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).
You’re welcome, I hope you find a good solution; and I agree entirely that my problem is not a serious one. I’ve filed a support request about it.
Hello,
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.
This is already one good list to get started
It would be great if you could also talk about this in the upcoming blog post 
From what I read from the blog post about releasing code and the build environment for FP2, I figure that a bug tracker is planned:
We are currently working on a system to accept community contributions (yes, there will be a public Gerrit for code review)
It doesn’t explicitly mention a bug tracker but bug reports are one important part of community contributions. And on the practical side, Gerrit is much more useful in combination with a bug tracker.
Therefore, I agree with @fp1_wo_sw_updates and the others, that a bug tracker should be introduced for FP2. And since you are at it already, also add a category for FP1 
I know there’s a list of bugs maintained here on the forum, but:
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.
What about:
Actually I just got presented a link to “Bugs”, “Help”, “confirmed Bugs”, “Software Problems” (Category labeling) and found About the Bug Reports category. I guess that’s the info I wanted to be presented with in the different locations I mentioned above.
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:
http://omni.cmxlog.com/6/mako/
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:
[Poll name=1]
or like this:
0 voters
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!).
I really like the poll idea as well!
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.
I think that liking is not as intuitive as voting in a poll. Also I, for example, tend to like good bug reports (a lot of information, etc.), also if I don’t have the problem myself.
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:
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…
Full ack!
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.
As long as it isn’t a Heisenbug.
But joking aside is there a howto about “How to get useful debug information for the FP1, FP2 under different OS’es” somewhere?"
I did a quick search but I was not able to find anything. Have I missed something or does such an article not exist?
None that I know of. It shouldn’t be too different from debugging other (stock?) Android phones. Maybe you can find a good one?