[gentoo-project] A GLEP for ComRel?

[gentoo-project] A GLEP for ComRel?

[Michał Górny]

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

Hi,

Given the amount of discussion GLEP 48 update brought, I'd like to
tackle a semi-related topic: wouldn't it be beneficial to have the role
and policies of ComRel solidified in a GLEP, and officially stamped
by the Council this way?

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] A GLEP for ComRel?

[Thomas Deutschmann]

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

On 2019-04-25 16:02, Michał Górny wrote:
> Given the amount of discussion GLEP 48 update brought, I'd like to
> tackle a semi-related topic: wouldn't it be beneficial to have the role
> and policies of ComRel solidified in a GLEP, and officially stamped
> by the Council this way?

+1

Including Proctors.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5


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

Re: [gentoo-project] A GLEP for ComRel?

[Alec Warner]

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

On Thu, Apr 25, 2019 at 10:02 AM Michał Górny <mgorny@gentoo.org> wrote:

> Hi,
>
> Given the amount of discussion GLEP 48 update brought, I'd like to
> tackle a semi-related topic: wouldn't it be beneficial to have the role
> and policies of ComRel solidified in a GLEP, and officially stamped
> by the Council this way?
>

I'd be excited to see a GLEP to outline the purpose of the Comrel team and
its role. I'm less happy to codify the policies in the GLEP. I'd argue that
most policies should be decided at the team level (not the council level).
GLEP48 itself is kind of a mix of "here is what we think the QA team should
be doing" and policies "the QA team will fix typos, etc." I'd perhaps
advocate for stronger guidance on separating these concerns.

To use an example from our IRC conversation. Rich suggested the Comrel GLEP
should contain some kind of wording for privacy expectations. I agree that
it should, but I'm not sure it should exactly specify. It might be
sufficient to say:

[Proctors]
You should have no privacy expectation for conversations with the Proctors
team, assume all conversations are public.

[Comrel]
Conversations with Comrel are confidential, but may become non-confidential
under (some circumstances){LINK_TO_POLICY_DOCUMENT}.

Note that I don't intend for this to mean the council cannot have a say in
team policies, but I think it should be more reactionary (users report bad
policies, council investigates and takes action) and less proactive
(council reviews and approves all policies.) I think if the latter was to
happen, you'd need some faster way to get the a council to review and
approve things. Like in Infra (another team where a charter might be
worthwhile) I'm not sure the council approving our policies adds much.

-A


>
> --
> Best regards,
> Michał Górny
>
>

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

Re: [gentoo-project] A GLEP for ComRel?

[Michał Górny]

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

On Thu, 2019-04-25 at 11:55 -0400, Alec Warner wrote:
> On Thu, Apr 25, 2019 at 10:02 AM Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Hi,
> > 
> > Given the amount of discussion GLEP 48 update brought, I'd like to
> > tackle a semi-related topic: wouldn't it be beneficial to have the role
> > and policies of ComRel solidified in a GLEP, and officially stamped
> > by the Council this way?
> > 
> 
> I'd be excited to see a GLEP to outline the purpose of the Comrel team and
> its role. I'm less happy to codify the policies in the GLEP. I'd argue that
> most policies should be decided at the team level (not the council level).
> GLEP48 itself is kind of a mix of "here is what we think the QA team should
> be doing" and policies "the QA team will fix typos, etc." I'd perhaps
> advocate for stronger guidance on separating these concerns.
> 
> To use an example from our IRC conversation. Rich suggested the Comrel GLEP
> should contain some kind of wording for privacy expectations. I agree that
> it should, but I'm not sure it should exactly specify. It might be
> sufficient to say:
> 
> [Proctors]
> You should have no privacy expectation for conversations with the Proctors
> team, assume all conversations are public.
> 
> [Comrel]
> Conversations with Comrel are confidential, but may become non-confidential
> under (some circumstances){LINK_TO_POLICY_DOCUMENT}.
> 
> Note that I don't intend for this to mean the council cannot have a say in
> team policies, but I think it should be more reactionary (users report bad
> policies, council investigates and takes action) and less proactive
> (council reviews and approves all policies.) I think if the latter was to
> happen, you'd need some faster way to get the a council to review and
> approve things. Like in Infra (another team where a charter might be
> worthwhile) I'm not sure the council approving our policies adds much.
> 

We could also go for more general 'disciplinary action' GLEP, and make
individual project (ComRel, Proctors, QA) policies adhere to that.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] A GLEP for ComRel?

[Matthew Thode]

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

On 19-04-25 18:14:18, Michał Górny wrote:
> On Thu, 2019-04-25 at 11:55 -0400, Alec Warner wrote:
> > On Thu, Apr 25, 2019 at 10:02 AM Michał Górny <mgorny@gentoo.org> wrote:
> > 
> > > Hi,
> > > 
> > > Given the amount of discussion GLEP 48 update brought, I'd like to
> > > tackle a semi-related topic: wouldn't it be beneficial to have the role
> > > and policies of ComRel solidified in a GLEP, and officially stamped
> > > by the Council this way?
> > > 
> > 
> > I'd be excited to see a GLEP to outline the purpose of the Comrel team and
> > its role. I'm less happy to codify the policies in the GLEP. I'd argue that
> > most policies should be decided at the team level (not the council level).
> > GLEP48 itself is kind of a mix of "here is what we think the QA team should
> > be doing" and policies "the QA team will fix typos, etc." I'd perhaps
> > advocate for stronger guidance on separating these concerns.
> > 
> > To use an example from our IRC conversation. Rich suggested the Comrel GLEP
> > should contain some kind of wording for privacy expectations. I agree that
> > it should, but I'm not sure it should exactly specify. It might be
> > sufficient to say:
> > 
> > [Proctors]
> > You should have no privacy expectation for conversations with the Proctors
> > team, assume all conversations are public.
> > 
> > [Comrel]
> > Conversations with Comrel are confidential, but may become non-confidential
> > under (some circumstances){LINK_TO_POLICY_DOCUMENT}.
> > 
> > Note that I don't intend for this to mean the council cannot have a say in
> > team policies, but I think it should be more reactionary (users report bad
> > policies, council investigates and takes action) and less proactive
> > (council reviews and approves all policies.) I think if the latter was to
> > happen, you'd need some faster way to get the a council to review and
> > approve things. Like in Infra (another team where a charter might be
> > worthwhile) I'm not sure the council approving our policies adds much.
> > 
> 
> We could also go for more general 'disciplinary action' GLEP, and make
> individual project (ComRel, Proctors, QA) policies adhere to that.
> 

I'd like to avoid focusing too much on retribution (disciplinary action)
and more on education.  I'm sure there are times where action may be
needed but what it sounds like is needed are more genral definitions of
what the relationship between groups should be (how to hand off a high
priority item for review/action).

-- 
Matthew Thode (prometheanfire)

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

Re: [gentoo-project] A GLEP for ComRel?

[Michał Górny]

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

On Thu, 2019-04-25 at 11:24 -0500, Matthew Thode wrote:
> On 19-04-25 18:14:18, Michał Górny wrote:
> > On Thu, 2019-04-25 at 11:55 -0400, Alec Warner wrote:
> > > On Thu, Apr 25, 2019 at 10:02 AM Michał Górny <mgorny@gentoo.org> wrote:
> > > 
> > > > Hi,
> > > > 
> > > > Given the amount of discussion GLEP 48 update brought, I'd like to
> > > > tackle a semi-related topic: wouldn't it be beneficial to have the role
> > > > and policies of ComRel solidified in a GLEP, and officially stamped
> > > > by the Council this way?
> > > > 
> > > 
> > > I'd be excited to see a GLEP to outline the purpose of the Comrel team and
> > > its role. I'm less happy to codify the policies in the GLEP. I'd argue that
> > > most policies should be decided at the team level (not the council level).
> > > GLEP48 itself is kind of a mix of "here is what we think the QA team should
> > > be doing" and policies "the QA team will fix typos, etc." I'd perhaps
> > > advocate for stronger guidance on separating these concerns.
> > > 
> > > To use an example from our IRC conversation. Rich suggested the Comrel GLEP
> > > should contain some kind of wording for privacy expectations. I agree that
> > > it should, but I'm not sure it should exactly specify. It might be
> > > sufficient to say:
> > > 
> > > [Proctors]
> > > You should have no privacy expectation for conversations with the Proctors
> > > team, assume all conversations are public.
> > > 
> > > [Comrel]
> > > Conversations with Comrel are confidential, but may become non-confidential
> > > under (some circumstances){LINK_TO_POLICY_DOCUMENT}.
> > > 
> > > Note that I don't intend for this to mean the council cannot have a say in
> > > team policies, but I think it should be more reactionary (users report bad
> > > policies, council investigates and takes action) and less proactive
> > > (council reviews and approves all policies.) I think if the latter was to
> > > happen, you'd need some faster way to get the a council to review and
> > > approve things. Like in Infra (another team where a charter might be
> > > worthwhile) I'm not sure the council approving our policies adds much.
> > > 
> > 
> > We could also go for more general 'disciplinary action' GLEP, and make
> > individual project (ComRel, Proctors, QA) policies adhere to that.
> > 
> 
> I'd like to avoid focusing too much on retribution (disciplinary action)
> and more on education.  I'm sure there are times where action may be
> needed but what it sounds like is needed are more genral definitions of
> what the relationship between groups should be (how to hand off a high
> priority item for review/action).
> 

I'd be happy to see ComRel focus more on educating, helping and cooling
down conflicts.  To my experience, ComRel so far has mostly focused
on ignoring requests, threatening people and occasionally issuing
punishment.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] A GLEP for ComRel?

[Rich Freeman]

On Thu, Apr 25, 2019 at 12:24 PM Matthew Thode
<prometheanfire@gentoo.org> wrote:
>
> I'm sure there are times where action may be
> needed but what it sounds like is needed are more genral definitions of
> what the relationship between groups should be (how to hand off a high
> priority item for review/action).

IMO the scope of each is fairly clear-cut, and the few times we've had
to interact we already have a comrel liason on Proctors.  We really
only escalate serious repeat offenses/etc, and that basically just
involves sending them a complaint (much as any dev might), and
referencing what data we have (which is all public anyway, since
Proctors only deals with specific incidents that happen in public, and
not interpersonal issues in general).  There will never be a case
where a Comrel issue would get referred to Proctors, unless it was
just misdirected from the start.  If that were the case we'd just have
them assign us a bug/etc or otherwise ping us.

No harm in writing that down I suppose, but I'm not sure it is worth
it since I don't see this particular aspect of either group as
contentious.  Neither group really has special standing with the other
- when we refer issues to Comrel they basically go into a black hole
as far as we're concerned - it would be between that dev and Comrel,
since it wouldn't be a personal conflict issue from our standpoint.
We could continue to take action on future incidents like we always
would, and we don't have discretion to do permanent bans/etc.  If
Comrel issued a long-term ban then there would be no further incidents
for us to deal with.

While I'm not opposed to a single GLEP for Comrel plus Proctors (or
maybe even lump QA in there - there are potentially some common
elements like confirming leads), I'm not sure if that actually makes
things simpler.  IMO Comrel is more about dealing with people, and
Proctors is more about dealing with their specific posts/etc without
passing judgment on the individuals long-term fit in the community.
Proctors actions are definitely not intended to be punitive even if
they're bans - it is more about cooling down, bringing attention to
the CoC, and so on, and all bans are relatively short and
auto-reinstated with no further follow-up.  We also generally have
been avoiding being ban-heavy (well, aside from that spam a while ago)
and I'd like to see guidelines published further explaining our goals.

-- 
Rich

Re: [gentoo-project] A GLEP for ComRel?

[Alec Warner]

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

On Thu, Apr 25, 2019 at 3:18 PM Rich Freeman <rich0@gentoo.org> wrote:

> On Thu, Apr 25, 2019 at 12:24 PM Matthew Thode
> <prometheanfire@gentoo.org> wrote:
> >
> > I'm sure there are times where action may be
> > needed but what it sounds like is needed are more genral definitions of
> > what the relationship between groups should be (how to hand off a high
> > priority item for review/action).
>
> IMO the scope of each is fairly clear-cut, and the few times we've had
> to interact we already have a comrel liason on Proctors.  We really
> only escalate serious repeat offenses/etc, and that basically just
> involves sending them a complaint (much as any dev might), and
> referencing what data we have (which is all public anyway, since
> Proctors only deals with specific incidents that happen in public, and
> not interpersonal issues in general).  There will never be a case
> where a Comrel issue would get referred to Proctors, unless it was
> just misdirected from the start.  If that were the case we'd just have
> them assign us a bug/etc or otherwise ping us.
>

At least in my view the QA / Comrel interaction could use some
improvement. Proctors is *under* comrel so its less contentious I suspect ;)

-A


>
> No harm in writing that down I suppose, but I'm not sure it is worth
> it since I don't see this particular aspect of either group as
> contentious.  Neither group really has special standing with the other
> - when we refer issues to Comrel they basically go into a black hole
> as far as we're concerned - it would be between that dev and Comrel,
> since it wouldn't be a personal conflict issue from our standpoint.
> We could continue to take action on future incidents like we always
> would, and we don't have discretion to do permanent bans/etc.  If
> Comrel issued a long-term ban then there would be no further incidents
> for us to deal with.
>
> While I'm not opposed to a single GLEP for Comrel plus Proctors (or
> maybe even lump QA in there - there are potentially some common
> elements like confirming leads), I'm not sure if that actually makes
> things simpler.  IMO Comrel is more about dealing with people, and
> Proctors is more about dealing with their specific posts/etc without
> passing judgment on the individuals long-term fit in the community.
> Proctors actions are definitely not intended to be punitive even if
> they're bans - it is more about cooling down, bringing attention to
> the CoC, and so on, and all bans are relatively short and
> auto-reinstated with no further follow-up.  We also generally have
> been avoiding being ban-heavy (well, aside from that spam a while ago)
> and I'd like to see guidelines published further explaining our goals.
>
> --
> Rich
>
>

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