Better labels for all core packages

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.

Since formatting im would come to its limits I started a spreadsheet. Don't forget to read the explanations at the bottom:

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?

I already have a script doing all this at There you can find also the current labels and the proposed migrations:
Please do not let this thing run if you're not exactly know what you are doing!

For one repository - plone.event (which has just 2 closed issues and 2 closed PRs) - I run the script already. You can look at or create an issue (do not save!) and add a label in order to see how the label-selection-widget looks/feels like.

Feel free to comment.

1 Like

Hi Jens,

Thanks for the writeup!
I have some additions to this. I'll get back to you on this this evening.

In the meanwhile, check out
I think you'll find it very nice to map the 'status' labels as 'pipelines'!


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 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.

Here's how works looks for me for
I use the columns for status and labels for additional information.

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.

Thats very fine-grained. Do we need this for all repositories or just a selected number?

Waffle works with combined repos too!:

That's excellent!
Probably better than Zenhub as it does not involve a browser-specific plugin.

Agree, bye-bye zenhub :slight_smile: