kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

Dear Developers,

and other people actively using the launchpad bug tracker for KiCad.

I have had the intention to write a guideline on how to help triage
bugs. Mostly categorizing the priority, target milestone and tags. I
have never reached this and we are now far into the year of 2019...

I think we should add notes in the kicad dev docs (some md file in the
doxygen docs) along the lines of:

====
# Tags
Use tags if it makes sense, a bug does not _need_ to have tags, but it
is often useful to add eeschema or pcbnew if it only applies to
specifics in that sub-application.

There is a moderated set of "official tags", these are tags that will
appear as a suggestion when entering tags. We want simple tags. Some
tags are multi word, like 3d-viewer, but otherwise we should try to
avoid this, don't use underscores. Just use words that can be used as
separate tags. This is for example used for bugs relating to some
import for export of a file, for example export of step models, they
are tagged as "export step", preferably pcbnew is added here as well
as this is clearly not relating to anything other than pcbnew. Or it
could be "pcbnew import svg" if it is about the secret SVG importer,
or "pcbnew pns" if it is purely related with the router tool in
pcbnew.

<a list of all or most important official tags and their intention may
be good here>

We should avoid using too many other tags that are not "official
tags". They are not forbidden, but probably not needed. If we have a
billion tags, then they are of no use. There is no need spending
cycles to be creative with adding as may tags as you can think of in
thirty seconds.

# Status
This should be more or less self explanatory. Worth mentioning is that
Fix Committed is used when it is merged on master or a feature branch.
An exception to this could be if it is specifically a bug made against
a developers preview branch.

Fix Released is used when bugs are in Fix Committed state around
tagging a release of KiCad. This may also be used if it is an issue
not directly related to KiCad source code, like packaging or
peripheral KiCad project.

Triaged: This one is subjective. I don't really think this is very
useful. Many bugs have this status while I don't really think it is
clear what the next steps for the bug is, or what the intention with
the bug is. IMHO this should only be used for bugs where a good
description of an issue or feature is present, and there is some very
concrete work that can be done.

# Importance
The meaning of the importance used in the KiCad project:

Not decided yet. | This is OK for many bugs.
Critical | Exclusively for things like build errors and crash bug
High | Reserved for bugs that cause loss of or corrupt data.
Medium | Fix when convenient, or schedule to fix later.
Low | Fix when convenient.
Wishlist | Not a bug. It's an enhancement/new feature.

Low bugs could be bugs tagged with starter as well, it may be easy
bugs, or it may be hard work for a simple task!

Please do not escalate any bug that does not meet the appropriate
criterias on High and Critical.

# Milestone
Use of this field is intended to put the bug on a milestone to be able
to get a quick and good feeling of how far we are from tagging a
milestone.

====

This email is not intended to be a discussion, just a +1 thing if you
like it and feedback on where we should document this. This specific
part is intended for developers and the bug squad as a guideline, not
a guideline for newbies reporting bugs, but similar information could
be used as part of the content of
http://kicad-pcb.org/help/report-a-bug/.  For that page we should
probably also give some very quick guide to provide backtraces, or is
this not needed with the new stuff from Tom?

So please indicate on the way forward. Should we add it to the dev
docs or the website?

Regards
Nick Østergaard