Re: [gentoo-project] How do you feel about non-contributing developers with commit access?

[Andrew Savchenko]

On Fri, 2 Nov 2018 16:43:28 +0000 M. J. Everitt wrote:
> On 02/11/18 16:22, Matthew Thode wrote:
> > On 18-11-02 16:05:35, Michał Górny wrote:
> >> Hello,
> >>
> >> The Undertakers team has frequently received various forms of
> >> 'criticism' of their effort in attempting to find and retire inactive
> >> developers.  This is getting as far as to claim that we shouldn't retire
> >> anyone because there are no limits on commit slots.
> >>
> >> Therefore, I would like to ask the wider community a general question:
> >> how do you feel about preserving commit access for people who no longer
> >> actively commit to Gentoo?  I'm talking about extreme cases, say,
> >> no commits to any user-visible repository for over a year.
> >>
> > I'm not sure the exact time, but I think it shouldn't be user-visable,
> > but 'Gentoo' that should ben what's looked at.
> >
> > As far as changing the developer to a non-committing developer, what
> > happens if they want to come back?  Would they need to retake the quiz,
> > re-find a mentor/recruiter, etc?
> >
> I have long felt that an automated 'devaway' process would actually be
> beneficial to Gentoo and other devs, etc, as it would be an easy way to see
> if someone was 'active' and accessible; whereas the existing one depends
> very much on someone talking on IRC, making commits, answering bugzilla or
> github requests or bikeshedding on the mailing lists. Devaway isn't
> properly used (in my experience) simply because people forget to set it. Or
> its ambiguous because someone sets it, and continues some form of visible
> activity with it set.
>
> The reason I say automated, as everybody would be independently held to the
> exact same standards uniformly, and whilst there are likely to be some
> exceptions, these are probably better use of human 'labour' than doing the
> whole job by hand. Also, there would be less confusion because it would be
> possible to write a policy/procedure for the 'bot'/automation, and emails
> could even be sent out automatically even, to warn potential candidates.
>
> I would also advocate a reduced "dev-refresher" "course" which the
> recruiters administer, which is a short form of the quizzes structure,
> simply to revisit some of the important salient topics, and any relevant
> updates in policy and practice which they might have missed in their absence.
>
> This shouldn't be an onerous procedure to implement, and should greatly aid
> the work of the retirement team to best use their limited resources to best
> effect; even if that means working around the tooling to make it efficient
> and effective to them.

Looks like you are misunderstanding devaway. This is an
informational message to the community about limited (but not
necassarily zero!) availability. If I read this correctly and you
are proposing to suspend commit access when devaway flag is set,
this is dubious at best.

E.g. this summer I was at hospital, I set devaway flag for estimated
period of unavailability. But when things got better, I was able to
fix some stuff and make some commits. Triggering devaway on and off
in such situation would be ridiculous.

Sometimes people have reduced, but not zero availability, e.g. when
travelling or visiting conferences. Devaway is useful in such cases
to inform community that response time may be bad, but still some
activity may be present.

Best regards,
Andrew Savchenko