Closed svx closed 7 years ago
:+1: !
@svx I am currently working on this package, and could include this. As we currently have a metric like:
"## type: name" color
see: https://github.com/plone/plone.github/blob/master/definitions.json#L229-L257
"LABELS": {
"01 type: bug": "fa0000",
"02 type: regression": "ff9900",
"03 type: feature (plip)": "0000fa",
"04 type: enhancement": "00fa00",
"05 type: question": "fa00fa",
"11 prio: blocker": "990000",
"12 prio: high": "cc0000",
"13 prio: normal": "e06666",
"14 prio: low": "f4cccc",
"21 status: confirmed": "fafa00",
"22 status: in-progress": "fafa00",
"23 status: testing": "fafa00",
"24 status: ready": "fafa00",
"25 status: deferred": "fafa00",
"31 needs: help": "00fafa",
"32 needs: review": "00fafa",
"33 needs: docs": "00fafa",
"34 needs: tests": "00fafa",
"35 needs: rebase": "00fafa",
"36 needs: cla": "00fafa",
"41 lvl: easy": "6aa84f",
"42 lvl: moderate": "38761d",
"43 lvl: complex": "274e13"
},
could you please translate this into this schema:
maybe:
37 needs: doc review by one person": "00fafa",
38 needs: doc review by two persons": "00fafa",
@loechel yeah sounds good !
In a perfect world I would like to have also a
39 prio: blocker documentation": "990000",
or
39 prio: blocker release": "990000",
Currently we have for example open issue https://github.com/plone/documentation/issues/881. Before we release 5.1 we should make sure that we have a upgrade guide to 5.1 in the docs.
This is not a 'blocker' on the software level but IMHO still a blocker for a release.
I do not want offend someone, but in my opinion we should also have 'blocker' for this kind of things to make sure we have a good[better ?] QA for releases.
As I said many times before is it not only about the code ! :)
-1000 - no specific labels in the common name space please.
therefore we have 99 tag: whateveryouwant
BTW: blocker documentation
is already theres with the combination of current 11: prio: blocker
together with 33 needs: docs
- this is how it's supposed to work.
We want as less labels as possible!
"37 needs: doc review by one person" translates to 32 needs: review
+ 33 needs: docs
+ 99 tag: one person
OR + one of the 4x lvl: *
Also, tags are not everything: we have also projects and milestones! Do not mix this.
To give this a better semantic I could imagine a new type: 05 type: docs
:
05 type: docs
+ 32 needs: review
+ 4x lvl: *
(* => easy=no real review needed, moderate=one person should review, complex=2 person review would be great).
To be honest I do see your point but for me this is way too complicated :)
Yes, less tags !
Having to use a combination of different 4 tags to label it with one certain thing is at least for me weird :).
I do see the point of flexibility and such, still for me too complicated and time consuming.
Also, again speaking about me here, the group and label prefix confuses me :)
Maybe its a matter of personal workflow and taste :)
I do not want to start a boring discussion here about the way of labeling and tags, we have better things to do, so lets not do that :)
'Just' as example in other projects I work we use something similar more or less to that: https://github.com/kubernetes/kubernetes/labels
Again, I guess there are reasons why we use something with numbers and groups. So fine lets stick with it :)
Should I close this issue ?
@svx I am for closing this one here and may discuss it at a certain conf.
Ok, closing it !
Hi,
Can we add
Scenario: For 'bigger' changes or changes in certain parts, we want to have more than one person to review docs pr. Or in another scenario it will be helpful if a person with the needed knowledge is doing review 1 and a person of the docs team [or someone else] is doing a second review to make sure that the rst and formatting is right and that everythin is OK according to the docs guidelines.
Another aspect:
plips: it would be awesome to include docs into plips, meaning if there is a new plip and the fwt agrees on that one, we should have a technical review [fwt] and a docs review, and only if both reviews are OK, the plip will get merged. Somehow we as community forgetting this aspect, to name just one example 'new collections' we had them for more than a year, without any docs on how to use them and so at all :)