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

[Rich Freeman]

On Fri, Oct 7, 2016 at 10:05 AM, Raymond Jennings <shentino@×××××.com> wrote:
> 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.

Sure, by all means leave the bug open until the paperwork is fixed,
but I don't think that means that the developer should be allowed back
in if the bug isn't closed before some deadline.

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

Sure, if all three of your preconditions are true I agree with your
conclusion.  However, if comrel screwed up and there was a mistake and
the developer is actually still a problem, then the solution is to fix
the mistakes, not keep them around.

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

I tend to agree with this, or a process where Comrel assigns a small
group of devs to each case.  The Comrel lead or maybe the entirety of
Comrel could keep a general eye on things as a level of QA and there
would still be Council appeals.  I've heard the issue raised that the
system where all of Comrel deals with every case also causes issues
when some members of Comrel aren't around or don't have time to deal
with every case.  Basically it makes all of Comrel as fast as its
slowest member.  Imagine if every stablereq required every member of
an arch team to approve it?  It would be like Ago trying to swim with
concrete shoes.

Indeed, with the model where all Comrel members deciding every case
recruiting more manpower to Comrel would actually have the ironic
effect of lowering their productivity.  The best thing you could do in
such a model is instead boot out the slowest contributors.

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

If you punish people for ignoring important bugs at times, then you
just encourage people to not sign up for the job in the first place.
If you have a single queue multiple server model (which is how most
projects tend to work, including arch teams), then the queue only
stalls if all the servers stall.  The solution in this case isn't to
kick out servers, but rather to encourage more to show up and deal
with the high priority bugs (the reality is that our servers don't
strictly work on bugs in priority order, though again I think that
trying to change this could actually lower throughput).  Even if a
server only closes one bug per year, that still has a net positive
impact on the queue (assuming zero overhead, which is mostly true for
the way we work).

-- 
Rich