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

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

[Michał Górny]

Hi,

Here's a quick pre-GLEP for review.  It's a supplement to GLEP 39 that
defines who Gentoo Developer is (GLEP 39 mentions devs a lot but doesn't
say who they are).  Alike 39, it's purely information -- it doesn't
state a policy, just notes the status quo.  It is also minimal
and focuses on linking the policies of relevant teams.

Please review.

---
GLEP: 76
Title: Gentoo Developer status
Author: Michał Górny <mgorny@gentoo.org>
Type: Informational
Status: Draft
Version: 1
Created: 2018-04-11
Last-Modified: 2018-04-13
Post-History: 
Content-Type: text/x-rst
Requires: 39
Replaces: 
---

Abstract
========

This GLEP aims to supplement GLEP 39 [#GLEP39]_ with the definition
of *Gentoo Developer*.  It shortly indicates the policies relevant
to obtaining, preserving and revoking the Developer status.


Motivation
==========

Most of Gentoo's metastructure is explained in GLEP 39 [#GLEP39]_.
However, while this GLEP is focused around Gentoo Developers, it does
not define whom they precisely are.  It lacks a clear statement of how
new developers are recruited, and for how long they hold the developer
status.

The ‘status quo’ can be found across different Gentoo websites.
The recruitment procedure (from user perspective) is described
on the main site [#BECOME-A-DEV]_.  The Recruiters [#RECRUITERS]_,
Undertakers [#UNDERTAKERS]_ and Community Relation [#COMREL]_ teams
provide their relevant policies.  However, there seems to be no single
document binding all of them together.  This GLEP aims to be precisely
that.


Specification
=============

A *Gentoo Developer* is a person who has successfully passed
the recruitment procedure (as defined at the time of his/her joining)
and is actively contributing to Gentoo Linux in one or both
of the following areas:

1. Gentoo ebuild maintenance (either individual or through a project);
   with activity being determined through the official Gentoo repository
   commits.

2. Contributing to the present Gentoo projects [#PROJECTS]_; with
   activity being determined at the discretion of project leads.

The admission of new Developers is done by the *Recruiters* project
[#RECRUITERS]_ upon asserting that the candidate has the necessary
skills and motivation to actively contribute to Gentoo as outlined
above, provided recent contributions to the specified areas.  The exact
policies and procedures are specified by the Recruiters project.

The removal of Developers is done by the *Undertakers* project
[#UNDERTAKERS]_.  The Developer status can be revoked in one
of the following conditions:

- on an explicit request from the Developer himself/herself,

- upon determining that the Developer is no longer actively contributing
  to Gentoo,

- as a result of disciplinary action taken by the *Community Relations*
  project [#COMREL]_ or another explicitly authorized entity.

The exact policies and procedures are specified by the Undertakers
project.


Rationale
=========

This GLEP does not introduce any new policies but merely attempts to
document the current standing practices.  It aims to supplement GLEP 39
[#GLEP39]_ with the details necessary to understand who Gentoo
Developers are, in context of the metastructure defined there.
It does not mean to replace or thoroughly copy the relevant policies.

Only the details deemed most important and relevant are listed:
explanation whom Gentoo Developers are, what are their responsibilities,
what are the requirements for recruiting them and the possibilities of
their retirement.  The teams responsible for handling both of those
processes and defining the detailed policies are explicitly indicated.

The specific policy details were intentionally left out to avoid having
to perform frequent updates to this GLEP.  This includes the exact
procedures, ``repo/gentoo`` commit access, devaway system, etc.


References
==========

.. [#GLEP39] GLEP 39: An "old-school" metastructure proposal with "boot
   for being a slacker"
   (https://www.gentoo.org/glep/glep-0039.html)

.. [#BECOME-A-DEV] Become a developer - Gentoo Linux
   (https://www.gentoo.org/get-involved/become-developer/)

.. [#RECRUITERS] Project:Recruiters - Gentoo Wiki
   (https://wiki.gentoo.org/wiki/Project:Recruiters)

.. [#UNDERTAKERS] Project:Undertakers - Gentoo Wiki
   (https://wiki.gentoo.org/wiki/Project:Undertakers)

.. [#COMREL] Project:ComRel - Gentoo Wiki
   (https://wiki.gentoo.org/wiki/Project:ComRel)

.. [#PROJECTS] Project:Gentoo - Gentoo Wiki
   (https://wiki.gentoo.org/wiki/Project:Gentoo)


Copyright
=========
This work is licensed under the Creative Commons Attribution-ShareAlike
3.0 Unported License. To view a copy of this license, visit
http://creativecommons.org/licenses/by-sa/3.0/.

-- 
Best regards,
Michał Górny

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

[Francisco Blas Izquierdo Riera (klondike)]

[-- Attachment #1.1: Type: text/plain, Size: 5891 bytes --]

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

As a closing note, I'm really getting tired of all this "Either you
write ebuilds or you are a piece of shit" philosophy that is running on
the ambient nowadays. If such people want a developer centric source
based distro, who gives shit about the non developers I strongly
recommend trying Exherbo instead.

Klondike


El 13/04/18 a las 19:31, Michał Górny escribió:
> Hi,
>
> Here's a quick pre-GLEP for review.  It's a supplement to GLEP 39 that
> defines who Gentoo Developer is (GLEP 39 mentions devs a lot but doesn't
> say who they are).  Alike 39, it's purely information -- it doesn't
> state a policy, just notes the status quo.  It is also minimal
> and focuses on linking the policies of relevant teams.
>
> Please review.
>
> ---
> GLEP: 76
> Title: Gentoo Developer status
> Author: Michał Górny <mgorny@gentoo.org>
> Type: Informational
> Status: Draft
> Version: 1
> Created: 2018-04-11
> Last-Modified: 2018-04-13
> Post-History: 
> Content-Type: text/x-rst
> Requires: 39
> Replaces: 
> ---
>
> Abstract
> ========
>
> This GLEP aims to supplement GLEP 39 [#GLEP39]_ with the definition
> of *Gentoo Developer*.  It shortly indicates the policies relevant
> to obtaining, preserving and revoking the Developer status.
>
>
> Motivation
> ==========
>
> Most of Gentoo's metastructure is explained in GLEP 39 [#GLEP39]_.
> However, while this GLEP is focused around Gentoo Developers, it does
> not define whom they precisely are.  It lacks a clear statement of how
> new developers are recruited, and for how long they hold the developer
> status.
>
> The ‘status quo’ can be found across different Gentoo websites.
> The recruitment procedure (from user perspective) is described
> on the main site [#BECOME-A-DEV]_.  The Recruiters [#RECRUITERS]_,
> Undertakers [#UNDERTAKERS]_ and Community Relation [#COMREL]_ teams
> provide their relevant policies.  However, there seems to be no single
> document binding all of them together.  This GLEP aims to be precisely
> that.
>
>
> Specification
> =============
>
> A *Gentoo Developer* is a person who has successfully passed
> the recruitment procedure (as defined at the time of his/her joining)
> and is actively contributing to Gentoo Linux in one or both
> of the following areas:
>
> 1. Gentoo ebuild maintenance (either individual or through a project);
>    with activity being determined through the official Gentoo repository
>    commits.
>
> 2. Contributing to the present Gentoo projects [#PROJECTS]_; with
>    activity being determined at the discretion of project leads.
>
> The admission of new Developers is done by the *Recruiters* project
> [#RECRUITERS]_ upon asserting that the candidate has the necessary
> skills and motivation to actively contribute to Gentoo as outlined
> above, provided recent contributions to the specified areas.  The exact
> policies and procedures are specified by the Recruiters project.
>
> The removal of Developers is done by the *Undertakers* project
> [#UNDERTAKERS]_.  The Developer status can be revoked in one
> of the following conditions:
>
> - on an explicit request from the Developer himself/herself,
>
> - upon determining that the Developer is no longer actively contributing
>   to Gentoo,
>
> - as a result of disciplinary action taken by the *Community Relations*
>   project [#COMREL]_ or another explicitly authorized entity.
>
> The exact policies and procedures are specified by the Undertakers
> project.
>
>
> Rationale
> =========
>
> This GLEP does not introduce any new policies but merely attempts to
> document the current standing practices.  It aims to supplement GLEP 39
> [#GLEP39]_ with the details necessary to understand who Gentoo
> Developers are, in context of the metastructure defined there.
> It does not mean to replace or thoroughly copy the relevant policies.
>
> Only the details deemed most important and relevant are listed:
> explanation whom Gentoo Developers are, what are their responsibilities,
> what are the requirements for recruiting them and the possibilities of
> their retirement.  The teams responsible for handling both of those
> processes and defining the detailed policies are explicitly indicated.
>
> The specific policy details were intentionally left out to avoid having
> to perform frequent updates to this GLEP.  This includes the exact
> procedures, ``repo/gentoo`` commit access, devaway system, etc.
>
>
> References
> ==========
>
> .. [#GLEP39] GLEP 39: An "old-school" metastructure proposal with "boot
>    for being a slacker"
>    (https://www.gentoo.org/glep/glep-0039.html)
>
> .. [#BECOME-A-DEV] Become a developer - Gentoo Linux
>    (https://www.gentoo.org/get-involved/become-developer/)
>
> .. [#RECRUITERS] Project:Recruiters - Gentoo Wiki
>    (https://wiki.gentoo.org/wiki/Project:Recruiters)
>
> .. [#UNDERTAKERS] Project:Undertakers - Gentoo Wiki
>    (https://wiki.gentoo.org/wiki/Project:Undertakers)
>
> .. [#COMREL] Project:ComRel - Gentoo Wiki
>    (https://wiki.gentoo.org/wiki/Project:ComRel)
>
> .. [#PROJECTS] Project:Gentoo - Gentoo Wiki
>    (https://wiki.gentoo.org/wiki/Project:Gentoo)
>
>
> Copyright
> =========
> This work is licensed under the Creative Commons Attribution-ShareAlike
> 3.0 Unported License. To view a copy of this license, visit
> http://creativecommons.org/licenses/by-sa/3.0/.
>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 862 bytes --]

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

[Rich Freeman]

On Fri, Apr 13, 2018 at 5:28 PM, Francisco Blas Izquierdo Riera
(klondike) <klondike@gentoo.org> wrote:
>
> 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."
>
> As a closing note, I'm really getting tired of all this "Either you
> write ebuilds or you are a piece of shit" philosophy that is running on
> the ambient nowadays.

Care to cite an example of this?  I certainly haven't seen this
attitude displayed anywhere.  While there has been plenty of talk of
developers lately there has been lite mention of "ebuild developers"
specifically.  Any regular Gentoo contributor can be recognized as a
developer, and we have several who do not have commit access to the
main repo.  If there are regular contributors who are not developers I
certainly encourage them to apply to become developers.

In fact, the GLEP that was just posted is just another example of
this.  You pointed out that the section intended to make it clear that
non-ebuild-related developers are developers might not have been
worded properly.  Then you go on and complain about how nobody thinks
about non-ebuild developers, having just cited a policy intended to be
inclusive of them.

Honestly, I'm getting tired of the constant complaints that Gentoo
developers are embroiled in some kind of war against people who use
Gentoo.  Pretty-much everything they do is for the ultimate benefit of
Gentoo users.  People are throwing around accusations in some kind of
political game to create divisions where they don't exist, and drive
people further apart where they do.

I find it ironic that you're suggesting that the folks who disagree
with you leave, considering that this whole debate was started by a
bunch of people who basically felt that nobody should really be kicked
out for anything.

-- 
Rich

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 665 bytes --]

On 13/04/18 22:57, Rich Freeman wrote [excerpted]:
> I find it ironic that you're suggesting that the folks who disagree
> with you leave, considering that this whole debate was started by a
> bunch of people who basically felt that nobody should really be kicked
> out for anything.
>
The problem stems from the fact that there is (perceived to be) a
problem with the wrong kinds of people *being* ejected or disciplined,
whereas some people who *should* be ejected or disciplined, are not. And
obviously so. There is no even-handed or transparent application of
whatever "rules" are being applied, and this is seen to be unjust and
unacceptable ...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Rich Freeman]

On Fri, Apr 13, 2018 at 6:07 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> On 13/04/18 22:57, Rich Freeman wrote [excerpted]:
>> I find it ironic that you're suggesting that the folks who disagree
>> with you leave, considering that this whole debate was started by a
>> bunch of people who basically felt that nobody should really be kicked
>> out for anything.
>>
> The problem stems from the fact that there is (perceived to be) a
> problem with the wrong kinds of people *being* ejected or disciplined,
> whereas some people who *should* be ejected or disciplined, are not. And
> obviously so. There is no even-handed or transparent application of
> whatever "rules" are being applied, and this is seen to be unjust and
> unacceptable ...
>

Obviously I don't want to rehash this whole debate, but applying the
rules in a transparent way seems to be impossible without creating
legal risks.  I've yet to hear anything to the contrary from the
Trustees/etc.  So, it comes down to either trusting people to do this
well, or not doing it at all.  I'm certainly supportive of calls to
try to improve transparency where this is possible, such as with
anonymized stats published by comrel.

FWIW I've actually heard complaints at all levels within Gentoo about
double standards (coming from the top on down).  It is probably fair
to say that bad deeds can be offset by good deeds to a significant
degree around here, even if those deeds are of a different nature.
So, somebody with a strong negative technical/non-technical/social
contribution could be tolerated if they have a correspondingly strong
positive social/non-technical/technical contribution.  I've seen lots
of debate on both sides as to whether that is good or bad, but there
are certainly consequences for being too liberal with booting people
out, or keeping them around.

I haven't heard many appeals during my time on the Council, but from
the ones I have seen there were usually very good reasons for those
who were asked to leave, and those same people were generally not very
honest with the community about the reasons they were given for being
booted.  One form of transparency I have suggested is that when
disciplinary actions are given the person being disciplined should be
given an explanation for why the action is being taken, and that at
their option that explanation would be made public verbatim.  I've
seen Debian do this and I thought it was a good way to balance
privacy/transparency/risk.  The person being disciplined can at their
option keep the whole matter quiet, or they can have it publicized in
an official way.  However, if they decide to publish their own account
of events while denying Gentoo permission to publish its side, then
those listening will probably be skeptical that they're getting the
full story.  Since Gentoo would not make any public statements without
permission from the person impacted there would be little risk of
legal repercussions.

-- 
Rich

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 3436 bytes --]

On 13/04/18 23:25, Rich Freeman wrote:
> On Fri, Apr 13, 2018 at 6:07 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>> On 13/04/18 22:57, Rich Freeman wrote [excerpted]:
>>> I find it ironic that you're suggesting that the folks who disagree
>>> with you leave, considering that this whole debate was started by a
>>> bunch of people who basically felt that nobody should really be kicked
>>> out for anything.
>>>
>> The problem stems from the fact that there is (perceived to be) a
>> problem with the wrong kinds of people *being* ejected or disciplined,
>> whereas some people who *should* be ejected or disciplined, are not. And
>> obviously so. There is no even-handed or transparent application of
>> whatever "rules" are being applied, and this is seen to be unjust and
>> unacceptable ...
>>
> Obviously I don't want to rehash this whole debate, but applying the
> rules in a transparent way seems to be impossible without creating
> legal risks.  I've yet to hear anything to the contrary from the
> Trustees/etc.  So, it comes down to either trusting people to do this
> well, or not doing it at all.  I'm certainly supportive of calls to
> try to improve transparency where this is possible, such as with
> anonymized stats published by comrel.
>
> FWIW I've actually heard complaints at all levels within Gentoo about
> double standards (coming from the top on down).  It is probably fair
> to say that bad deeds can be offset by good deeds to a significant
> degree around here, even if those deeds are of a different nature.
> So, somebody with a strong negative technical/non-technical/social
> contribution could be tolerated if they have a correspondingly strong
> positive social/non-technical/technical contribution.  I've seen lots
> of debate on both sides as to whether that is good or bad, but there
> are certainly consequences for being too liberal with booting people
> out, or keeping them around.
>
> I haven't heard many appeals during my time on the Council, but from
> the ones I have seen there were usually very good reasons for those
> who were asked to leave, and those same people were generally not very
> honest with the community about the reasons they were given for being
> booted.  One form of transparency I have suggested is that when
> disciplinary actions are given the person being disciplined should be
> given an explanation for why the action is being taken, and that at
> their option that explanation would be made public verbatim.  I've
> seen Debian do this and I thought it was a good way to balance
> privacy/transparency/risk.  The person being disciplined can at their
> option keep the whole matter quiet, or they can have it publicized in
> an official way.  However, if they decide to publish their own account
> of events while denying Gentoo permission to publish its side, then
> those listening will probably be skeptical that they're getting the
> full story.  Since Gentoo would not make any public statements without
> permission from the person impacted there would be little risk of
> legal repercussions.
>
I think that if this is the process, people are more likely to buy into
it, and accept that if that's the way it works, they can take it or
leave it - and the risk is more theirs than that of the organisation. I
think that in itself will garner more respect than the current situation
at least ..


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Rich Freeman]

On Fri, Apr 13, 2018 at 6:29 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
> On 13/04/18 23:25, Rich Freeman wrote:
>
>> One form of transparency I have suggested is that when
>> disciplinary actions are given the person being disciplined should be
>> given an explanation for why the action is being taken, and that at
>> their option that explanation would be made public verbatim.  I've
>> seen Debian do this and I thought it was a good way to balance
>> privacy/transparency/risk.  The person being disciplined can at their
>> option keep the whole matter quiet, or they can have it publicized in
>> an official way.  However, if they decide to publish their own account
>> of events while denying Gentoo permission to publish its side, then
>> those listening will probably be skeptical that they're getting the
>> full story.  Since Gentoo would not make any public statements without
>> permission from the person impacted there would be little risk of
>> legal repercussions.
>>
> I think that if this is the process, people are more likely to buy into
> it, and accept that if that's the way it works, they can take it or
> leave it - and the risk is more theirs than that of the organisation. I
> think that in itself will garner more respect than the current situation
> at least ..
>

I hate to drag out this tangent further, but there is another matter
that I think that the community should probably vote on: whether
Comrel will accept testimony/evidence/complaints that will be withheld
from the target of the complaint.

Currently the policy is that this kind of evidence will be accepted,
which generates frustration because people feel like they cannot
confront their accuser.  The obvious defense of this policy is that
without it some would not come forward with legitimate complaints out
of fear of retaliation (by the person they're accusing, or others who
care about them), or just concern for having their names come up in
Google associated with the incident, since they might trust Gentoo to
keep it private but not the person they're having problems with.

I'm sure there are plenty of examples of organizations that do it
either way, and since we aren't an employer/etc I don't think we
really have any legal constraints here.

Either way the policy should be clear to anybody bringing forward a
complaint so that they can trust us to keep things confidential, or
not, in accordance with the policy.

-- 
Rich

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]

On Fri, Apr 13, 2018 at 6:41 PM, Rich Freeman <rich0@gentoo.org> wrote:

> On Fri, Apr 13, 2018 at 6:29 PM, M. J. Everitt <m.j.everitt@iee.org>
> wrote:
> > On 13/04/18 23:25, Rich Freeman wrote:
> >
> >> One form of transparency I have suggested is that when
> >> disciplinary actions are given the person being disciplined should be
> >> given an explanation for why the action is being taken, and that at
> >> their option that explanation would be made public verbatim.  I've
> >> seen Debian do this and I thought it was a good way to balance
> >> privacy/transparency/risk.  The person being disciplined can at their
> >> option keep the whole matter quiet, or they can have it publicized in
> >> an official way.  However, if they decide to publish their own account
> >> of events while denying Gentoo permission to publish its side, then
> >> those listening will probably be skeptical that they're getting the
> >> full story.  Since Gentoo would not make any public statements without
> >> permission from the person impacted there would be little risk of
> >> legal repercussions.
> >>
> > I think that if this is the process, people are more likely to buy into
> > it, and accept that if that's the way it works, they can take it or
> > leave it - and the risk is more theirs than that of the organisation. I
> > think that in itself will garner more respect than the current situation
> > at least ..
> >
>
> I hate to drag out this tangent further, but there is another matter
> that I think that the community should probably vote on: whether
> Comrel will accept testimony/evidence/complaints that will be withheld
> from the target of the complaint.
>
> Currently the policy is that this kind of evidence will be accepted,
> which generates frustration because people feel like they cannot
> confront their accuser.  The obvious defense of this policy is that
> without it some would not come forward with legitimate complaints out
> of fear of retaliation (by the person they're accusing, or others who
> care about them), or just concern for having their names come up in
> Google associated with the incident, since they might trust Gentoo to
> keep it private but not the person they're having problems with.
>
> I'm sure there are plenty of examples of organizations that do it
> either way, and since we aren't an employer/etc I don't think we
> really have any legal constraints here.
>
> Either way the policy should be clear to anybody bringing forward a
> complaint so that they can trust us to keep things confidential, or
> not, in accordance with the policy.
>

I'm totally supportive of this conversation, but I think its tough to be OP
and have your threads de-railed like this; I'd really prefer if we forked
this thread to have it.

Whether or not we should do any of these things is really orthogonal to
this GLEP which just seeks to clarify the existing state.

-A


>
> --
> Rich
>
>

[-- Attachment #2: Type: text/html, Size: 3865 bytes --]

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

[Raymond Jennings]

What about the whole "hold harmless" things that often pop up?

I think that, as a volunteer organization it's not unreasonable for
the foundation to have waivers in place.

Honestly, I think transparency is good overall, it helps the offender
understand their misdeeds.

If there are any legal risks then maybe new developers should be
agreeing to not sue the foundation.

My two cents.

On Fri, Apr 13, 2018 at 3:25 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Fri, Apr 13, 2018 at 6:07 PM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>> On 13/04/18 22:57, Rich Freeman wrote [excerpted]:
>>> I find it ironic that you're suggesting that the folks who disagree
>>> with you leave, considering that this whole debate was started by a
>>> bunch of people who basically felt that nobody should really be kicked
>>> out for anything.
>>>
>> The problem stems from the fact that there is (perceived to be) a
>> problem with the wrong kinds of people *being* ejected or disciplined,
>> whereas some people who *should* be ejected or disciplined, are not. And
>> obviously so. There is no even-handed or transparent application of
>> whatever "rules" are being applied, and this is seen to be unjust and
>> unacceptable ...
>>
>
> Obviously I don't want to rehash this whole debate, but applying the
> rules in a transparent way seems to be impossible without creating
> legal risks.  I've yet to hear anything to the contrary from the
> Trustees/etc.  So, it comes down to either trusting people to do this
> well, or not doing it at all.  I'm certainly supportive of calls to
> try to improve transparency where this is possible, such as with
> anonymized stats published by comrel.
>
> FWIW I've actually heard complaints at all levels within Gentoo about
> double standards (coming from the top on down).  It is probably fair
> to say that bad deeds can be offset by good deeds to a significant
> degree around here, even if those deeds are of a different nature.
> So, somebody with a strong negative technical/non-technical/social
> contribution could be tolerated if they have a correspondingly strong
> positive social/non-technical/technical contribution.  I've seen lots
> of debate on both sides as to whether that is good or bad, but there
> are certainly consequences for being too liberal with booting people
> out, or keeping them around.
>
> I haven't heard many appeals during my time on the Council, but from
> the ones I have seen there were usually very good reasons for those
> who were asked to leave, and those same people were generally not very
> honest with the community about the reasons they were given for being
> booted.  One form of transparency I have suggested is that when
> disciplinary actions are given the person being disciplined should be
> given an explanation for why the action is being taken, and that at
> their option that explanation would be made public verbatim.  I've
> seen Debian do this and I thought it was a good way to balance
> privacy/transparency/risk.  The person being disciplined can at their
> option keep the whole matter quiet, or they can have it publicized in
> an official way.  However, if they decide to publish their own account
> of events while denying Gentoo permission to publish its side, then
> those listening will probably be skeptical that they're getting the
> full story.  Since Gentoo would not make any public statements without
> permission from the person impacted there would be little risk of
> legal repercussions.
>
> --
> Rich
>

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

[Rich Freeman]

On Fri, Apr 13, 2018 at 9:05 PM, Raymond Jennings <shentino@gmail.com> wrote:
>
> If there are any legal risks then maybe new developers should be
> agreeing to not sue the foundation.
>

Two issues with that:

1.  Comrel doesn't exclusively deal with developers.  That said,
unless our media is whitelisted there might not be much we can do
about non-devs unless they're cooperative.
1a.  A possible way to mitigate this is to make step 1 of any Comrel
interaction with a non-dev to ask them if they're willing to agree to
not sue.  If they aren't then they are automatically booted with no
further interaction.  I'm not sure this really makes anybody happier
but it would be a way to reconcile this issue.
2.  In the US at least you can't really agree to not sue somebody
unconditionally.  You can sign something that says that you do, but it
isn't likely to be upheld by a court.  You can give up your right to
sue in specific ways, but courts will generally only accept this to
the extent that the deal is seen as fair/etc.

Most organizations that require their members/employees/etc to sign
such agreements STILL keep such proceedings private for this reason.
That, and out of an interest in not turning every single HR issue into
a circus.  Keep in mind that Comrel's goal in interacting with
somebody should be primarily to help them to get along with everybody,
not just to kick them out, and IMO keeping things private makes it
easier to re-integrate.

I'm not saying that asking Foundation members not to sue isn't a bad
idea, but I don't know that it would accomplish much.  I doubt that it
would protect the Foundation against accusations of slander, or
against shareholder lawsuits, and those are probably the two biggest
areas of risk where suits from members are concerned.

-- 
Rich

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

[Alec Warner]

[-- Attachment #1: Type: text/plain, Size: 7057 bytes --]

On Fri, Apr 13, 2018 at 5:28 PM, Francisco Blas Izquierdo Riera (klondike) <
klondike@gentoo.org> wrote:

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

I think this is a gap in the GLEP wording. It claims a developer must
contribute either in a repo or to some project.

However undertakers don't retire people who respond to Gentoo mail,
regardless of active project affiliation. This seems to
leave a gap where people are not contributing to Gentoo in repos or in an
active project, but are also not retired.

Note that there is also no significant procedure for making a 'project'. So
if I was about to be retired I could just make a new project, elect myself
lead and then claim I was an active contributor and there is no policy
against this. I tend to think the undertakers realize this and that is how
we ended up with the current retirement policy (with the gap.)


> As a closing note, I'm really getting tired of all this "Either you
> write ebuilds or you are a piece of shit" philosophy that is running on
> the ambient nowadays. If such people want a developer centric source
> based distro, who gives shit about the non developers I strongly
> recommend trying Exherbo instead.




> Klondike
>
>
> El 13/04/18 a las 19:31, Michał Górny escribió:
> > Hi,
> >
> > Here's a quick pre-GLEP for review.  It's a supplement to GLEP 39 that
> > defines who Gentoo Developer is (GLEP 39 mentions devs a lot but doesn't
> > say who they are).  Alike 39, it's purely information -- it doesn't
> > state a policy, just notes the status quo.  It is also minimal
> > and focuses on linking the policies of relevant teams.
> >
> > Please review.
> >
> > ---
> > GLEP: 76
> > Title: Gentoo Developer status
> > Author: Michał Górny <mgorny@gentoo.org>
> > Type: Informational
> > Status: Draft
> > Version: 1
> > Created: 2018-04-11
> > Last-Modified: 2018-04-13
> > Post-History:
> > Content-Type: text/x-rst
> > Requires: 39
> > Replaces:
> > ---
> >
> > Abstract
> > ========
> >
> > This GLEP aims to supplement GLEP 39 [#GLEP39]_ with the definition
> > of *Gentoo Developer*.  It shortly indicates the policies relevant
> > to obtaining, preserving and revoking the Developer status.
> >
> >
> > Motivation
> > ==========
> >
> > Most of Gentoo's metastructure is explained in GLEP 39 [#GLEP39]_.
> > However, while this GLEP is focused around Gentoo Developers, it does
> > not define whom they precisely are.  It lacks a clear statement of how
> > new developers are recruited, and for how long they hold the developer
> > status.
> >
> > The ‘status quo’ can be found across different Gentoo websites.
> > The recruitment procedure (from user perspective) is described
> > on the main site [#BECOME-A-DEV]_.  The Recruiters [#RECRUITERS]_,
> > Undertakers [#UNDERTAKERS]_ and Community Relation [#COMREL]_ teams
> > provide their relevant policies.  However, there seems to be no single
> > document binding all of them together.  This GLEP aims to be precisely
> > that.
> >
> >
> > Specification
> > =============
> >
> > A *Gentoo Developer* is a person who has successfully passed
> > the recruitment procedure (as defined at the time of his/her joining)
> > and is actively contributing to Gentoo Linux in one or both
> > of the following areas:
> >
> > 1. Gentoo ebuild maintenance (either individual or through a project);
> >    with activity being determined through the official Gentoo repository
> >    commits.
> >
> > 2. Contributing to the present Gentoo projects [#PROJECTS]_; with
> >    activity being determined at the discretion of project leads.
> >
> > The admission of new Developers is done by the *Recruiters* project
> > [#RECRUITERS]_ upon asserting that the candidate has the necessary
> > skills and motivation to actively contribute to Gentoo as outlined
> > above, provided recent contributions to the specified areas.  The exact
> > policies and procedures are specified by the Recruiters project.
> >
> > The removal of Developers is done by the *Undertakers* project
> > [#UNDERTAKERS]_.  The Developer status can be revoked in one
> > of the following conditions:
> >
> > - on an explicit request from the Developer himself/herself,
> >
> > - upon determining that the Developer is no longer actively contributing
> >   to Gentoo,
> >
> > - as a result of disciplinary action taken by the *Community Relations*
> >   project [#COMREL]_ or another explicitly authorized entity.
> >
> > The exact policies and procedures are specified by the Undertakers
> > project.
> >
> >
> > Rationale
> > =========
> >
> > This GLEP does not introduce any new policies but merely attempts to
> > document the current standing practices.  It aims to supplement GLEP 39
> > [#GLEP39]_ with the details necessary to understand who Gentoo
> > Developers are, in context of the metastructure defined there.
> > It does not mean to replace or thoroughly copy the relevant policies.
> >
> > Only the details deemed most important and relevant are listed:
> > explanation whom Gentoo Developers are, what are their responsibilities,
> > what are the requirements for recruiting them and the possibilities of
> > their retirement.  The teams responsible for handling both of those
> > processes and defining the detailed policies are explicitly indicated.
> >
> > The specific policy details were intentionally left out to avoid having
> > to perform frequent updates to this GLEP.  This includes the exact
> > procedures, ``repo/gentoo`` commit access, devaway system, etc.
> >
> >
> > References
> > ==========
> >
> > .. [#GLEP39] GLEP 39: An "old-school" metastructure proposal with "boot
> >    for being a slacker"
> >    (https://www.gentoo.org/glep/glep-0039.html)
> >
> > .. [#BECOME-A-DEV] Become a developer - Gentoo Linux
> >    (https://www.gentoo.org/get-involved/become-developer/)
> >
> > .. [#RECRUITERS] Project:Recruiters - Gentoo Wiki
> >    (https://wiki.gentoo.org/wiki/Project:Recruiters)
> >
> > .. [#UNDERTAKERS] Project:Undertakers - Gentoo Wiki
> >    (https://wiki.gentoo.org/wiki/Project:Undertakers)
> >
> > .. [#COMREL] Project:ComRel - Gentoo Wiki
> >    (https://wiki.gentoo.org/wiki/Project:ComRel)
> >
> > .. [#PROJECTS] Project:Gentoo - Gentoo Wiki
> >    (https://wiki.gentoo.org/wiki/Project:Gentoo)
> >
> >
> > Copyright
> > =========
> > This work is licensed under the Creative Commons Attribution-ShareAlike
> > 3.0 Unported License. To view a copy of this license, visit
> > http://creativecommons.org/licenses/by-sa/3.0/.
> >
>
>
>

[-- Attachment #2: Type: text/html, Size: 9538 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

>>>>> On Fri, 13 Apr 2018, Francisco Blas Izquierdo Riera (klondike) wrote:

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

Sorry, but I don't understand what you are talking about. GLEP types
are defined in GLEP 1 [1]:

,----
| A Standards Track GLEP describes a new feature or implementation
| for Gentoo Linux. An Informational GLEP provides general guidelines
| or information to the Gentoo Linux community, but does not propose
| a new feature.
`----

Michał's GLEP doesn't describe any new feature, but aims to document
current practice. Therefore it cannot be of type "Standards Track".

> [...]

> As a closing note, I'm really getting tired of all this "Either you
> write ebuilds or you are a piece of shit" philosophy that is running
> on the ambient nowadays. If such people want a developer centric
> source based distro, who gives shit about the non developers I
> strongly recommend trying Exherbo instead.

This is not helpful.

Ulrich

[1] https://www.gentoo.org/glep/glep-0001.html#kinds-of-gleps

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Francisco Blas Izquierdo Riera (klondike)]

[-- Attachment #1.1: Type: text/plain, Size: 1914 bytes --]

Hi Ulm!

El 14/04/18 a las 07:59, Ulrich Mueller escribió:
>>>>>> On Fri, 13 Apr 2018, Francisco Blas Izquierdo Riera (klondike) wrote:
>> 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.
> Sorry, but I don't understand what you are talking about. GLEP types
> are defined in GLEP 1 [1]:
>
> ,----
> | A Standards Track GLEP describes a new feature or implementation
> | for Gentoo Linux. An Informational GLEP provides general guidelines
> | or information to the Gentoo Linux community, but does not propose
> | a new feature.
> `----
>
> Michał's GLEP doesn't describe any new feature, but aims to document
> current practice. Therefore it cannot be of type "Standards 

You are deviating the topic here. Informative GLEPs:
* Are enforced.
* Are accepted as a valid argument without trying to check whether their
contents still apply (and no that doesn't mean that it is not marked as
Replaced, Moribund or Deferred, it means that their contents are actual
and relevant).

If you want to document the current lifecycle of Gentoo Developers it's
a better idea to, for example, go and update the Developer Handbook
https://wiki.gentoo.org/wiki/Project:ComRel/Developer_Handbook Because
anything that is stated in a GLEP will be enforced even if said GLEP is
"informative".

>> As a closing note, I'm really getting tired of all this "Either you
>> write ebuilds or you are a piece of shit" philosophy that is running
>> on the ambient nowadays. If such people want a developer centric
>> source based distro, who gives shit about the non developers I
>> strongly recommend trying Exherbo instead.
> This is not helpful.

Having second class contributors isn't either and that is exactly what
this GLEP proposes.

Klondike



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 862 bytes --]

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

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 1449 bytes --]

>>>>> On Sun, 15 Apr 2018, Francisco Blas Izquierdo Riera (klondike) wrote:

> You are deviating the topic here. Informative GLEPs:

It is "Informational" not "Informative".

> * Are enforced.
> * Are accepted as a valid argument without trying to check whether
> their contents still apply (and no that doesn't mean that it is not
> marked as Replaced, Moribund or Deferred, it means that their
> contents are actual and relevant).

Maybe this applies to GLEP 39. That is an exceptional case though,
because it hasn't followed the normal GLEP process, but was accepted
by a vote of all developers. The GLEP format was only chosen because
it was a convenient means to publish it (and I guess also because its
predecessor had been published as GLEP 4).

> If you want to document the current lifecycle of Gentoo Developers it's
> a better idea to, for example, go and update the Developer Handbook
> https://wiki.gentoo.org/wiki/Project:ComRel/Developer_Handbook
> Because anything that is stated in a GLEP will be enforced even if
> said GLEP is "informative".

> Having second class contributors isn't either and that is exactly
> what this GLEP proposes.

Do you really read it in that way? We previously had a distinction
between developers who could commit to the gentoo-x86 repository and
staffers who could not, but IIUC this has largely been dropped. I
don't think the intention of mgorny's pre-GLEP is to reinstate that
distinction.

Ulrich

[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]

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

[Michał Górny]

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.

> As a closing note, I'm really getting tired of all this "Either you
> write ebuilds or you are a piece of shit" philosophy that is running on
> the ambient nowadays. If such people want a developer centric source
> based distro, who gives shit about the non developers I strongly
> recommend trying Exherbo instead.
> 

This is highly inappropriate, especially given that you are a public
representative of Gentoo.  The GLEP *explicitly* defines that there are
both ebuild and non-ebuild contributions, so whatever you're making up,
it's irrelevant to the topic at hand.

-- 
Best regards,
Michał Górny

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

[Francisco Blas Izquierdo Riera (klondike)]

[-- Attachment #1.1: Type: text/plain, Size: 3049 bytes --]

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.

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.

>> As a closing note, I'm really getting tired of all this "Either you
>> write ebuilds or you are a piece of shit" philosophy that is running on
>> the ambient nowadays. If such people want a developer centric source
>> based distro, who gives shit about the non developers I strongly
>> recommend trying Exherbo instead.
>>
> This is highly inappropriate, especially given that you are a public
> representative of Gentoo.

If you want to play the "you more" game I strongly recommend you read
Matthew 7:5.

> The GLEP *explicitly* defines that there are
> both ebuild and non-ebuild contributions, so whatever you're making up,
> it's irrelevant to the topic at hand.

The GLEP defines different requirements for those two sets of peoples
with the second set having harsher constraints (i.e. not having the
possibility of having their contributions not being filtered by a third
party). This second group happens to be "non-ebuild contributors". So
maybe, instead of trying to insult me a "non-ebuild contributor" you
could consider looking at the moon instead of the finger.

Klondike


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 862 bytes --]

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

[Rich Freeman]

On Sun, Apr 15, 2018 at 7:44 AM, Francisco Blas Izquierdo Riera
(klondike) <klondike@gentoo.org> wrote:
>
> 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.

Wiki project

> * Writting new, relevant documentation.

That seems redundant with the wiki, since that is where we keep our docs.

> * Helping address users concerns over one of our official channels

Comrel project?

> (forums, gentoo-user mailing list, IRC, etc.).

Forums, PR projects.  So far we haven't had anybody become a dev
merely on the basis of hanging out on IRC/gentoo-user that I'm aware
of, though this certainly seems like it could be a project.

> * Helping users provide relevant information on bug reports.

Bug-wrangler project.

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

Sure, but so far I don't think anybody has actually become a developer
NOT being on a project.  Also, I suspect that if somebody did want to
contribute ONLY in one of those areas they'd be a perfect candidate to
create and lead such a project where one doesn't exist.

> 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!)."

Project leads don't generally dictate what project members work on.
They might have a coordination or dispute resolution role.

And there is nothing that says a project lead has to be an ebuild developer.

This assumes some kind of adversarial relationship between project
leads and their members, when in fact as you point out the leads are
chosen BY the project members.

>
>> The GLEP *explicitly* defines that there are
>> both ebuild and non-ebuild contributions, so whatever you're making up,
>> it's irrelevant to the topic at hand.
>
> The GLEP defines different requirements for those two sets of peoples
> with the second set having harsher constraints (i.e. not having the
> possibility of having their contributions not being filtered by a third
> party). This second group happens to be "non-ebuild contributors".

This is reasonable to point out (IMO), though again I think you're
assuming some kind of hostile intent here where I don't think it is
warranted.  I believe the intent here is to describe the status quo,
which will of course require some care since the status quo wasn't
well-defined previously.

Do you have any suggestions for better wording here?  Are you
advocating for requiring all developers to be members or a project, or
do you have a better way to define the qualifications for developer
status that does not invoke projects?

-- 
Rich

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

[Michał Górny]

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.

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

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.

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

> > The GLEP *explicitly* defines that there are
> > both ebuild and non-ebuild contributions, so whatever you're making up,
> > it's irrelevant to the topic at hand.
> 
> The GLEP defines different requirements for those two sets of peoples
> with the second set having harsher constraints (i.e. not having the
> possibility of having their contributions not being filtered by a third
> party). This second group happens to be "non-ebuild contributors". So
> maybe, instead of trying to insult me a "non-ebuild contributor" you
> could consider looking at the moon instead of the finger.
> 

No, I haven't been trying to insult you so far.  What has been happening
here is that *you* have been trying to picture yourself as a potential
victim of insults from 'bad' Gentoo developers who apparently don't
appreciate your 'contributions' to Gentoo.

-- 
Best regards,
Michał Górny

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

[Francisco Blas Izquierdo Riera (klondike)]

[-- Attachment #1.1: Type: text/plain, Size: 6640 bytes --]

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:
* Being a developer makes new/changed documentation more turst worthy
(and that can be particularly important in some cases=.
* Users are more likely to accept any input from a developer.
* Users are more likely to follow directions by a developer.

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.

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

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

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.





[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 862 bytes --]

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 3185 bytes --]

On 15/04/18 17:55, Francisco Blas Izquierdo Riera (klondike) wrote:
> 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).
>
> 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.
> 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.
>
> Turns out that this is, in a way, the process documented on the
> Undertakers project itself: https://wiki.gentoo.org/wiki/Project:Undertakers
>
I have long thought there could be improvements to the Undertakers
process, and I think developers that have been MIA for some time (for
whatever circumstances) have some checks made that they are indeed
up-to-speed with any policy changes that may have happened since their
last 'active' period. This would be not to penalise them, but ensure
that the Quality standards that Gentoo holds, are upheld, and devs don't
get to run riot once their initial 'assessment' and recruitment phases
are over. It would provide a better 'continual development' track that
could be expanded into other areas if proven and desirable.

My ideas went so far as:
-- if Dev does not set Devaway, and/or devaway period is over ~6months
(say) and activity has fallen to zero .. commit privs get automatically
revoked (by script, not by human). An automated email is sent out to
that Dev, encouraging them to contact [insert project here] (eg.
Council, ComReS, DevRel, etc) if there is good reason for the absence,
the privs can be reinstated after a petition has been received and reviewed.
-- A fast-track re-fresher training is provided by Recruiters, which
brings an existing or elapsed dev back up to current standards. Such
topics as new EAPIs, QA tracks, and policy updates could be covered in a
couple of 'sessions' and then commit privs can be reinstated.

I think this would improve the situation where some devs commit in large
'bursts' in between significant lapses in activity, causing a lot of
distress to other more regular contributors and disrupting some of the
more consistent ongoing efforts.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On Sun, 15 Apr 2018 18:22:48 +0100
"M. J. Everitt" <m.j.everitt@iee.org> wrote:

> -- if Dev does not set Devaway, and/or devaway period is over ~6months
> (say) and activity has fallen to zero .. commit privs get automatically
> revoked (by script, not by human). An automated email is sent out to
> that Dev, encouraging them to contact [insert project here] (eg.
> Council, ComReS, DevRel, etc) if there is good reason for the absence,
> the privs can be reinstated after a petition has been received and reviewed.

The problem here is that not all contribution is "visible" on any
metrics system.

This is only useful in regards to measuring *commit* contribution.

But there are many other ways to contribute to Gentoo, and not all of
them monitorable by automated tools.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Robin H. Johnson]

On Mon, Apr 23, 2018 at 05:24:41AM +1200, Kent Fredric wrote:
> On Sun, 15 Apr 2018 18:22:48 +0100
> "M. J. Everitt" <m.j.everitt@iee.org> wrote:
> 
> > -- if Dev does not set Devaway, and/or devaway period is over ~6months
> > (say) and activity has fallen to zero .. commit privs get automatically
> > revoked (by script, not by human). An automated email is sent out to
> > that Dev, encouraging them to contact [insert project here] (eg.
> > Council, ComReS, DevRel, etc) if there is good reason for the absence,
> > the privs can be reinstated after a petition has been received and reviewed.
> 
> The problem here is that not all contribution is "visible" on any
> metrics system.
> 
> This is only useful in regards to measuring *commit* contribution.
> 
> But there are many other ways to contribute to Gentoo, and not all of
> them monitorable by automated tools.
In one of the threads leading up to this pre-GLEP, I proposed a
requiring testable metrics for all activity. It was dropped for
simplicity, as it's probably something that would merit it's own GLEP.

It would NOT be a way to measure >1 contribution, but just a way to show
the date of last contribution for each project where a dev is active.
Specifically it would NOT disclose what that action was (because the
action in itself may be protected/private information).

Commits: last commit date (on both public & private repos).
Bugzilla: last comment OR action date (even if the bug is private)
Forums: date of last post OR mod-action (even if the post or mod-action
        is in a hidden/private forum)

Bugzilla & Commits already do this effectively, it would be exposing the
data more readily, and adding similar functionality for other projects.

Think like an IRC bot responding to '!seen', but it only tells you when
the person was seen [optionally for a specific project], and not exactly
what they were saying/doing.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Treasurer
E-Mail   : robbat2@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136

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

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 2361 bytes --]

On 23/04/18 21:01, Robin H. Johnson wrote:
> On Mon, Apr 23, 2018 at 05:24:41AM +1200, Kent Fredric wrote:
>> On Sun, 15 Apr 2018 18:22:48 +0100
>> "M. J. Everitt" <m.j.everitt@iee.org> wrote:
>>
>>> -- if Dev does not set Devaway, and/or devaway period is over ~6months
>>> (say) and activity has fallen to zero .. commit privs get automatically
>>> revoked (by script, not by human). An automated email is sent out to
>>> that Dev, encouraging them to contact [insert project here] (eg.
>>> Council, ComReS, DevRel, etc) if there is good reason for the absence,
>>> the privs can be reinstated after a petition has been received and reviewed.
>> The problem here is that not all contribution is "visible" on any
>> metrics system.
>>
>> This is only useful in regards to measuring *commit* contribution.
>>
>> But there are many other ways to contribute to Gentoo, and not all of
>> them monitorable by automated tools.
> In one of the threads leading up to this pre-GLEP, I proposed a
> requiring testable metrics for all activity. It was dropped for
> simplicity, as it's probably something that would merit it's own GLEP.
>
> It would NOT be a way to measure >1 contribution, but just a way to show
> the date of last contribution for each project where a dev is active.
> Specifically it would NOT disclose what that action was (because the
> action in itself may be protected/private information).
>
> Commits: last commit date (on both public & private repos).
> Bugzilla: last comment OR action date (even if the bug is private)
> Forums: date of last post OR mod-action (even if the post or mod-action
>         is in a hidden/private forum)
>
> Bugzilla & Commits already do this effectively, it would be exposing the
> data more readily, and adding similar functionality for other projects.
>
> Think like an IRC bot responding to '!seen', but it only tells you when
> the person was seen [optionally for a specific project], and not exactly
> what they were saying/doing.
>
I'm inclined to support the idea that <something> is marginally better
than <nothing> and could be used as some form of evidence should there
be need to substantiate a claim either way, and make it much less
subjective ...

Not looking for a perfect solution here, that IS impossible, just
something that would aid metrics...


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

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

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]

On Mon, 23 Apr 2018 22:30:21 +0100
"M. J. Everitt" <m.j.everitt@iee.org> wrote:

> I'm inclined to support the idea that <something> is marginally better
> than <nothing> and could be used as some form of evidence should there
> be need to substantiate a claim either way, and make it much less
> subjective ...
> 
> Not looking for a perfect solution here, that IS impossible, just
> something that would aid metrics...

Agreed. Its useful in one direction, to say "Look, they're active, proof!",
but can't be used to say "Look, they're INACTIVE".

Similar to how a Bloom Filter can be used to say:

  "We definitely did not see this item before"

But can't be used to say

  "We definitely saw this item before"

Subsequently, an automated "you're inactive, so drop your commit
rights" bot can't exist, as it can only determine if you're factually
active, not factually inactive.


It could at best aggregate these sources and produce a list of gentoo
devs that are /possibly/ inactive, but not /certainly/ inactive.

And humans can then scour that list and attempt to verify the activity
status.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michał Górny]

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

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

[Francisco Blas Izquierdo Riera (klondike)]

[-- Attachment #1.1: Type: text/plain, Size: 15539 bytes --]

Hi Michał!

El 15/04/18 a las 19:58, Michał Górny escribió:
> 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'.

You are misinterpreting the argument here and providing a straw man. Do
all developers need "free commit access"? No. Do any developers need
"free commit access"? No as long as they can proxy commits through other
developers who have access to the parts of the tree that developer can't
access in this hypothetical case. Is it helpful for some developer to
have "free commit access"? Yes, a clear example maybe AT.

The fact is that when a developer comments on a bug, bugzilla shows a
dev mark. When a developer posts to a mailing list it uses a gentoo.org
address. When a developer uses IRC it has a gentoo cloak. The only
exception is the wiki and even that is something that maybe should be
considered. Turns out all of these things help developers perform some
of the above mentioned tasks in a more efficient way, just in the same
way that giving full tree access does for some tree related tasks.

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

You go explain that to the Gentoo Hardened users, will you? In fact that
was one of the reasons to have the Gentoo Hardened project pages
protected on wiki migration, keeping the reliability of the doc. So
whilst maybe not for you, we have a subset of users for which being able
to go back to a version of the document verified by a developer provides
a lot of value.

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

Or maybe because of their history. The gentoo.org address is a hint at
the existence of prior good contributions by somebody but is not the
only one. Users are more likely to trust and hold higher opinion on
those who have helped them in the past.

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

For this argument to be valid you'll have to consider only the cases
where bad advice was provided by a non-dev and good advice was provided
by a dev within a reasonable amount of time. Mostly because if no good
advise is provided by a developer or it is provided too late, the user
will follow the bad advice as it was the only input that person got.

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

At the beginning yes, but people change over time and so may do their
contributions. Sunrise project is dead, X11
https://wiki.gentoo.org/wiki/Project:X11 doesn't list you as a member
and these two where the projects that scarabeus mentioned in your
developer recruitment bug. Like you a non ebuild developer may still be
contributing to areas other than these in which it began its career and
it may do so without even belonging to a project.


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

So why don't just update the undertakers policy to account for such
cases then? Anyways a developer who is not happy about its retirement is
likely to ask council to address the issue.

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

No, but somebody who hasn't voted in elections for say two years is
probably inactive (or not interested), that is why the clause is "for
example" and not "only and only if".

That said, I'm going to give you a different question: "Do you consider
it fair to give the same level of vote to people who spend many hours
each week contributing to Gentoo without keeping up with any policy
changes unless pointed to making other people lose time as to people who
make small contributions now and then but actively keep themselves up to
date so that these have high value and require little or no work from
others?"

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

The point you are missing is that project leads may not be aware of a
specific developer's contributions, but a developer is expected to, at
least, know which its most significant ones were.

Also I'm not expecting undertakers to measure contributions, just to
reason if they are positive for the project in some way. In general it's
an awful idea to retire anybody who has even a small positive impact on
Gentoo because then you are likely to go from small positive impact to
no impact at all.

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


Where? In the "However, there seems to be no single document binding all
of them together. This GLEP aims to be precisely that." Because that
pretty much sounds as "This document replaces said policies by bringing
them together" to me. 


To prove my point here is a different definition:

A *Gentoo Developer* is a person who has successfully passed the
recruitment procedure (as defined at the time of his/her joining) and is
making positive contributions to Gentoo Linux project in some way.

Simple, straightforward and keeps every developer under the same
standards in particular "making positive contributions to Gentoo Linux
project in some way".

Klondike

PS: Sending this also to gentoo-project as I didn't add the address before.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 862 bytes --]

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

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 5502 bytes --]

On 18-04-13 19:31:37, Michał Górny wrote:
> Hi,
> 
> Here's a quick pre-GLEP for review.  It's a supplement to GLEP 39 that
> defines who Gentoo Developer is (GLEP 39 mentions devs a lot but doesn't
> say who they are).  Alike 39, it's purely information -- it doesn't
> state a policy, just notes the status quo.  It is also minimal
> and focuses on linking the policies of relevant teams.
> 
> Please review.
> 
> ---
> GLEP: 76
> Title: Gentoo Developer status
> Author: Michał Górny <mgorny@gentoo.org>
> Type: Informational
> Status: Draft
> Version: 1
> Created: 2018-04-11
> Last-Modified: 2018-04-13
> Post-History: 
> Content-Type: text/x-rst
> Requires: 39
> Replaces: 
> ---
> 
> Abstract
> ========
> 
> This GLEP aims to supplement GLEP 39 [#GLEP39]_ with the definition
> of *Gentoo Developer*.  It shortly indicates the policies relevant
> to obtaining, preserving and revoking the Developer status.
> 
> 
> Motivation
> ==========
> 
> Most of Gentoo's metastructure is explained in GLEP 39 [#GLEP39]_.
> However, while this GLEP is focused around Gentoo Developers, it does
> not define whom they precisely are.  It lacks a clear statement of how
> new developers are recruited, and for how long they hold the developer
> status.
> 
> The ‘status quo’ can be found across different Gentoo websites.
> The recruitment procedure (from user perspective) is described
> on the main site [#BECOME-A-DEV]_.  The Recruiters [#RECRUITERS]_,
> Undertakers [#UNDERTAKERS]_ and Community Relation [#COMREL]_ teams
> provide their relevant policies.  However, there seems to be no single
> document binding all of them together.  This GLEP aims to be precisely
> that.
> 
> 
> Specification
> =============
> 
> A *Gentoo Developer* is a person who has successfully passed
> the recruitment procedure (as defined at the time of his/her joining)
> and is actively contributing to Gentoo Linux in one or both
> of the following areas:
> 
> 1. Gentoo ebuild maintenance (either individual or through a project);
>    with activity being determined through the official Gentoo repository
>    commits.
> 
> 2. Contributing to the present Gentoo projects [#PROJECTS]_; with
>    activity being determined at the discretion of project leads.
> 
> The admission of new Developers is done by the *Recruiters* project
> [#RECRUITERS]_ upon asserting that the candidate has the necessary
> skills and motivation to actively contribute to Gentoo as outlined
> above, provided recent contributions to the specified areas.  The exact
> policies and procedures are specified by the Recruiters project.
> 
> The removal of Developers is done by the *Undertakers* project
> [#UNDERTAKERS]_.  The Developer status can be revoked in one
> of the following conditions:
> 
> - on an explicit request from the Developer himself/herself,
> 
> - upon determining that the Developer is no longer actively contributing
>   to Gentoo,
> 
> - as a result of disciplinary action taken by the *Community Relations*
>   project [#COMREL]_ or another explicitly authorized entity.
> 
> The exact policies and procedures are specified by the Undertakers
> project.
> 
> 
> Rationale
> =========
> 
> This GLEP does not introduce any new policies but merely attempts to
> document the current standing practices.  It aims to supplement GLEP 39
> [#GLEP39]_ with the details necessary to understand who Gentoo
> Developers are, in context of the metastructure defined there.
> It does not mean to replace or thoroughly copy the relevant policies.
> 
> Only the details deemed most important and relevant are listed:
> explanation whom Gentoo Developers are, what are their responsibilities,
> what are the requirements for recruiting them and the possibilities of
> their retirement.  The teams responsible for handling both of those
> processes and defining the detailed policies are explicitly indicated.
> 
> The specific policy details were intentionally left out to avoid having
> to perform frequent updates to this GLEP.  This includes the exact
> procedures, ``repo/gentoo`` commit access, devaway system, etc.
> 
> 
> References
> ==========
> 
> .. [#GLEP39] GLEP 39: An "old-school" metastructure proposal with "boot
>    for being a slacker"
>    (https://www.gentoo.org/glep/glep-0039.html)
> 
> .. [#BECOME-A-DEV] Become a developer - Gentoo Linux
>    (https://www.gentoo.org/get-involved/become-developer/)
> 
> .. [#RECRUITERS] Project:Recruiters - Gentoo Wiki
>    (https://wiki.gentoo.org/wiki/Project:Recruiters)
> 
> .. [#UNDERTAKERS] Project:Undertakers - Gentoo Wiki
>    (https://wiki.gentoo.org/wiki/Project:Undertakers)
> 
> .. [#COMREL] Project:ComRel - Gentoo Wiki
>    (https://wiki.gentoo.org/wiki/Project:ComRel)
> 
> .. [#PROJECTS] Project:Gentoo - Gentoo Wiki
>    (https://wiki.gentoo.org/wiki/Project:Gentoo)
> 
> 
> Copyright
> =========
> This work is licensed under the Creative Commons Attribution-ShareAlike
> 3.0 Unported License. To view a copy of this license, visit
> http://creativecommons.org/licenses/by-sa/3.0/.
> 

I'm not sure a new GLEP is the proper place for this.  Since it seems to
be refining GLEP 39, (defining membership).  So would probably be best
placed as an ammendment to it.  I think I generally supportive of
defining developership though, so I don't want to discourage this.

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Michał Górny]

W dniu sob, 14.04.2018 o godzinie 01∶57 -0500, użytkownik Matthew Thode
napisał:
> On 18-04-13 19:31:37, Michał Górny wrote:
> > Hi,
> > 
> > Here's a quick pre-GLEP for review.  It's a supplement to GLEP 39 that
> > defines who Gentoo Developer is (GLEP 39 mentions devs a lot but doesn't
> > say who they are).  Alike 39, it's purely information -- it doesn't
> > state a policy, just notes the status quo.  It is also minimal
> > and focuses on linking the policies of relevant teams.
> > 
> > Please review.
> > 
> > ---
> > GLEP: 76
> > Title: Gentoo Developer status
> > Author: Michał Górny <mgorny@gentoo.org>
> > Type: Informational
> > Status: Draft
> > Version: 1
> > Created: 2018-04-11
> > Last-Modified: 2018-04-13
> > Post-History: 
> > Content-Type: text/x-rst
> > Requires: 39
> > Replaces: 
> > ---
> > 
> > Abstract
> > ========
> > 
> > This GLEP aims to supplement GLEP 39 [#GLEP39]_ with the definition
> > of *Gentoo Developer*.  It shortly indicates the policies relevant
> > to obtaining, preserving and revoking the Developer status.
> > 
> > 
> > Motivation
> > ==========
> > 
> > Most of Gentoo's metastructure is explained in GLEP 39 [#GLEP39]_.
> > However, while this GLEP is focused around Gentoo Developers, it does
> > not define whom they precisely are.  It lacks a clear statement of how
> > new developers are recruited, and for how long they hold the developer
> > status.
> > 
> > The ‘status quo’ can be found across different Gentoo websites.
> > The recruitment procedure (from user perspective) is described
> > on the main site [#BECOME-A-DEV]_.  The Recruiters [#RECRUITERS]_,
> > Undertakers [#UNDERTAKERS]_ and Community Relation [#COMREL]_ teams
> > provide their relevant policies.  However, there seems to be no single
> > document binding all of them together.  This GLEP aims to be precisely
> > that.
> > 
> > 
> > Specification
> > =============
> > 
> > A *Gentoo Developer* is a person who has successfully passed
> > the recruitment procedure (as defined at the time of his/her joining)
> > and is actively contributing to Gentoo Linux in one or both
> > of the following areas:
> > 
> > 1. Gentoo ebuild maintenance (either individual or through a project);
> >    with activity being determined through the official Gentoo repository
> >    commits.
> > 
> > 2. Contributing to the present Gentoo projects [#PROJECTS]_; with
> >    activity being determined at the discretion of project leads.
> > 
> > The admission of new Developers is done by the *Recruiters* project
> > [#RECRUITERS]_ upon asserting that the candidate has the necessary
> > skills and motivation to actively contribute to Gentoo as outlined
> > above, provided recent contributions to the specified areas.  The exact
> > policies and procedures are specified by the Recruiters project.
> > 
> > The removal of Developers is done by the *Undertakers* project
> > [#UNDERTAKERS]_.  The Developer status can be revoked in one
> > of the following conditions:
> > 
> > - on an explicit request from the Developer himself/herself,
> > 
> > - upon determining that the Developer is no longer actively contributing
> >   to Gentoo,
> > 
> > - as a result of disciplinary action taken by the *Community Relations*
> >   project [#COMREL]_ or another explicitly authorized entity.
> > 
> > The exact policies and procedures are specified by the Undertakers
> > project.
> > 
> > 
> > Rationale
> > =========
> > 
> > This GLEP does not introduce any new policies but merely attempts to
> > document the current standing practices.  It aims to supplement GLEP 39
> > [#GLEP39]_ with the details necessary to understand who Gentoo
> > Developers are, in context of the metastructure defined there.
> > It does not mean to replace or thoroughly copy the relevant policies.
> > 
> > Only the details deemed most important and relevant are listed:
> > explanation whom Gentoo Developers are, what are their responsibilities,
> > what are the requirements for recruiting them and the possibilities of
> > their retirement.  The teams responsible for handling both of those
> > processes and defining the detailed policies are explicitly indicated.
> > 
> > The specific policy details were intentionally left out to avoid having
> > to perform frequent updates to this GLEP.  This includes the exact
> > procedures, ``repo/gentoo`` commit access, devaway system, etc.
> > 
> > 
> > References
> > ==========
> > 
> > .. [#GLEP39] GLEP 39: An "old-school" metastructure proposal with "boot
> >    for being a slacker"
> >    (https://www.gentoo.org/glep/glep-0039.html)
> > 
> > .. [#BECOME-A-DEV] Become a developer - Gentoo Linux
> >    (https://www.gentoo.org/get-involved/become-developer/)
> > 
> > .. [#RECRUITERS] Project:Recruiters - Gentoo Wiki
> >    (https://wiki.gentoo.org/wiki/Project:Recruiters)
> > 
> > .. [#UNDERTAKERS] Project:Undertakers - Gentoo Wiki
> >    (https://wiki.gentoo.org/wiki/Project:Undertakers)
> > 
> > .. [#COMREL] Project:ComRel - Gentoo Wiki
> >    (https://wiki.gentoo.org/wiki/Project:ComRel)
> > 
> > .. [#PROJECTS] Project:Gentoo - Gentoo Wiki
> >    (https://wiki.gentoo.org/wiki/Project:Gentoo)
> > 
> > 
> > Copyright
> > =========
> > This work is licensed under the Creative Commons Attribution-ShareAlike
> > 3.0 Unported License. To view a copy of this license, visit
> > http://creativecommons.org/licenses/by-sa/3.0/.
> > 
> 
> I'm not sure a new GLEP is the proper place for this.  Since it seems to
> be refining GLEP 39, (defining membership).  So would probably be best
> placed as an ammendment to it.  I think I generally supportive of
> defining developership though, so I don't want to discourage this.
> 

I was thinking of that as well.  However, given the 'core' importance
of GLEP 39, I didn't want to modify it.  Also a separate GLEP makes it
easier to clearly define rationale and motivation.

-- 
Best regards,
Michał Górny

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

[Matthew Thode]

[-- Attachment #1: Type: text/plain, Size: 6614 bytes --]

On 18-04-14 09:19:47, Michał Górny wrote:
> W dniu sob, 14.04.2018 o godzinie 01∶57 -0500, użytkownik Matthew Thode
> napisał:
> > On 18-04-13 19:31:37, Michał Górny wrote:
> > > Hi,
> > > 
> > > Here's a quick pre-GLEP for review.  It's a supplement to GLEP 39 that
> > > defines who Gentoo Developer is (GLEP 39 mentions devs a lot but doesn't
> > > say who they are).  Alike 39, it's purely information -- it doesn't
> > > state a policy, just notes the status quo.  It is also minimal
> > > and focuses on linking the policies of relevant teams.
> > > 
> > > Please review.
> > > 
> > > ---
> > > GLEP: 76
> > > Title: Gentoo Developer status
> > > Author: Michał Górny <mgorny@gentoo.org>
> > > Type: Informational
> > > Status: Draft
> > > Version: 1
> > > Created: 2018-04-11
> > > Last-Modified: 2018-04-13
> > > Post-History: 
> > > Content-Type: text/x-rst
> > > Requires: 39
> > > Replaces: 
> > > ---
> > > 
> > > Abstract
> > > ========
> > > 
> > > This GLEP aims to supplement GLEP 39 [#GLEP39]_ with the definition
> > > of *Gentoo Developer*.  It shortly indicates the policies relevant
> > > to obtaining, preserving and revoking the Developer status.
> > > 
> > > 
> > > Motivation
> > > ==========
> > > 
> > > Most of Gentoo's metastructure is explained in GLEP 39 [#GLEP39]_.
> > > However, while this GLEP is focused around Gentoo Developers, it does
> > > not define whom they precisely are.  It lacks a clear statement of how
> > > new developers are recruited, and for how long they hold the developer
> > > status.
> > > 
> > > The ‘status quo’ can be found across different Gentoo websites.
> > > The recruitment procedure (from user perspective) is described
> > > on the main site [#BECOME-A-DEV]_.  The Recruiters [#RECRUITERS]_,
> > > Undertakers [#UNDERTAKERS]_ and Community Relation [#COMREL]_ teams
> > > provide their relevant policies.  However, there seems to be no single
> > > document binding all of them together.  This GLEP aims to be precisely
> > > that.
> > > 
> > > 
> > > Specification
> > > =============
> > > 
> > > A *Gentoo Developer* is a person who has successfully passed
> > > the recruitment procedure (as defined at the time of his/her joining)
> > > and is actively contributing to Gentoo Linux in one or both
> > > of the following areas:
> > > 
> > > 1. Gentoo ebuild maintenance (either individual or through a project);
> > >    with activity being determined through the official Gentoo repository
> > >    commits.
> > > 
> > > 2. Contributing to the present Gentoo projects [#PROJECTS]_; with
> > >    activity being determined at the discretion of project leads.
> > > 
> > > The admission of new Developers is done by the *Recruiters* project
> > > [#RECRUITERS]_ upon asserting that the candidate has the necessary
> > > skills and motivation to actively contribute to Gentoo as outlined
> > > above, provided recent contributions to the specified areas.  The exact
> > > policies and procedures are specified by the Recruiters project.
> > > 
> > > The removal of Developers is done by the *Undertakers* project
> > > [#UNDERTAKERS]_.  The Developer status can be revoked in one
> > > of the following conditions:
> > > 
> > > - on an explicit request from the Developer himself/herself,
> > > 
> > > - upon determining that the Developer is no longer actively contributing
> > >   to Gentoo,
> > > 
> > > - as a result of disciplinary action taken by the *Community Relations*
> > >   project [#COMREL]_ or another explicitly authorized entity.
> > > 
> > > The exact policies and procedures are specified by the Undertakers
> > > project.
> > > 
> > > 
> > > Rationale
> > > =========
> > > 
> > > This GLEP does not introduce any new policies but merely attempts to
> > > document the current standing practices.  It aims to supplement GLEP 39
> > > [#GLEP39]_ with the details necessary to understand who Gentoo
> > > Developers are, in context of the metastructure defined there.
> > > It does not mean to replace or thoroughly copy the relevant policies.
> > > 
> > > Only the details deemed most important and relevant are listed:
> > > explanation whom Gentoo Developers are, what are their responsibilities,
> > > what are the requirements for recruiting them and the possibilities of
> > > their retirement.  The teams responsible for handling both of those
> > > processes and defining the detailed policies are explicitly indicated.
> > > 
> > > The specific policy details were intentionally left out to avoid having
> > > to perform frequent updates to this GLEP.  This includes the exact
> > > procedures, ``repo/gentoo`` commit access, devaway system, etc.
> > > 
> > > 
> > > References
> > > ==========
> > > 
> > > .. [#GLEP39] GLEP 39: An "old-school" metastructure proposal with "boot
> > >    for being a slacker"
> > >    (https://www.gentoo.org/glep/glep-0039.html)
> > > 
> > > .. [#BECOME-A-DEV] Become a developer - Gentoo Linux
> > >    (https://www.gentoo.org/get-involved/become-developer/)
> > > 
> > > .. [#RECRUITERS] Project:Recruiters - Gentoo Wiki
> > >    (https://wiki.gentoo.org/wiki/Project:Recruiters)
> > > 
> > > .. [#UNDERTAKERS] Project:Undertakers - Gentoo Wiki
> > >    (https://wiki.gentoo.org/wiki/Project:Undertakers)
> > > 
> > > .. [#COMREL] Project:ComRel - Gentoo Wiki
> > >    (https://wiki.gentoo.org/wiki/Project:ComRel)
> > > 
> > > .. [#PROJECTS] Project:Gentoo - Gentoo Wiki
> > >    (https://wiki.gentoo.org/wiki/Project:Gentoo)
> > > 
> > > 
> > > Copyright
> > > =========
> > > This work is licensed under the Creative Commons Attribution-ShareAlike
> > > 3.0 Unported License. To view a copy of this license, visit
> > > http://creativecommons.org/licenses/by-sa/3.0/.
> > > 
> > 
> > I'm not sure a new GLEP is the proper place for this.  Since it seems to
> > be refining GLEP 39, (defining membership).  So would probably be best
> > placed as an ammendment to it.  I think I generally supportive of
> > defining developership though, so I don't want to discourage this.
> > 
> 
> I was thinking of that as well.  However, given the 'core' importance
> of GLEP 39, I didn't want to modify it.  Also a separate GLEP makes it
> easier to clearly define rationale and motivation.
> 

Another reason, one that I should have said previously, is that I think
this is important enought to invoke a full dev vote (it is defining the
electorate for the council afterall).

-- 
Matthew Thode (prometheanfire)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Daniel Robbins]

[-- Attachment #1: Type: text/plain, Size: 396 bytes --]

On Fri, Apr 13, 2018 at 11:31 AM, Michał Górny <mgorny@gentoo.org> wrote:

> Hi,
>
> Here's a quick pre-GLEP for review.  It's a supplement to GLEP 39


I think that modifications to GLEP 39 need to be placed on hold until there
is a clear relationship defined to the Foundation.

GLEP 39 has a number of problems but we need to tackle the highest-priority
issues first.

-Daniel

[-- Attachment #2: Type: text/html, Size: 758 bytes --]

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

[Raymond Jennings]

Would there be some sort of dependency-like issues if bylaws were made
that referenced or used terms that themselves were not in the bylaws?

Like, for example, do the words council, developer, etc need
themselves defined in the bylaws?

On Sat, Apr 14, 2018 at 1:58 PM, Daniel Robbins <drobbins@funtoo.org> wrote:
> On Fri, Apr 13, 2018 at 11:31 AM, Michał Górny <mgorny@gentoo.org> wrote:
>>
>> Hi,
>>
>> Here's a quick pre-GLEP for review.  It's a supplement to GLEP 39
>
>
> I think that modifications to GLEP 39 need to be placed on hold until there
> is a clear relationship defined to the Foundation.
>
> GLEP 39 has a number of problems but we need to tackle the highest-priority
> issues first.
>
> -Daniel