On Mon, Apr 29, 2019 at 8:07 AM Michał Górny wrote: > Update the wording of GLEP 48 to provide clear information on what kind > of disciplinary actions can be issued by QA and under what circumstances > they can be exercised. > > According to the old wording, QA could only request 're-evaluating > commit rights' from ComRel. This is very unclear, and has been a source > of confusion. Firstly, it is unclear whether ComRel merely serves > as a proxy executing the QA team's decision, or whether it is supposed > to make independent judgment (which would be outside its scope). > Secondly, it suggests that the only disciplinary action possible would > be 're-evaluating commits rights' which sounds like an euphemism for > removing commit access permanently. > I agree re-evaluating commit rights is weird, we should just strike it. > The new wording aims to make things clear, and make QA able to issue > short-term disciplinary actions without involving ComRel, similarly > to how Proctors work. Explanation for the individual points follows. > > Firstly, it aims to clearly define the domain of QA actions, and set > a better distinction between QA and ComRel. In this context, QA > is concerned whenever the developer's action technically affects Gentoo, > which includes breaking user systems, Infrastructure tooling, other > packages, etc. ComRel/Proctors on the other hand are concerned > in actions having social consequences rather than technical. > > Secondly, it clearly defines that the QA team can issue a temporary ban > (with the upper limit of 30 days, same as Proctors) via an internal team > vote. In this case there is no necessity of involving ComRel, and QA > can request executing this disciplinary decision straight from Infra. > > Thirdly, the old policy is clarified as applying to permanent bans. > In case of repeated offenses, QA requests ComRel to evaluate the case. > > Signed-off-by: Michał Górny > --- > glep-0048.rst | 14 +++++++++----- > 1 file changed, 9 insertions(+), 5 deletions(-) > > Changes in v3: > * improved the commit message to remove v1 cruft > * specified upper limit of ban length to 30 days > (lack of this was pointed out by ulm) > * removed duplicate notion of Council appeal > > diff --git a/glep-0048.rst b/glep-0048.rst > index f9773c0..8625b6f 100644 > --- a/glep-0048.rst > +++ b/glep-0048.rst > @@ -6,8 +6,8 @@ Type: Standards Track > Status: Final > Version: 2 > Created: 2006-04-24 > -Last-Modified: 2014-01-25 > -Post-History: 2006-04-24, 2006-09-05, 2011-06-08 > +Last-Modified: 2019-04-29 > +Post-History: 2006-04-24, 2006-09-05, 2011-06-08, 2019-04-12 > Content-Type: text/x-rst > --- > > @@ -76,9 +76,13 @@ tree policies are respected. > made by the council. > * Just because a particular QA violation has yet to cause an issue does > not > change the fact that it is still a QA violation. > -* If a particular developer persistently causes breakage, the QA team > - may request that Comrel re-evaluates that developer's commit rights. > - Evidence of past breakages will be presented with this request to > Comrel. > +* If a particular developer persistently causes QA violations (actions > that > + negatively impact the behavior of Gentoo systems, work of other > developers > + or infrastructure facilities), the QA team may issue a temporary > revocation > + of developer's commit access (ban), up to 30 days. In case of repeated > + offenses, the QA team may request that ComRel re-evaluates the commit > access. > + All the evidence of the violation, as well as ban length will be > evaluated > + and voted on by the QA team for each case individually. > "In the case of repeated offenses, the QA team may request that ComRel take appropriate disciplinary action against the developer." The "re-evaluates the commit access line" is ..weird, so I suggest replacing it. > * The QA team will maintain a list of current "QA Standards" with > explanations > as to why they are problems, and how to fix the problem. The list is > not > meant by any means to be a comprehensive document, but rather a dynamic > -- > 2.21.0 > > >