Yesterday in FWT meeting we briefly discussed usage of Milestones and Labels in all Plone core packages issue trackers.
To increase quality we need better targeting of issues, across all issue trackers. This is valid for milestones and for labels.
With milestones its easy: we need to create them (best automatically) for every repository in the github plone organisation. Timo proposed to use the target versions like Plone 4.3, Plone 5.0, Plone 5.1. We can make it even more fine granular if needed, but lets start with it.
With labels things are way more difficult. We have a complete jungle of labels at the moment (most sematically very similar). I fetched all existent one using Github API and made a proposal of what a future system may look like.
I'am curious about the comments on the label-system. I did not invent it, its more or less a mixture of ideas found on the web put together for current plone-core reality
I tried to avoid too many labels, but its still a whole bunch of them. Any ideas how to reduce them w/o loosing information?
For one repository - plone.event (which has just 2 closed issues and 2 closed PRs) - I run the script already. You can look at https://github.com/plone/plone.event/labels or create an issue (do not save!) and add a label in order to see how the label-selection-widget looks/feels like.
Liking the idea, but would like some extra ones. I know, bad, we want to reduce the number...
But some 'topic' would help:
31 topic: managing content
32 topic: accessibility
33 topic: installing / deploying
34 topic: UI / UX
35 topic: theming
or so would help me (and probably other teams) to find 'their' issues quicker. Actual list is debatable, but nice if in accordance with terms used in the documentation.
And on the milestones: maybe that should be left. plone/documentation and plone/papyrus are on other release schedules, for instance, and probably also others want their own versioning scheme as milestones. So the "4.3", "5.0", "5.1" are only practical for Products.CMFPlone.
@polyester I also had already the idea with xx topic: something but its difficult to find universal topics. So i let it in the domain of a universal `xx tag: SOMETEXT`` .
But if we're able to define a small (best 5, max 7 items) set of general valid topics this would be a good extension.
I also thought about having xx needs: something instead of the xx status: needs XYZ (replacing that ones with xx needs action). this way we can have a real flow through the states which targets better a "kanban"-style represenation of the workflow like zenhub of waffle.io offers.
maybe like so:
51 needs: help
52 needs: review
53 needs: docs
54 needs: rebase
55 needs: tests
My overall fear is that we're starting to over-engineer things when doing all this. So more opinions welcome.
Ad milstones: I agree, we should stick them only to the set of packages used in coredev sources.cfg file. We have two versions of it and its easy to parse the information out automatically.
I would really like to see extra labels for enhancements that target:
user experience of editors
user experience of themers
user experience of admins
onboarding user experience (ie beginners)
The reason is I think this will help provide a flag for the UX team to get involved (perhaps even automate it via an email). I'd like to try and create greater interaction between the UX team and developers and end users. This is one possible way to do this but there might be others.
The reason I split out the different user roles as I think it might help developers focus on whose problem they are solving so the solution is more likely to match the end user problem.
Zenhub looks and feels really good - only drawback: its chrome only - thats crazy!
I think Zenhub will work fine with the proposed labels.
I'll try to find time to refine the label-set as proposed above and come back them.
