Fairphone Bugtracker. Request for Comments

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.


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.


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.


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.


  • Suggestions by @johannes (Fairphone Model, Voting)
  • Language changes.
  • Suggestions by @stefan (put checking for duplicates higher on the list)
  • Suggestions by @tphysm to make the text more dense and remove repetitive language.

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)?


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 :slight_smile:

And yes, we’ll use the voting system. I added that to the form. Thnx for the tip!


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. :slight_smile:

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? :confused:
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 :slight_smile:


@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

Thank you @tphysm for your feedback!
I updated the text with your suggestions :slight_smile:

The bug tracker is here now: