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.
1 Like
+1 for Redmine. I also liked the tool.
2 Likes
True. Do you have a suggestion how to encourage people to look for other similiar reports first so we can minimize duplicates?
@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.
6 Likes
Maybe there can be one or two volunteers from the community, who help the devs to keep the bug tracker tidy and sort out duplicates.
3 Likes
here is a linux distro using phabricator - they do a very good job, to my opinion.
https://dev.solus-project.com/
1 Like
Tuleap is FLOSS and Savoir-faire Linux (developers of the GNU Skype-killer, Ring) like it:
They say it is more flexible than Redmine and can be linked with git and Gerrit
2 Likes
I am happy to announce that after some weeks of trying and testing different tools and setups we’ve come to a conclusion. This week we’ll be installing and testing Taiga internally as our new bugtracking system. Thank you @mheiber for the tip!
We like the ease of use, friendly design, very permissive license and active development of Taiga. We hope of course that our community will like it as well.
If all goes well it should be ready before we release the Android 6 beta to the community.
So, if you want to test both Android 6 beta on your Fairphone and use our new bugtracker to help us squashing the last bugs, make sure to apply for the beta testing program!
Everyone who gave us tips here and in other channels, thank you for thinking with us, it helped us a lot to come to a decision.
14 Likes
I am currently writing the Contributions file for the bugtracker. I’ll paste it here so you can give feedback if you want!
Fairphone Contributions.
Introduction
First off, thank you for considering contributing to Fairphone. It’s people like you that make Fairphone possible.
Below, you’ll find all the information you need to get started right away! Take a minute to read it so we know you respect the time of the developers managing and developing this project. In return, we will reciprocate that respect by addressing your issue, assessing changes, and keeping your issue up-to-date.
Android 6 for Fairphone 2 is our latest project, and we’d love to receive contributions from our community (that’s you)! You can start today by submitting bug reports and feature requests.
Please don’t use the issue tracker for support requests or other open questions. Our forum, the official support section of our website and IRC/Matrix channel can help you answer to those questions.
How to contribute:
All contributions and bugs can be submitted in our bug tracker. Even small issues such as spelling mistakes can be made into a bug.
- Check for duplicates. Vote up an existing bugreport instead of filing a similiar one.
- Have a look at the bugs already submitted to get a feeling for how to do it.
- Now click the bright green button in the top right of our issues list and fill in the field in the new window that pops up. Easy, right?
You’re ready to submit your first bug!
- Give as complete and detailed information as possible when submitting a bug.
- Include the Fairphone version, OS version, apps in use, networks connected and steps needed to reproduce the bug if possible.
- Use factual language describing the issue, not your personal feelings on the issue or how it is being handled.
If you’re still not confident that you’re doing it right, feel free to ask for help. Don’t worry, everyone is a beginner at first.
How to suggest a feature or enhancement
Fairphone has small team of developers who are committed to making a fast, lean OS that receives regular and timely (security) updates. New features should not interfere with basic OS functionality or complicate the monthly updates.
If you find yourself wishing for a feature that doesn’t exist in Fairphone OS or Fairphone Open, you are probably not alone. There are bound to be others out there with similar needs. Many of the features that the Fairphone has today have been added because our users requested them. Open an issue on our issues list on code.fairphone.com/bugtracker which describes the feature you would like to see, why you need it, and how it should work.
You can also check forum.fairphone.com for lively debates about which features users want most and why.
Bug review process
The core team looks at the issue tracker on a regular basis in a weekly triage meeting. This meeting is on Wednesdays and afterwards the issue list will be updated to a new status if needed and tasks assigned to team members. You can then check the updated status of your bug report.
Community
You can chat with the team members and the rest of the community on #fairphone:matrix.org and fairphone on Freenode. But most of us gather on forum.fairphone.com.
Edited
8 Likes
So this is only for the Android 6 development at first, right? (potentially makes the Fairphone model question a bit redundant initially). Otherwise we could port some of the current bug reports listed on the forum into the bugtracker to have some relevant examples in there as soon as it opens.
Relevant examples of feature requests are easier to predict before the release of the first Beta. As the guidelines leave a lot more room for variation, there would be a benefit in having some very nicely worded examples in there.
As a side note: Will the voting system in Taiga be used? It may help the developers get a feel for demand/impacted users and dissuade a bunch of me-too posts… If it is, should there be a note in the contributions file on voting behaviour (when is it encouraged)?
3 Likes
Yes, that is a great idea! Initially this is indeed for Android 6, but I hope we can add more and more projects to Taiga in the future. I hope people are willing and able to help with that as soon as the bugtracker is up 
And yes, we’ll use the voting system. I added that to the form. Thnx for the tip!
2 Likes
I think that the following paragraph should really be the first in the list above.
Check if the bug or request is not already reported by anyone else. Vote up an existing bugreport instead of filing a new one if possible to prevent duplicates.
Also, in the introduction section the official support is not mentioned.
Ps: Will the URLs be linked? Eg forum.fairphone. com
Yes, I put the part of checking for duplicates higher on the list.
But support is mentioned…
And yes, in the final doc they will all be links.
Oh, I only connected “support pages” with support articles. It sounds a bit disencouraging to me to use the support form.
How about ‘the official support section of our website’?
1 Like
Are you two talking about “only for Android 6” as opposed to FP1’s 4.4.4 beta, opposed to continuing support for Android 5 or opposed to #software:alternative-oses? 
Could it make sense to use the same Bugtracker for community efforts as well as for officially supported software?
1 Like
As the Android 6 release is an entire new project, it is easy to start with Taiga now. It will create a lot of work for us to move the documentation and bugs of 4.4 to a new bugtracker. Time that is better spend on working on the actual update.
If proven successful and people are happily using it, I hope we can move more and more projects into Taiga. But one step at a time 
2 Likes
@Douwe Nice introduction text for the bugtracker - I like it a lot!
I just stumbled over a minor point:
Have you already incorporated this change into the draft above? If not, just ignore my following comment. If so, it seems like you moved this part higher in the “Your First Contribution” section, but not in the “Responsibilities” list, which is what @Stefan meant and what I would support to do as well.
Moreover, right now the last point in the “Responsibilities” is (nearly word-by-word) directly repeated in the first sentence of the next “Your First Contribution” section.
Another suggestion from my side: Perhaps it may be possible to remove repetitions or condense some sections a bit? For example, the responsibilites list point
and the “How to file a bug” section do have some overlaps / repetitions that might not be necessary for some (most? or only advanced?) users and that could possibly reduced. But it might in fact be helpful for beginners and it indeed seems reasonable to mention it as a short point in the beginning and have a detailed section later for it. Hence, it might be better to just leave it as it is.
In fact, I have no good idea how to remove repetitions or condense sections - it’s just an idea that came to my mind while reading it, cause I thought that the text might be a bit too long. However, this also depends on the representation and location of the text - e.g. it would imho be too long for a banner on top of the site like in the forum some time ago whereas for a text on it’s own introduction / howto page I think it’s perfecty suitable.
1 Like
The bug tracker is here now:
https://forum.fairphone.com/t/the-bugtracker-for-android-6-is-here/28222?u=paulakreuzer&source_topic_id=25053