There has been repeated and strong requests from the community for a bugtracker and we hope we can implement this when we move over to Marshmellow.
To make sure that the bugtracker we use is optimal for the community, we’d like to request the community members who would such a tool, to share your expectations and experiences with us.
What bugtrackers have you been using so far and which one do you like?
What is the minimal a bug tracker should do?
Do you have examples of other project (preferably somewhat similar to Fairphone) who make good use of bugtracker in combination with their community?
Is there stuff we should think about, that we are probably forgetting now?
Thank you for your input and I hope we can collectively get this of the ground soon!
I like Github’s issue tracker because it has a nice UI that invites contributions. That’s also why I don’t like bugzilla. So, in my opinion a bugtracker should have an inviting user interface.
I think the bugtracking tool itself is not the crucial point, it is the proper handling of the tools.
During my work I used Mantis, Redmine, Openproject, Jira, OTRS, Github,… The core funktions are more or less the same. I like Redmine most, because it is open source and has good addons.
I think the most important thing is a proper wording on bug status, version, description and using the tool in your daily work. There are many possibilities to connect the bugtracking with your communication and tools (git, svn, etc.). If it is set up correctly that can save a lot of work.
EDIT:
I would NOT start with a minimal version or a “self-made” solution. In the beginning it seems that a number, title, description, … is enough. But it will turn out that you will need the nice features you haven’t thought about…
Evalute the tools and make a decision, do not start without a proper wording and defined workflow…
Migrating data afterwards is a lot of work
I agree. I believe most people who demanded a proper bug tracker in the past were actually complaining about the lack of feedback by the developers.
I believe if bug topics in the forum had been officially marked as:
Fix will come soon.
We are working on it.
It’s high up on our todo list.
It seems low priority to us and we’ll get to it when we can.
We don’t think it’s a FP-bug / A third party would have to provide a fix.
We don’t have enough info to go on yet.
the discussion about a bug tracker would have never been started.
But don’t get me wrong. Even though I never used a bug tracker and therefore personally don’t see the benefit I don’t mind it at all.
There are just two things I really hope for:
There should be some proper integration to the forum. People who post issues caused by known or unknown bugs on the forum shouldn’t be asked to file a bug report and provide debug info on a complicated bug tracker tool if they don’t know the first thing about debugging. They should instead be helped and provided with workarounds if they exist. And they should have the opportunity to discuss the issue with other people who have the same problem and talk english and not code.
But then again there shouldn’t be information lost by splitting between the forum and the bug tracker - hence: some kind of integration - I don’t know how exactly that could work.
There should be a up-to-date list of known bugs with human-readable descriptions. Since I believe normal users won’t be using the bug tracker I fear there will be a lack of language there that normal users can understand.
I love Taiga! I use it everyday But I more see it as a FLOSS alternative to Trello, than a bugtracker to be used for Software development…
Thank you all for your contributions so far!
I made a little ‘user story’ to describe the use case for an average community member.
Submitting a bug by a Fairphone community member
Alice has a Fairphone 2 and finds a bug. The screen brightness is not going up as fast as she’d like to. She goes to code.fairphone.com and clicks on the button ‘Submit a bug’ which leads her to a bugtracker page. She can describe the problem and classify it (minor annoyance, major annoyance, critical etc.). She has to fill in a few fields before she can submit: version of the OS and version of the Fairphone.
The bug tracker uses the words in Alices bug report to do a search in the system for already existing bugs and presents Alice with the bugs that look similar. Alice has the option to discard her own report and +1 an already existing bug report if it is very similar. If the new report is unique, she can go forward with submitting.
If she already has an account the bug is submitted, otherwise she is presented with an sign-up field. She can sign-up with Google, Facebook, Twitter, Github, email or her existing forum account. This way the dev can contact her in case the dev needs more information. Also Alice can login at a later date and quickly check the status of the bug she reported.
Checking a bug
Alice logs in with the credentials she made earlier on the bugtracker. She has a clear overview of the bugs reported by her and the other bugs submitted by other users. She can +1 the bugs reported by others that she also experiences.
The bugtracker shows her the status of the bug: New, accepted, assigned, fixed.
Do you think this is an accurate description of such a user story?
How would you describe your own usage of such a tool?
I like that there are obligatory fields like the OS version. There should be a leading to the support article “How to find out my OS version”. The same goes for other fields that are not obvious to the average user (for example: any modifications like Xprivacy, Gravity Box, etc.?)
I don’t like that. You have to fill out the entire report before being presented with similar bugs. I believe Alice may discard her report because she likes to follow rules and she may feel insecure whether she did the report correctly anyway, but Jasper won’t just discard his report even if there is already a very similar report, simply because he doesn’t want to have wasted time and effort in filing a presentable bug report.
@Douwe Some GitHub repos that I have used / submitted bug reports to have in their template a check list were one of the item you need to check of is that you have searched the issue tracker for similar reports before submitting your own one. I think it is hard to do much more than reminding people of that in order to prevent duplicates.
I have written a thesis on the subject of finding duplicates (specifically on GitHub), and prior to that I did some research on what preventive measures you can take, but I think it is generally hard to prevent new duplicates when the issue tracker grows to a certain size.
But I more see it as a FLOSS alternative to Trello, than a bugtracker to be used for Software development…
leading to the support article “How to find out my OS version”. The same goes for other fields that are not obvious to the average user (for example: any modifications like Xprivacy, Gravity Box, etc.?)