Re: [gentoo-project] pre-GLEP: Gentoo Developer status

["Michał Górny" <mgorny@gentoo.org>]

W dniu nie, 15.04.2018 o godzinie 18∶55 +0200, użytkownik Francisco Blas
Izquierdo Riera (klondike) napisał:
> Hi Michał!
> 
> El 15/04/18 a las 14:22, Michał Górny escribió:
> > W dniu nie, 15.04.2018 o godzinie 13∶44 +0200, użytkownik Francisco Blas
> > Izquierdo Riera (klondike) napisał:
> > > Hi Michał!
> > > 
> > > El 14/04/18 a las 09:24, Michał Górny escribió:
> > > > W dniu pią, 13.04.2018 o godzinie 23∶28 +0200, użytkownik Francisco Blas
> > > > Izquierdo Riera (klondike) napisał:
> > > > > Hi Michał,
> > > > > 
> > > > > Taking into account that the letter and not the spirit of GLEP 39 is
> > > > > usually thrown around as a weapon ("INFORMATIVE", HAH!). I strongly
> > > > > disrecommend having more "informative" policies.
> > > > > 
> > > > > Not to say that whether you like it or not, not all non ebuild related
> > > > > developer work is necessarily tied to a project. Even GLEP 39 mentions
> > > > > this: "Not everything (or everyone) needs a project."
> > > > 
> > > > If you have a good example of a developer contributing to Gentoo without
> > > > having commit access and without being tied to a project, I'm all ears.
> > > 
> > > Here are some randomly picked tasks that don't require belonguing to a
> > > project:
> > > * Keeping the documentation on the wiki up to date and clear.
> > > * Writting new, relevant documentation.
> > > * Helping address users concerns over one of our official channels
> > > (forums, gentoo-user mailing list, IRC, etc.).
> > > * Helping users provide relevant information on bug reports.
> > 
> > Which of those tasks strictly require developer status?  That said, some
> > of them fall into scope of one or more project -- e.g. Forums project or
> > Bug Wranglers project.
> 
> None of them. In the same way it is not needed to be a developer to
> contribute ebuilds. But there is this thing called motivation and
> approval by their peers that tends to motivate most volunteers when
> there is no other incentives. Also:

Yes and no.  We are not giving 'free commit access' to contributors. 
Unlike, say, Wiki edits, accepting ebuilds from users involves
significant work on an existing developer with commit access (proxy
maintainer).  So it's not 'the same way'.

> * Being a developer makes new/changed documentation more turst worthy
> (and that can be particularly important in some cases=.

Given that our documentation is mostly hosted on Wiki, I'd like to point
out that I seriously doubt that most of our users check page history to
see who has written which part of the document.  I should also point out
that 'normally' Wikis are edited by everyone and their quality is
'assured' not by access restrictions but by large number of reviewers
who correct articles.

As a side note, I'm aware that some of the 'areas' of the wiki are
restricted to editing by developers.  However, there is no real
agreement about it and there are people who strongly believe that
documentation should be kept open for user edits.

> * Users are more likely to accept any input from a developer.
> * Users are more likely to follow directions by a developer.

This is somewhat correct.  However, the truth is most of the users are
also more likely to accept input from someone who behaves like he were
a developer even though he isn't one.  We have had a number of verbose
users on the mailing lists whose opinions were considered higher than
those of developers because they expressed them with a tone
of authority.

On the other hand, if you look through the Forums you'd notice how many
users actually follow bad advises given by non-developers.

> All of them things not "strictly" needed but particularly helpful for
> the cases I propose. Also keep in mind that the fact there is a project
> covering some of those cases doesn't mean that the specific developer is
> willing or needs to be part of it. You don't need to be part of bug
> wranglers to help with bug management. You don't need to be part of the
> forums project to answer questions on the forums nor you need to be part
> of the OPS project to assist users over IRC.

To some degree, yes.  However, the relevant projects still keep some
degree of power over the specific area.  As you mention, you don't have
to be part of bug-wranglers but you *need* to follow their rules.  If
you start wrangling bugs against the rules set by bug-wranglers, we
aren't going to be happy about it.

Plus, getting recruited involves someone confirming your skills
and mentoring you.  If your intent is to help in any of those areas, it
seems reasonable that someone *already working on them* should help you
and vouch for you.  Therefore, projects.

> > > All those are tasks making a very significant contribution to Gentoo.
> > > All of those are tasks that don't require being a member of any project
> > > to be performed, just having the relevant experience and skills.
> > > So here is my proof. Where is yours?
> > > 
> > > Also why have to be the project leads the one determining the activity
> > > non ebuild developers do? After all GLEP39 clearly states too: " Instead
> > > the practical responsibility of a lead is "whatever the members
> > > require", and if that isn't satisfied, the members can get a new lead
> > > (if they can find somebody to take the job!)." Which doesn't names
> > > "determining the activity non ebuild developers do". Or maybe could it
> > > be that you are planning to force project leads to define those
> > > activites in which case you should modify ALSO GLEP 39.
> > 
> > First of all, I should point out to you that 'GLEP 39' was created at
> > the time when 'developers' were only people having commit access.  While
> > people doing other tasks were called 'staffers' and therefore were not
> > covered by GLEP 39.  Is reducing their privileges what you're really
> > pursuing?
> 
> No, I'm pursuing that they are treated in the same way a developer is!
> 
> > That said, all I'm doing here is noting down the current Undertaker
> > policies.  The classification into two groups determines the two main
> > methods of checking developer's activity.  In case of developers with
> > repo/gentoo.git commit access, it is easy.  In case of the remaining
> > developers, this is much harder.
> > 
> > I think that so far the largest group of non-commit-access developers
> > were Forum project members.  Others were also contributing to some kind
> > of project (e.g. Infra).  The only reasonably tangible method were
> > querying the relevant projects to determine whether their members were
> > active and to establish a good way of measuring one's activity.
> > 
> > Of course, if you insist we could just say that Undertakers determine
> > the activity at their own accord, and retire people who are apparently
> > inactive without consulting the project leads.  However, that seems
> > inferior to the current practice.
> 
> This is not what I'm saying. In fact current practice is different from
> what you purvey:
> * Ebuild developers are usually asked about reassignment: see
> https://bugs.gentoo.org/show_bug.cgi?id=vapier or
> https://bugs.gentoo.org/show_bug.cgi?id=hwoarang
> * If they state they are interested in maintaining the packages they are
> allowed to do so (I guess unless the council decides to reassign them).

The fact is, what you perceive as current practice is pretty much
the 'optimistic' solution.  I don't think we really had many cases of
people who tried to abuse this to keep the developer status after really
stopping to contribute to Gentoo, and I don't think we really consider
it urgent to 'kick' them.  However, this doesn't mean that it wouldn't
happen if need so.

I don't like to point to specific people but we've recently retired
an ex-Forums project member who stopped contributing years ago
but wanted to keep the status.

> Here is a similar approach that would work for both:
> * Once a developer has been inactive for x time (for example not having
> voted on two consecutive council electiions), the developer is contacted
> by undertakers and asked whether he/she/it is still interested in Gentoo
> and has contributed soomething that went missing in this period.

This opens a loophole for people who keep the developer status only to
vote in elections.  Do you consider it fair to give the same level of
vote to people who spend many hours each week contributing to Gentoo,
and people who don't contribute at all but only keep the status to have
control over Gentoo?

> Undertakers also give a deadline for a reply.
> ** If the answer is afirmative and the developer sends some
> contributions the undertakers close the issue.
> ** If the answer is negative but the developer wants to continue
> contributing, the undertaker can provide advice on how to do so and
> extend the deadline a bit (after which the developer will be retired and
> invited to take the tests).
> ** If the answer is negative and the developer is okay with retiring,
> retirement is done.
> ** If no reply is obtained before the deadline, retirement is done.

Well, let me just summarize the problem: it is really hard to 'measure'
contributions.  We don't want to make people who contribute in unusual
ways to feel offended because Undertakers were not aware of this
(and yes, we also had pretty offensive behavior from people who
apparently were contributed in non-Undertaker visible ways).  We don't
want to create a huge catalog of possible contributions.  In the end, we
don't want to really end up judging quantities of contributions to
distinguish between people actually contributing and 'trying to work
around the mechanisms'.

That said, what you're saying is pretty much the case.  The main idea
with project leads is that they say Undertakers how to determine
the activity in specific areas in Gentoo.  In fact, we could take this
even further and say you don't have to be member of Forums, bug-
wranglers etc. -- but leads of those projects may be asked to verify
your contributions.

> Turns out that this is, in a way, the process documented on the
> Undertakers project itself: https://wiki.gentoo.org/wiki/Project:Undertakers
> 
> > What is the problem you're trying to solve here?  Are you just arguing
> > for the sake of arguing?  Or are you pursuing the concept of 'every
> > developer obtains his developer status forever, until he agrees to
> > retire'?
> 
> I'm saying that:
> * It is the responsability of the developers to provide signs of
> activity if none was detected.
> * It is usually a bad idea to forcefully retire an inactive developer as
> that person may not come back once its life circumstances change.
> 

This is really covered by Undertakers policy, and the GLEP explicitly
says it doesn't cover it.

-- 
Best regards,
Michał Górny