← Back to team overview

kicad-developers team mailing list archive

Re: Launchpad bug tracker guidelines


Hey Nick,

This was on my list but if you want to take it on, I'm fine with that.
I agree that it should be a separate developer document in markdown
format.  I also recommend that we link this document on the bug squad

There needs to be section on when and how set the various bug settings.
 There is currently too much variation in how we handle bug reports.



[1]: https://launchpad.net/~kicad-bug-squad

On 5/21/2019 5:27 PM, Nick Østergaard wrote:
> 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
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp