I wrote up a draft bug reporting guidelines document and wanted to throw it
up for comment. I would appreciate any feedback.
'''Bug reporting rules:'''
'''Before Reporting a bug:'''
1 Check upstream to find out if this bug has been reported. Trisquel
GNU/Linux is based off Ubuntu and even further upstream Debian. Bugs in
either of these distros often make their way down into Trisquel. If the bug
is in a specific package also check that program's bug tracker if one is
available.
* Check Ubuntu's bug tracker (https://bugs.launchpad.net/ubuntu)
* Check Debian's bug tracker (http://www.debian.org/Bugs/)
* Check the package's bug tracker if one exists
2 Check the bug tracker to make sure this bug has not been reported already.
Unfortunately Trisquel does not have the level of manpower other more popular
distributions have. Try to avoid duplicate bugs for this reason so that
volunteers and developers waste less time on duplicates.
3 Make sure the bug the bug tracker is the appropriate place to report your
issue. Not all issues are best suited for the issue tracker. For example,
most support issues are best addressed on the forums. Secondly, upstream
resources may be better equipped to support your request. For example, The
Document Foundation may be better suited to help users with LibreOffice
(https://www.libreoffice.org/get-help/) then Trisquel.
* Direct issues to the areas best suited to respond (e.g. forums for support
requests)
* Seek upstream documentation/assistance for help with specific packages.
'''When Reporting a bug:'''
1 If you were able to find an upstream bug please link to it. Linking a bug
to an upstream one helps us track issues better and use less man-power fixing
bugs that can be fixed by others. If you were unable to find the bug
upstream consider reporting it to the upstream providers as well.
Link to upstream bugs to help developers track the issue.
If no upstream bug exists previously consider reporting it.
2 Describe the issue clearly. The more information the better. Describe
relevant information such as what version of Trisquel you are using, edition
(e.g. mini, pro), and software version for any packages. Hardware
information may also be useful. As clearly as possible explain the problem
and the steps needed to reproduce it. The expected results compared to what
actually happens will help volunteers and developers greatly.
3 Select an appropriate priority for the issue. Volunteers and developers
use an issue's priority to determine which bugs to fix first and the bugs
importance. Marking a non-urgent bug as “critical” hampers these
efforts. Some general guidelines include:
* Bugs that violate the GNU Project's Guidelines for Free System
Distributions area always “critical”
* A technical “critical” bug is one that causes Trisquel not to function
or have a serious flaw.
* A normal bug is one that may affects a specific program or part of
Trisquel. It may not be enough to crash the operating system but is an
issue. It should be noted that an issue with a specific package may be
“critical” in reference to that package but it is “normal” as far as
Trisquel is concerned. For example, a critical bug in GIMP (GNU Image
Manipulation Program) that causes it to crash is not a critical Trisquel bug.
This is because while the bug is critical to that specific program it is not
critical to the operating system.
** A minor bug is one that may cause minor annoyances. These may be things
like spelling or grammatical errors. They may also be bugs that do not have
a major impact on the operating system.
'''Things to consider when reporting a bug:'''
1 While not required, if possible report bugs in English. Most Trisquel
developers and volunteers speak English. Issues are more likely to be
addressed quickly if they are in English. However, submitting a bug in a
language other then English is not frowned upon in any way.
