per1234
commented
6 years ago This is really great!
A suggestion: GitHub now allows you to add descriptions to labels. The text of the description is displayed as sort of a tooltip when you hover the mouse over the label anywhere it's displayed in the repository. Adding summary descriptions to this repository's labels would make the information contained here more visible.
You can edit label descriptions by going to the label page: https://github.com/Optiboot/optiboot/labels then clicking the "edit" button next to each label, which will provide a description input field.
I am rather used to a more complex bug tracking system that includes a lot of meta-data with each "bug" report, and I've tried to duplicate some of the fondly-remembered features using GitHub's "labels." But it's probably useful to define what I had in mind...
Announcement - an announcement of some project or occurence of probably interest to users of Optiboot. Usually some modified version that hasn't been (or won't be) accepted as a patch, or re-writes in assembler, and stuff like that.
auto-migrated - Optiboot was originally a Google Code project, and was converted to github when that went away. Issues that were copied from the old Google Code repository have an "auto-migrated" label. No new issues should use this!
Component-Docs, Component-Makefiles, Component-Scripts - tags that an issue should be addressed by modifying something other than the optiboot code itself.
Discussion - means that the issue has turned into more of a discussion on how something might be improved or changed, rather than an actual change request. Also for tagging issues that are changes, but have resulted in a lot of discussion.
Duplicate - This is the same problem as another issue, or was fixed as a side effect of another issue.
help wanted - The Optiboot "owners" are unsure or unable to figure this one out, and are hoping for assistance from the rest of the community.
Invalid - The submitted issue was in error or otherwise rejected.
Maintainability - changes that should improve the ability to build and maintain Optiboot, but don't really result in any change in functionality. For example: updates needed for the latest avr-gcc version.
No-binary-change - changes that should no result in ANY change to the "production" binary images (Atmega328p for Arduino Uno, mainly.)
Not-our-issue - A valid issue, due to a cause that is outside the scope of the Optiboot project itself. Examples: compiler and make.exe bugs.
OpSys-Linux, OpSys-OSX, OpSys-Windows - An issue specific to the build process on a particular operating system.
Partly Done - some aspect of this issue has already been fixed, but it needs more work to be fully closed, or has not yet been tested on all the platforms that it is known to affect.
question - someone is using the "Issues" on github to ask a question, rather than report an actual problem.
Regression - Something that used to work right has broken. Usually caused by some other "fix."
Superseded - this issue has sat around for so long that it is no longer relevant, or it got changed/fixed by some other issue's changes.
Priority-Critical, Priority-High, Priority-Low, Priority-Medium Type-Defect, Type-Enhancement, Type-newChip, Type-Other, Type-Patch hopefully somewhat self-explanatory? I'm not sure what Type-Patch is, actually.
Typically when someone finds a bug, I'll assign it a "type" and a "priority", and maybe a "Component." As the fix is developed and a change is committed to the code, it may become "Partly done" if I recognize that additional work is needed (say, for other chips.)