I just wondered: Do you think Fairphone should have a bug tracker (like e.g. Bugzilla) outside the forum to deal with bugs in Fairphone OS?
My opinion on this: The forum, as it is a community-led place, is not a platform to efficiently communicate bugs to the software developers in the Fairphone team. If the community finds a bug, it should be verified by a Fairphone employee so we, as the community, know that we have been heard and can hope for a fix.
That might be true. AFAIK this is the repository which Kwamecorp set up to publish Fairphone Launcher, PeaceOfMind Widget, and Updater. The repository has not been updated for over a year and the latest mentioned Fairphone version is 1.2. You are right: This is seriously old and doesn’t seem to have ever been used for development.
However it might be a good start. It’s there already and if someone would actively monitor it, it could be an easy and cheap way to get started with an issue tracker. No need for extra setup or costs.
Of course, all will be in vain if no one involved in development monitors it and responds to issues.
The last link also brings to mind the Bug Reports section of this forum. It’s not really an issue tracker but at least it is public and people respond to it (if not Fairphone staff, then at least fellow users and forum mods).
To summarize: There are plenty of options available to let Fairphone (and possibly fellow users) know of bugs. However none of the presently available options seem to properly do the job. Integrating them to some extent might be a good option.
The problem is that it needs to be managed/moderated, and with a community as large as FairPhone’s, this might end up becoming a fulltime job.
For example, if you have 15 people experiencing the same problem, there’s a good chance at least 10 of them will create a new bug report for the problem so you end up with lots of duplicates. You need someone to merge these reports or delete duplicates.
I don’t think that especially the duplicates-problem is a brilliant argument FOR a bug-tracker: with most bug-trackers this is a single button task (granted: you’ve got to know the ID of the ticket this is a duplicate of). The reporter then knows where to look for further information (good bug-trackers even automatically add him to the original ticket so that he gets information about the progress there)
Of course it is work to maintain such a bug-tracker. But less work than searching the forum for reports and trying to keep track IF you do that at all. Not having a bug-tracker says “We don’t care and will only fix the things that bother us personally”
Well yeah, you’re right, but the point I was trying to make is that a bug tracker needs someone to do the household work in there, preferably someone from the FP dev team. That someone is on FP’s payroll so I don’t know how many resources they’re willing to spend on something like this.
I would rather like to have feedback on the issues posted in the Bug Reports category. Are they being worked on? After the outroll of 1.8.5 we should ask around in the topics to see if the issues there have been fixed.
I will then make a list of unsolved bugs. (Plese remind me, if I forget about it. ;))
I think the bugs category could easily be used as a quite good bug tracker. It just has to be maintained a little better.
First us moderators should go through all the bugs and move all topics that are not really bugs to another category. (E.g. I believe we established that the ghost touches are not a software bug but a hardware issue, right?)
Then a software employee should go through all the open topics in the category and comment whether the bug is recognized, is being worked on or was fixed already. (I’m guessing that employee would be @keesj, since he’s the only one regularly posting in the bugs category)
When a bug has been fixed the topic should be closed with the note: “This bug was fixed with Fairphone OS 1.x.x…”
We currently have 36 topics in the bugs category, 15 of which are already closed, so I think this would be manageable.
EDIT 1: Maybe we could also add status tags to bug topics, like [fixed], [fix in beta testing], [soon to be fixed], [recognized] and [unknown].
EDIT 2: This is what a structured bug report could look like.
You are right, we should think about changing that statement a bit.
On the other hand the bugs section is primarily meant for troubles a lot of users run into during normal operation. And in those cases us moderators will involve the Fairphone team.
This sounds more like a forum for users to report problems (informal) than to report bugs (formal). Perhaps this distinction could usefully be made? This could help both users (because then they can tell where to send their report, according to their level of technical expertise; for example, I am used to dealing with bug reporting systems as a developer), forum maintainers (not having to act as intermediaries for straightforward bug reports) and users (make it more obvious where to take their problems according to their level of experience).
I’m sorry, I have now diverged somewhat from the original subject…
We (as the community) are aware of the somewhat undetermined situation regarding bug reports. Actually I want to thank you for bringing this topic up again. It should be considered, now when FP2 comes up.
Regarding your issue with sound file names: Personally I don’t think this is a very pressing issue, and it also does not affect a lot of people. We community moderators usually only contact the Fairphone Team, if there is a serious bug, which is a deal breaker for the majority (like this one).
now that the source of the FP1 will be available (or at least for the FP project) and with the FP2 coming up … a bug tracker like redmine or bugzilla or JIRA or … would be great to keep track of things.
@anon12454812, @anon90052001 : Are you planning to do something like this in the future? Or are you going to outsource the coding more and more back to google/alternatives? Even if so, it would be nice to see if most of the FP1/A4.2.2 CVEs are fixed.