Gitlab issues for pre-installed apps: should they be reported in Gitlab at all?

Someone named Nicolas Gelot, alias nicofonk, just closed this issue that I had raised in Gitlab, stating that I should report it to the app vendor (in this case, Magic Earth), not on /e/ Gitlab. Ok, but then why is there even an ‘/e/OS Maps’ tag in the Gitlab, when these issues have nothing to do in Gitlab? and why are other issues relative to pre-installed applications remaining open while mine is being closed? Manoj likes us to report issues in Gitlab but it get’s a bit tricky when it comes to which ones to report and which ones not.

Side note: I like the ‘bug bounty’ label because it clearly communicates that /e/ is not in charge but that the /e/ community is being mobilized.

As you may be aware, most of the apps we have as default on the /e/OS are forked from the original. At times, issues raised by users are issues existing on the original app. These bugs cannot be fixed by /e/OS developers and need the original application developers to make changes. The ideal way to report such issues is to report it on the original app’s site or issue trackers. This is a convention followed all over the software industry.

Well noted.
I think you guys could make a huge cleanup of Gitlab issue by closing all the issues that are in the scope of the original app manufacturer instead of in the fork by /e/. in other words, issues like mine.
What do you think?
Reducing your workload is key in my opinion.

1 Like