<div dir="ltr"><div>The categorisation of bugs in our bug trackers by release has always bothered me because it wasn't clear what the release actually meant (present in? introduced in? fixed in? vague guess?) or whether it was set correctly, especially the 'nightly' tag.</div><div><br></div><div>So I propose a simple rule on github: <br></div><div>-Add a single release tag, which is the earliest release (or 'nightly') in which the bug is known (or purported) to be present in. Use the 'ancient' tag instead if the bug has clearly been around a long time. Don't tag if unknown.<br></div><div>-If the bug is known to have been introduced in the tagged release/nightlies, then add the "Is new in ..." tag.</div><div>-When we do a stable release, all bugs tagged 'nightly' which are still open should be re-tagged with the new release. Any closed bugs tagged 'nightly'... I guess we just keep them as they are.<br></div><div><br></div><div>Tags for operating systems were also a big mess previously. OS tags should only be used if actually relevant.<br></div><div><br></div><div>I've checked that the issues currently on github comply with this (most aren't tagged by release). When bugzilla and sourceforge bugs finally get imported (I want to try again soon), I'll try to homogenise tags/categories across the different trackers, and will replace "nightly" on open bugs with something else. So just beware that old bugs might be inconsistent. I think I'll just remove the OS tags completely (and put that in the description instead).<br></div><div><br></div><div>We can also create a milestone per release and add fixed bugs to the milestone in which they were fixed. (Open bugs added to milestones are a todo list)<br></div><div><br></div><div>I'm also going to follow the same scheme with the bughunters league table, but moving forward I want to get into the habit of filing bugs of GH instead putting them in that table. Unless I fix them immediately or they're trivial (glitches), I guess.<br></div></div>