[gentoo-project] [RFC] Undertakers: appeal policy

[gentoo-project] [RFC] Undertakers: appeal policy

[Michał Górny]

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

Hi, everyone.

Since we currently don't explicitly indicate the appeal procedure
for Undertaker actions, I'd like to propose adding the following to our
wiki page.

TL;DR: Potential retirements can be appealed <1 mo before execution (or
post execution), with ComRel being the first appeal instance,
and Council being the second.


Full proposed policy, with rationale:

1. Both pending and past retirements can be appealed to ComRel.
The ComRel decision can be further appealed to the Council.

R: ComRel is a parent project for Undertakers, so it seems reasonable to
make it the first appeal instance.


2. Pending retirements can be appealed no earlier than one month before
planned execution date (i.e. no earlier than after receiving third-
mail).

R: This is meant to prevent premature appeals while Undertakers would
not retire the developer anyway (e.g. due to new activity).  Undertakers
recheck activity while sending third mail, so that's a good point to
confirm that someone's retirement is still pending.


3. Throughout the appeal process, the pending retirement is suspended. 
If the appeal occurs post retirement, the developer remains retired
throughout the appeal process.  The appeal process is finished if
either:

  a. the Council issues final decision,

  b. the ComRel decision is not appealed further within 7 days,

  c. both sides agree not to appeal further.

R: We obviously want to avoid ping-pong of retiring, then unretiring
(then maybe retiring again).


4. The appeal process is meant to resolve disagreements between
Undertakers and developers.  It is not a replacement for communicating
with Undertakers.

R: We don't want people to appeal everything without even trying to
resolve it between us.  For example, if we missed something, then you
should tell us rather than calling for appeal.  However, if we do
disagree on whether something counts as sufficient activity, this is
something you can appeal.


5. The appeal process resolves each case individually based on existing
policies.  While it may influence future policies, those need to be
carried out via appropriate policy making channels.

R: In other words, appeals don't change policies silently.  If a policy
needs to be changed, it must follow proper channel with ml review.


WDYT?

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

[gentoo-project] Re: [RFC] Undertakers: appeal policy

[James Le Cuirot]

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

On Sat, 21 Sep 2019 09:01:54 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> Hi, everyone.
> 
> Since we currently don't explicitly indicate the appeal procedure
> for Undertaker actions, I'd like to propose adding the following to our
> wiki page.
> 
> TL;DR: Potential retirements can be appealed <1 mo before execution (or
> post execution), with ComRel being the first appeal instance,
> and Council being the second.
> 
> 
> Full proposed policy, with rationale:
> 
> 1. Both pending and past retirements can be appealed to ComRel.
> The ComRel decision can be further appealed to the Council.
> 
> R: ComRel is a parent project for Undertakers, so it seems reasonable to
> make it the first appeal instance.
> 
> 
> 2. Pending retirements can be appealed no earlier than one month before
> planned execution date (i.e. no earlier than after receiving third-
> mail).
> 
> R: This is meant to prevent premature appeals while Undertakers would
> not retire the developer anyway (e.g. due to new activity).  Undertakers
> recheck activity while sending third mail, so that's a good point to
> confirm that someone's retirement is still pending.
> 
> 
> 3. Throughout the appeal process, the pending retirement is suspended. 
> If the appeal occurs post retirement, the developer remains retired
> throughout the appeal process.  The appeal process is finished if
> either:
> 
>   a. the Council issues final decision,
> 
>   b. the ComRel decision is not appealed further within 7 days,
> 
>   c. both sides agree not to appeal further.
> 
> R: We obviously want to avoid ping-pong of retiring, then unretiring
> (then maybe retiring again).
> 
> 
> 4. The appeal process is meant to resolve disagreements between
> Undertakers and developers.  It is not a replacement for communicating
> with Undertakers.
> 
> R: We don't want people to appeal everything without even trying to
> resolve it between us.  For example, if we missed something, then you
> should tell us rather than calling for appeal.  However, if we do
> disagree on whether something counts as sufficient activity, this is
> something you can appeal.
> 
> 
> 5. The appeal process resolves each case individually based on existing
> policies.  While it may influence future policies, those need to be
> carried out via appropriate policy making channels.
> 
> R: In other words, appeals don't change policies silently.  If a policy
> needs to be changed, it must follow proper channel with ml review.
> 
> 
> WDYT?

Thanks for noticing this gap and addressing it. Given recent events
though, we must also review the wording used in regular undertaker
correspondence and also the process, if necessary, to avoid things
getting to this point in the first place.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

Re: [gentoo-project] Re: [RFC] Undertakers: appeal policy

[Richard Yao]

> On Sep 21, 2019, at 5:55 AM, James Le Cuirot <chewi@gentoo.org> wrote:
> 
> On Sat, 21 Sep 2019 09:01:54 +0200
> Michał Górny <mgorny@gentoo.org> wrote:
> 
>> Hi, everyone.
>> 
>> Since we currently don't explicitly indicate the appeal procedure
>> for Undertaker actions, I'd like to propose adding the following to our
>> wiki page.
>> 
>> TL;DR: Potential retirements can be appealed <1 mo before execution (or
>> post execution), with ComRel being the first appeal instance,
>> and Council being the second.
>> 
>> 
>> Full proposed policy, with rationale:
>> 
>> 1. Both pending and past retirements can be appealed to ComRel.
>> The ComRel decision can be further appealed to the Council.
>> 
>> R: ComRel is a parent project for Undertakers, so it seems reasonable to
>> make it the first appeal instance.
>> 
>> 
>> 2. Pending retirements can be appealed no earlier than one month before
>> planned execution date (i.e. no earlier than after receiving third-
>> mail).
>> 
>> R: This is meant to prevent premature appeals while Undertakers would
>> not retire the developer anyway (e.g. due to new activity).  Undertakers
>> recheck activity while sending third mail, so that's a good point to
>> confirm that someone's retirement is still pending.
>> 
>> 
>> 3. Throughout the appeal process, the pending retirement is suspended. 
>> If the appeal occurs post retirement, the developer remains retired
>> throughout the appeal process.  The appeal process is finished if
>> either:
>> 
>>  a. the Council issues final decision,
>> 
>>  b. the ComRel decision is not appealed further within 7 days,
>> 
>>  c. both sides agree not to appeal further.
>> 
>> R: We obviously want to avoid ping-pong of retiring, then unretiring
>> (then maybe retiring again).
>> 
>> 
>> 4. The appeal process is meant to resolve disagreements between
>> Undertakers and developers.  It is not a replacement for communicating
>> with Undertakers.
>> 
>> R: We don't want people to appeal everything without even trying to
>> resolve it between us.  For example, if we missed something, then you
>> should tell us rather than calling for appeal.  However, if we do
>> disagree on whether something counts as sufficient activity, this is
>> something you can appeal.
>> 
>> 
>> 5. The appeal process resolves each case individually based on existing
>> policies.  While it may influence future policies, those need to be
>> carried out via appropriate policy making channels.
>> 
>> R: In other words, appeals don't change policies silently.  If a policy
>> needs to be changed, it must follow proper channel with ml review.
>> 
>> 
>> WDYT?
> 
> Thanks for noticing this gap and addressing it. Given recent events
> though, we must also review the wording used in regular undertaker
> correspondence and also the process, if necessary, to avoid things
> getting to this point in the first place.
I agree. Putting a process into place to provide order to things is a definite improvement. I am happy to see things moving in a constructive direction.

That said, I want to point out that our ability to move in a constructive direction after discussion is praiseworthy. I have recently had exposure to certain other areas of the OSS community where disagreements are not handled well. I find our approach to things to be a breath of fresh air in comparison. I will refrain from naming projects, but to avoid causing misconceptions, I will say that I am not referring to any projects where I currently have more than 3 commits.
> 
> -- 
> James Le Cuirot (chewi)
> Gentoo Linux Developer

Re: [gentoo-project] Re: [RFC] Undertakers: appeal policy

[Rich Freeman]

On Sat, Sep 21, 2019 at 9:54 AM Richard Yao <ryao@gentoo.org> wrote:
>
> That said, I want to point out that our ability to move in a
> constructive direction after discussion is praiseworthy. I have
> recently had exposure to certain other areas of the OSS community
> where disagreements are not handled well. I find our approach to
> things to be a breath of fresh air in comparison.

I suspect a lot of that has to do with the fact that our distro is
strongly organized around some principles that are fairly unique in
the FOSS world.  We're source-based with an emphasis on user choice,
and also stick close to upstream.  The latter is fairly uncommon, and
the former is basically non-existent elsewhere.

So, even those who have become extremely exasperated with the overall
community still tend to stick around.  Our PMS is largely maintained
by a former dev who many do not get along with.  Our founder isn't
really involved as a dev but never wanders too far and maintains a
fairly friendly fork.  Many who are devs have waxed and waned in
activity but even after expressing extreme frustration tend to return
after a break.

We're also a small community, so when there are disagreements they
might seem large in that context, but the number of people involved
tends to still be very small.  That means that there is less
temptation for groups of contributors to go off and start forks.

All of that has its pros and cons.  The obvious pro is that it tends
to keep us together and I think it really does demonstrate how a group
that is fairly diverse in many ways can rally around just a few common
goals, even if we sometimes disagree vigorously about all sorts of
things.  The obvious con is that we don't really have much of a
release valve for disagreement and so battles tend to just rage on
over certain things, with the distro reaching uncomfortable
compromises instead of a few forks organized more closely around one
principle or another.

-- 
Rich

Re: [gentoo-project] Re: [RFC] Undertakers: appeal policy

[Michał Górny]

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

On Sat, 2019-09-21 at 14:36 -0400, Rich Freeman wrote:
> Our PMS is largely maintained
> by a former dev who many do not get along with.

This is not true.  It is maintained by a few active Gentoo devs,
and by a quick peak last non-Gentoo-dev patch was committed in 2012.
In fact, EAPI 7 has been rejected in Paludis.

>   Our founder isn't
> really involved as a dev but never wanders too far and maintains a
> fairly friendly fork.

'Friendly fork', right.  I guess everyone is welcome to watch and make
his/her own opinion.  However, it doesn't sound like you really have
verified any of those statements.

That's just to correct things.  Now, guys, can we please stay on topic? 
I welcome all your support but of the three replies so far, nobody has
provided any opinion on the proposal in question.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]

Re: [gentoo-project] Re: [RFC] Undertakers: appeal policy

[James Le Cuirot]

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

On Sat, 21 Sep 2019 20:48:29 +0200
Michał Górny <mgorny@gentoo.org> wrote:

> That's just to correct things.  Now, guys, can we please stay on topic? 
> I welcome all your support but of the three replies so far, nobody has
> provided any opinion on the proposal in question.

I was implying that it was good with the "thanks" but yes, I should
have been clearer. It works for me.

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer

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

Re: [gentoo-project] Re: [RFC] Undertakers: appeal policy

[Aaron Bauman]

On September 21, 2019 2:48:29 PM EDT, "Michał Górny" <mgorny@gentoo.org> wrote:
>On Sat, 2019-09-21 at 14:36 -0400, Rich Freeman wrote:
>> Our PMS is largely maintained
>> by a former dev who many do not get along with.
>
>This is not true.  It is maintained by a few active Gentoo devs,
>and by a quick peak last non-Gentoo-dev patch was committed in 2012.
>In fact, EAPI 7 has been rejected in Paludis.
>
>>   Our founder isn't
>> really involved as a dev but never wanders too far and maintains a
>> fairly friendly fork.
>
>'Friendly fork', right.  I guess everyone is welcome to watch and make
>his/her own opinion.  However, it doesn't sound like you really have
>verified any of those statements.
>
>That's just to correct things.  Now, guys, can we please stay on topic?
>
>I welcome all your support but of the three replies so far, nobody has
>provided any opinion on the proposal in question.

The proposal is good, but I find it unnecessary at the same time. 

Of the devs appealing their retirement at the 11th... I find most of them have spent more time debating then just making a few simple commits to be active. 

Conversely, I see devs who just contribute and the undertaker's reverse the retirement process. 

Contribute || retire. 


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-project] [RFC] Undertakers: appeal policy

[Roy Bamford]

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

On 2019.09.21 08:01, Michał Górny wrote:
> Hi, everyone.
> 
> Since we currently don't explicitly indicate the appeal procedure
> for Undertaker actions, I'd like to propose adding the following to
> our
> wiki page.
> 
> TL;DR: Potential retirements can be appealed <1 mo before execution
> (or
> post execution), with ComRel being the first appeal instance,
> and Council being the second.
> 
> 
> Full proposed policy, with rationale:
> 
> 1. Both pending and past retirements can be appealed to ComRel.
> The ComRel decision can be further appealed to the Council.
> 
> R: ComRel is a parent project for Undertakers, so it seems reasonable
> to
> make it the first appeal instance.
> 
> 
> 2. Pending retirements can be appealed no earlier than one month
> before
> planned execution date (i.e. no earlier than after receiving third-
> mail).
> 
> R: This is meant to prevent premature appeals while Undertakers would
> not retire the developer anyway (e.g. due to new activity). 
> Undertakers
> recheck activity while sending third mail, so that's a good point to
> confirm that someone's retirement is still pending.
> 
> 
> 3. Throughout the appeal process, the pending retirement is suspended.
> 
> If the appeal occurs post retirement, the developer remains retired
> throughout the appeal process.  The appeal process is finished if
> either:
> 
>   a. the Council issues final decision,
> 
>   b. the ComRel decision is not appealed further within 7 days,
> 
>   c. both sides agree not to appeal further.
> 
> R: We obviously want to avoid ping-pong of retiring, then unretiring
> (then maybe retiring again).
> 
> 
> 4. The appeal process is meant to resolve disagreements between
> Undertakers and developers.  It is not a replacement for communicating
> with Undertakers.
> 
> R: We don't want people to appeal everything without even trying to
> resolve it between us.  For example, if we missed something, then you
> should tell us rather than calling for appeal.  However, if we do
> disagree on whether something counts as sufficient activity, this is
> something you can appeal.
> 
> 
> 5. The appeal process resolves each case individually based on
> existing
> policies.  While it may influence future policies, those need to be
> carried out via appropriate policy making channels.
> 
> R: In other words, appeals don't change policies silently.  If a
> policy
> needs to be changed, it must follow proper channel with ml review.
> 
> 
> WDYT?
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

Michał,

Looks good. It also looks like the standard process so does it
need to be documented explicitly on the Undertakers page? 

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

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

Re: [gentoo-project] [RFC] Undertakers: appeal policy

[Michał Górny]

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

On Sat, 2019-09-28 at 10:53 +0100, Roy Bamford wrote:
> On 2019.09.21 08:01, Michał Górny wrote:
> > Hi, everyone.
> > 
> > Since we currently don't explicitly indicate the appeal procedure
> > for Undertaker actions, I'd like to propose adding the following to
> > our
> > wiki page.
> > 
> > TL;DR: Potential retirements can be appealed <1 mo before execution
> > (or
> > post execution), with ComRel being the first appeal instance,
> > and Council being the second.
> > 
> > 
> > Full proposed policy, with rationale:
> > 
> > 1. Both pending and past retirements can be appealed to ComRel.
> > The ComRel decision can be further appealed to the Council.
> > 
> > R: ComRel is a parent project for Undertakers, so it seems reasonable
> > to
> > make it the first appeal instance.
> > 
> > 
> > 2. Pending retirements can be appealed no earlier than one month
> > before
> > planned execution date (i.e. no earlier than after receiving third-
> > mail).
> > 
> > R: This is meant to prevent premature appeals while Undertakers would
> > not retire the developer anyway (e.g. due to new activity). 
> > Undertakers
> > recheck activity while sending third mail, so that's a good point to
> > confirm that someone's retirement is still pending.
> > 
> > 
> > 3. Throughout the appeal process, the pending retirement is suspended.
> > 
> > If the appeal occurs post retirement, the developer remains retired
> > throughout the appeal process.  The appeal process is finished if
> > either:
> > 
> >   a. the Council issues final decision,
> > 
> >   b. the ComRel decision is not appealed further within 7 days,
> > 
> >   c. both sides agree not to appeal further.
> > 
> > R: We obviously want to avoid ping-pong of retiring, then unretiring
> > (then maybe retiring again).
> > 
> > 
> > 4. The appeal process is meant to resolve disagreements between
> > Undertakers and developers.  It is not a replacement for communicating
> > with Undertakers.
> > 
> > R: We don't want people to appeal everything without even trying to
> > resolve it between us.  For example, if we missed something, then you
> > should tell us rather than calling for appeal.  However, if we do
> > disagree on whether something counts as sufficient activity, this is
> > something you can appeal.
> > 
> > 
> > 5. The appeal process resolves each case individually based on
> > existing
> > policies.  While it may influence future policies, those need to be
> > carried out via appropriate policy making channels.
> > 
> > R: In other words, appeals don't change policies silently.  If a
> > policy
> > needs to be changed, it must follow proper channel with ml review.
> > 
> > 
> > WDYT?
> > 
> > -- 
> > Best regards,
> > Michał Górny
> > 
> > 
> 
> Michał,
> 
> Looks good. It also looks like the standard process so does it
> need to be documented explicitly on the Undertakers page? 
> 

Given that one person already asked about it, I supposed it does.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 618 bytes --]