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@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp