← 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
page[1].

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.

Cheers,

Wayne

[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
> 


References