Re: [gentoo-project] Re: Trying to become a Gentoo Developer again spanning 8 years...

[Raymond Jennings]

On Fri, Oct 7, 2016 at 5:45 AM, Rich Freeman <rich0@g.o> wrote:
> On Fri, Oct 7, 2016 at 8:22 AM, Raymond Jennings <shentino@×××××.com>
> wrote:
>>  On Fri, Oct 7, 2016 at 4:58 AM, Rich Freeman <rich0@g.o>
>> wrote:
>>>
>>>  If somebody was harassing somebody else, and Comrel boots them,
>>> and it
>>>  turns out that they didn't file some information correctly, is it
>>>  better to let the booted dev back in and tell Comrel to boot them
>>>  again correctly this time?
>>
>>
>>  In my opinion, sorta
>>
>>  Appropriate procedure IMHO is:
>>
>>  1.  Make comrel redo the "paperwork" properly
>>  2.  Give comrel a deadline of 7 days to do so
>>  3.  If the new "paperwork" supports the booting, leave them booted
>>  4.  Otherwise, let the dev back in provisionally until they can be
>> booted
>>  correctly.
>>  4.a  It is probably implicit that the developer in question will be
>> on
>>  implied probation.
>>
>>  Letting a bad developer back in is bad for gentoo, but if they
>> really are
>>  provably bad then it should be easy for comrel to fix the
>> paperwork.  If
>>  they can't fix it in a timely manner, that's a sign that their
>> original case
>>  was messed up to begin with.
>
> Or maybe it is just a sign that Comrel is overworked, or doesn't put a
> lot of priority on such things?

My opinion is that if a developer is bad enough to keep out, its also 
important enough to get the paperwork fixed to prove it.  If they have 
a clean case it *should* be very easy to get the paperwork right.

>>  My main concern is making sure that a bad developer stays
>> booted...but also
>>  making sure comrel can prove they're bad.  Letting the bad paperwork
>>  stagnate in limbo is bad for everyone.
>
> Sure, but so is letting the bad dev back in.  Basically we're
> punishing the community because of a failure to go through due
> process.

But its the "due process" here that proves the developer is bad to 
begin with.  If comrel screwed up and there was a mistake and the 
developer is actually meritorious, its bad for gentoo to keep them out.

>>>  When somebody doesn't commit a package properly we tell them not
>>> to do
>>>  it again, and we make any appropriate fixes.
>>
>>  I'd prefer to make them fix it themselves, or at least ask for their
>>  permission to do it for them.
>
> That really depends.  If the tree is broken, it is against everybody's
> interests to just leave it that way until the original dev checks
> their email/irc/etc.  If the problem is minor, sure, let it wait.
> However, for a serious problem we might not have that luxury.

Agreed, and I was citing regressions as one such "serious problem"

There are special cases, yes.

>>  In my opinion, a trial court should be held responsible to do the
>> best job
>>  it possibly can.  An appeals court should be held responsible to
>> review the
>>  cases it gets to the best of its ability.  BOTH should treat their
>>  responsibilities with utmost care and should assume that any
>> mistake they
>>  make is NOT going to be caught.
>
> No argument.  But at the same time if Comrel currently has a backlog
> of cases they aren't dealing with then there is a cost to increasing
> the level of rigor.

What is the cost of *not* increasing the rigor?

Honestly, I see removing a good developer by mistake as a social 
version of a regression-type bug.

> That was one thing we didn't get a measure of.
> How many cases are brought to Comrel and not seriously evaluated due
> to lack of time?

Maybe comrel should adopt the same sort of "triage" procedures that 
ubuntu uses to classify bugs?

I think every comrel petition should be kept on record, and then we 
have a class-based priority for which ones get solved first.  Comrel 
stays as busy as it wants to, and it deals with the most important 
issues first.

A toxic asshole who is sabotaging the community and can do a lot of 
damage if not removed, would probably be a high priority case, for 
example.

If nothing else, the number of "lower priority" cases left dangling in 
"backlog" could be a useful statistic.

Also, I just realized that the "everyone votes" blocks comrel manpower 
from scaling.

What if each member of comrel was granted the discretion to handle 
everything as they themselves saw fit, subject to the provision that 
the comrel lead/comrel as a group/the council could receive appeals?

Judge Dredds all on a squad, but all of them watched by higher powers 
ot make sure they do the best they can and can have their badges guided 
or if necessary yanked if they screw up a decision.

>>>  That actually brings up a separate issue with how Comrel operates.
>>>  Right now the most common interpretation of the code of conduct
>>> says
>>>  that the only person who can appeal a Comrel decision is somebody
>>>  being punished by Comrel.  If dev A complains to Comrel about dev B
>>>  doing something wrong, and Comrel decides to take no action against
>>>  dev B, dev A has no recourse for appeal.
>>
>>  I think that dev A should have recourse for appeal...especially if
>> they or
>>  their gentoo work was hampered by dev B's actions.
>>
>>  But I should emphasize that dev A should have a valid basis for the
>> appeal,
>>  and it should be important enough that its worth the time of dev A
>> taking
>>  the time ot make the appeal instead of fixing it himself.
>
> Well, any dev should have a valid basis of appeal.  Right now we have
> few Comrel decisions in the first place, let alone appeals.  However,
> I'm aware of one appeal on the basis of Comrel inaction.  I don't
> think it is harmful to say that in that case the Council didn't feel
> Comrel had reached a point yet where escalation was necessary.
> However, that does create a bit of a challenge because Council doesn't
> really want to deal with the entire backlog of Comrel cases if Comrel
> isn't able to keep up.

See earlier point about letting individual comrel members having 
discretion to handle things on the spot Judge Dredd style...so long as 
they are supervised by someone who can evaluate their performance and 
if necessary intervene.

> Imagine if stale stablereqs could be appealed
> to Council...  :)

Maybe not stale stablereqs themselves.  This is a volunteer project 
with finite manpower.

However, someone deliberately *ignoring* a stablereq when there's a 
large need for it MIGHT be more worthy of an escalation.  But merely 
being overworked should not be an offense, and it would probably go 
through comrel first.

> --
> Rich
>