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.
The rubric for this forum says: “The Community Moderators will ensure that bugs are reported to the Fairphone team.”
But you’re saying I should report the bug myself. I am quite happy to do so, but in that case, could the forum notice be updated and include a link to the correct place to report bugs, please?
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.
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
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.
What about:
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:
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.