Fairphone help is a bit of mixed bag, I’m not sure whether there is a generally useful format that would apply there.
In any case, stuff that might be good to encourage people to include when something doesn’t work:
- Fairphone OS version number from the updater app (or at least something specific - I’ve seen a lot of posts that do try to give the information, but report ‘Android 5.1’)
- If unexpected behaviour:
- Steps to reproduce
- Observed behaviour
- Expected behaviour
- If concerning a specific app:
- Which app specifically? (e.g. ‘my calendar app’ is ambiguous)
- If the app was installed via a store:
- Which store?
- Which app version? (i.e. not the version of the store)
Though in some cases this may scare people off - which is not what we want to do…
For cases where someone doesn’t know how to do something:
- What is the desired outcome / what do you want to achieve? Sometimes we develop tunnel vision and end up trying to fix what we think is a small bump in the road when the actual problem is that we’re on the wrong road.
- What operating system is being used? (maybe version number isn’t too important - but FP Open or FP regular can be important)
- Is the OS rooted (not always important, though)
- Does the solution need to be compatible with certain other apps? (though this should ideally already be clear from the stated goal)
- Any other restrictions? (e.g. FOSS only)
Overall, I would encourage a template for #software:bug-reports, but at best some tips for #fairphone2help (how to maximise the chances of getting an actually useful response) as it may otherwise put people off. For #software:bug-reports it would be a practise run for the bug tracker that is planned to be implemented, so we may also want to get some input from the devs.