Q: How can we better categorize/label our issues, and better structure the project workflow?

@danbri's May 2015 notes on issue reorganization. After 2.0 shipped, and we are launching the new Community Group-centric process, I want to refresh our working habits. We have a lot of open issues, and their labels have evolved in an ad hoc manner.

Today's experiment. Using git2pdf I printed out the first 100 of our 175 open issues

These 100 issues fall into several natural clusters:

From right to left.

• Specific modestly sized schema.org vocabulary proposals (green 'v' for vocab) - 44 issues
• Tweaks and fixes to existing vocabulary (5 issues)
• Exempted from classification because done already (3), rejected (2), descriptions unclear (2 issues)
• New site features - software work. Mainly python coding, appengine, site navigation (css/js) etc. (13 issues)
• Content fixes - primarily bad examples, occasionally bad term descriptions. (8 issues)
• Site software fixes. Actual bugs that need attention, usually Python, sometimes JS/CSS/HTML. (7 issues)
• Workflow/documentation fixes, updates and improvements. (6 issues)
• Workflow and documentation for Extensions - the extension model, and/or specific extension areas (9 issues).

No conclusion drawn at this time.

See also current list of labels