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.
the support forum is a community channel and there’s always the disclaimer that Fairphone employees don’t (necessarily) provide help here
the list on the forum is maintained manually which makes it hard to get on the overview list
Consequently it’s unclear (at least to me) whether a forum post of a new bug will reach the software development team. Also there’s no mention on the website on how to report software issues. I guess we don’t want people spamming support via Zendesk, as it may lead to double reporting.
implementing some sort of public issue reporting (similar but maybe easier to github), where the community can filter duplicates etc and staff can provide official responses & updates (or makes some changes to policy and the forum to allow to fulfil this function).
In fact, as far as I remember some statements here in the forum, you are actually encouraged to contact support about this. They even stated somewhere (edit: according to this post it was the Software issue report) that they want to hear the bugs people are struggling with to get an impression about frequency of occurrence.
However, I also always thought that this is not the best way to handle this due to the same reasons you have mentioned (support getting spammed with this) and that it would be far better to set up a site or some kind of communication means which is more effective for all parties of the story.
Of course, there are the categories. But at least, this is not as obvious to people as a special communication means for that could be and I nevertheless don’t really understand why support wants to get spammed with bug reports.
I think you shouldn’t mix support facilities with bug trackers and code review tools. In most processes, problems the support department can’t solve are issued as bugs, but since support can solve many problems the bug tracker is not spammed with entries by end-users which usually lack important information (like OS version, exact steps to reproduce the problem etc.) which the support would ask for.
But speaking of community facilities: What I would really welcome would be if Fairphone developers would a public platform like GitHub (or something similar) for development. They can have another private repo, but from there they should push the changes to such a public repo, so all changes could be easily tracked over the web without installing a git client and syncing the code. A good example is cmxlog which aggregates the commit history for multiple repositories into a unified view:
And once we have that, the issue tracker could be the next step. One issue here is though that you typically have several different repositories for android development, but most people would have a hard time to determine which component is the one to issue the bug report for.
Regarding the wiki-style bug list here on the forum: Yes this is very cool and much better than what you typically see in other Android community forums, especially in forums run by the vendor itself! I would opt for keeping it this way, but to have this “developer friendly” issue tracker as well and link each issue to both the forum thread with the discussion and the issue tracker entry.
Yet that’s basically what’s happening now, right? Bugs are reported here, as well as tracked (after FP releases updates), and meanwhile people drop other questions as well.
Why this particular order? I don’t think we necessarily need public code review for an issue tracker to work properly.
I see your point, but I think it makes sense to have one bugtracker for Fairphone users and even keep the issues that appear to be upstream ones. Then it’s a one-stop shop for bug searches, and links can be provided to the relevant repositories.
Hmm. Not sure. Though I agree that the community-maintained bug list is nice to keep, I guess you’d want to avoid having two entries for everything (on a bug tracker and on a forum). Of course many not-so-tech-savvy users will (first) go to the forum and drop questions there, but then we can direct them to a bug tracker if they want to provide a +1 (‘this affects me too’) or provide their use-case details.
It’s intended that it’s not to easy. New members can’t create new bug topics (any more), but should create topics in #fairphone-help or #fairphone2help instead. Before we made this rule many people posted in the bugs topic with problems that could easily be solved and were no bugs.
Also this assures that if us mods decide something is indeed a bug we can add it to the list and there are no bug topics not on the list.
You’re right. This is not communicated explicitly, but I was assured that they indeed are aware of all topics added to the list.
About the question of where to report whether you have a problem too: I also don’t think its very helpful to spam the support team, neither to reply “same here” in the bug topic on the forum. Maybe we could simply add a poll to each bug topic like this:
The first poll is a great idea! The second poll doesn’t add much information to the first one (Nobody cares, if it happens sometimes/often (what are these values anyways?). A bug rather has to be reroducable always!).
Or should we just do it like with the feature requests and vote (reporting "I have this issue too) by liking the original post? We could add instructions to do so in the bugs list and/or the about bugs topic.
You wouldn’t have that problem in a more technical bug tracker system. Non-technical people will first go to the forum anyways. Moreover, in a good bug tracking system one can easily mark issues as ‘duplicate’.
Well, not true IMHO. I just posted a kind request to you to include an issue. Nothing against you personally (really appreciate there’s someone taking on the role of community mod!), but it feels annoying to have to ask permission for something to be added to a bug list. Processing stuff the other way around (mark as duplicate, not a bug, etc, after an issue has been submitted) feels a lot less belittling/patronizing. But yeah, not being flooded with false reports and allowing anyone to submit bugs, would indeed require a seperate tracking system (which is perhaps better-suited).
Maybe it’s something that you can add to the bug list as a note? Knowing that the team is aware of them is already comforting (at least we’re not reporting for nothing).
Yup, that would be great! Agree with @Stefan that ‘favouriting’/‘liking’ bug report may not be the most intuitive way to say ‘I have the same issue’. Third proposal:
I have this problem too
I don’t have this problem
The workaround is solved my issue (sufficiently)
Maybe a not should be added to every poll that people can update their status by clicking on ‘hide results’ and voting again.
Not necessarily, especially when talking about good issue tracking systems: For example, you could have an extra tags like “confirmed” which only certain people can set, and the devs would not be notified about bugs without this tag or would get a list which automatically filters them out…
I like the second poll and I think, the additional information if a problem happens all the time or often or only sometimes might be useful to find out what’s causing the bug. The workaround info is also valuable.
A simple vote in a poll won’t help you find the cause of a bug. Devs need detailes steps to reproduce an issue. If an issue can’t be reproduces it is most probably not a bug.
But it is also more work to do. That’s why we decided to restrict new topics in the #software:bug-reports category. I can imagine that community members, who show good quality reports (or references in other bug tracking systems), could be excluded from the restriction.