[gentoo-project] rfc: comrel changes

[gentoo-project] rfc: comrel changes

[William Hubbs]

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

All,

I realize that comrel is a thankless job, but it is an important one
that helps preserve the health of the community.

To facilitate this, I think we need to have some changes in the way comrel
operates, so I would like to propose them here to see what other folks think.

Since comrel is a special TLP like QA, I think the comrel lead, like
the qa lead, should be confirmed by the council.

When an issue is filed with comrel, the issue should be addressed
within a reasonable time frame. As someone who has filed issues, I have
seen them sit for months with no action taken.
With all respect to comrel, this is unacceptable. You have a published
policy for how you will process issues, so follow it. If you don't, it
is very upsetting for users/developers who reach out to you for
assistance, weakens your credibility, and by extension negatively affects the
reputation of the entire Gentoo community.

To promote more transparency with comrel, I would like to 
require the comrel lead to send a report to the gentoo-project list monthly
containing these statistics for the previous month:

- number of bugs received
- number of bugs pending (this is for bugs that are currently in process)
- number of bugs resolved by actions (such as talking to
  developers or disciplinary action)
- number of bugs closed without action

- number of mediation requests received
- number of mediation requests resolved
- number of mediation requests escalated to bugs
- number of mediation requests dismissed without action

The comrel lead should be replaced if this report is not sent for three
consecutive months.

What do others think?

Thanks,

William


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

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Mon, 2020-02-17 at 10:18 -0600, William Hubbs wrote:
> Since comrel is a special TLP like QA, I think the comrel lead, like
> the qa lead, should be confirmed by the council.
> 

You may also want to have a GLEP for ComRel like GLEP 48 is for QA.

> When an issue is filed with comrel, the issue should be addressed
> within a reasonable time frame. As someone who has filed issues, I have
> seen them sit for months with no action taken.
> With all respect to comrel, this is unacceptable. You have a published
> policy for how you will process issues, so follow it. If you don't, it
> is very upsetting for users/developers who reach out to you for
> assistance, weakens your credibility, and by extension negatively affects the
> reputation of the entire Gentoo community.
> 
> To promote more transparency with comrel, I would like to 
> require the comrel lead to send a report to the gentoo-project list monthly
> containing these statistics for the previous month:
> 
> - number of bugs received
> - number of bugs pending (this is for bugs that are currently in process)
> - number of bugs resolved by actions (such as talking to
>   developers or disciplinary action)
> - number of bugs closed without action

Not sure if you wouldn't need more split, e.g. between requests rejected
as invalid, withdrawn or timed out.

> - number of mediation requests received
> - number of mediation requests resolved
> - number of mediation requests escalated to bugs
> - number of mediation requests dismissed without action
> 
> The comrel lead should be replaced if this report is not sent for three
> consecutive months.
> 
> What do others think?

Overall, the direction seems to make sense.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[William Hubbs]

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

On Mon, Feb 17, 2020 at 05:36:30PM +0100, Michał Górny wrote:
> On Mon, 2020-02-17 at 10:18 -0600, William Hubbs wrote:
> > Since comrel is a special TLP like QA, I think the comrel lead, like
> > the qa lead, should be confirmed by the council.
> > 
> 
> You may also want to have a GLEP for ComRel like GLEP 48 is for QA.

This is a good idea; I will write one.

...

> > To promote more transparency with comrel, I would like to 
> > require the comrel lead to send a report to the gentoo-project list monthly
> > containing these statistics for the previous month:
> > 
> > - number of bugs received
> > - number of bugs pending (this is for bugs that are currently in process)
> > - number of bugs resolved by actions (such as talking to
> >   developers or disciplinary action)
> > - number of bugs closed without action
> 
> Not sure if you wouldn't need more split, e.g. between requests rejected
> as invalid, withdrawn or timed out.

There's not a timed out or invalid status for comrel that I'm aware of,
but withdrawn might be good.

I will encorporate that into the glep also.

William

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

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Mon, 2020-02-17 at 12:10 -0600, William Hubbs wrote:
> On Mon, Feb 17, 2020 at 05:36:30PM +0100, Michał Górny wrote:
> > On Mon, 2020-02-17 at 10:18 -0600, William Hubbs wrote:
> > > Since comrel is a special TLP like QA, I think the comrel lead, like
> > > the qa lead, should be confirmed by the council.
> > > 
> > 
> > You may also want to have a GLEP for ComRel like GLEP 48 is for QA.
> 
> This is a good idea; I will write one.
> 
> ...
> 
> > > To promote more transparency with comrel, I would like to 
> > > require the comrel lead to send a report to the gentoo-project list monthly
> > > containing these statistics for the previous month:
> > > 
> > > - number of bugs received
> > > - number of bugs pending (this is for bugs that are currently in process)
> > > - number of bugs resolved by actions (such as talking to
> > >   developers or disciplinary action)
> > > - number of bugs closed without action
> > 
> > Not sure if you wouldn't need more split, e.g. between requests rejected
> > as invalid, withdrawn or timed out.
> 
> There's not a timed out or invalid status for comrel that I'm aware of,
> but withdrawn might be good.
> 

What if ComRel decides that there are no grounds for the complaint made?
Or do you consider this equivalent to resolved?


-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[William Hubbs]

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

On Mon, Feb 17, 2020 at 09:31:27PM +0100, Michał Górny wrote:
> What if ComRel decides that there are no grounds for the complaint made?
> Or do you consider this equivalent to resolved?

No, this is not the same as resolved.

This is a separate category which I'm working on in the glep.

Thanks,

William

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

[gentoo-project] Re: rfc: comrel changes

[Matt Turner]

On Mon, Feb 17, 2020 at 8:18 AM William Hubbs <williamh@gentoo.org> wrote:
>
> All,
>
> I realize that comrel is a thankless job, but it is an important one
> that helps preserve the health of the community.
>
> To facilitate this, I think we need to have some changes in the way comrel
> operates, so I would like to propose them here to see what other folks think.
>
> Since comrel is a special TLP like QA, I think the comrel lead, like
> the qa lead, should be confirmed by the council.
>
> When an issue is filed with comrel, the issue should be addressed
> within a reasonable time frame. As someone who has filed issues, I have
> seen them sit for months with no action taken.
> With all respect to comrel, this is unacceptable. You have a published
> policy for how you will process issues, so follow it. If you don't, it
> is very upsetting for users/developers who reach out to you for
> assistance, weakens your credibility, and by extension negatively affects the
> reputation of the entire Gentoo community.
>
> To promote more transparency with comrel, I would like to
> require the comrel lead to send a report to the gentoo-project list monthly
> containing these statistics for the previous month:
>
> - number of bugs received
> - number of bugs pending (this is for bugs that are currently in process)
> - number of bugs resolved by actions (such as talking to
>   developers or disciplinary action)
> - number of bugs closed without action
>
> - number of mediation requests received
> - number of mediation requests resolved
> - number of mediation requests escalated to bugs
> - number of mediation requests dismissed without action
>
> The comrel lead should be replaced if this report is not sent for three
> consecutive months.
>
> What do others think?

I think this is all very reasonable. I've both been in the position of
having (multiple) reports to ComRel ignored and also on the inside of
ComRel and seen reports languish.

I hope monthly reports can act as a forcing function for ComRel to be
more attentive.

Re: [gentoo-project] Re: rfc: comrel changes

[William Hubbs]

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

On Mon, Feb 17, 2020 at 08:43:06AM -0800, Matt Turner wrote:
> I think this is all very reasonable. I've both been in the position of
> having (multiple) reports to ComRel ignored and also on the inside of
> ComRel and seen reports languish.
> 
> I hope monthly reports can act as a forcing function for ComRel to be
> more attentive.
 
 I am currently waiting for the glep editors to number my pre-glep. once
 that happens, I'll start another thread with the glep.

 Thanks,

 William


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

Re: [gentoo-project] Re: rfc: comrel changes

[Michał Górny]

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

On Mon, 2020-02-17 at 18:08 -0600, William Hubbs wrote:
> On Mon, Feb 17, 2020 at 08:43:06AM -0800, Matt Turner wrote:
> > I think this is all very reasonable. I've both been in the position of
> > having (multiple) reports to ComRel ignored and also on the inside of
> > ComRel and seen reports languish.
> > 
> > I hope monthly reports can act as a forcing function for ComRel to be
> > more attentive.
>  
>  I am currently waiting for the glep editors to number my pre-glep. once
>  that happens, I'll start another thread with the glep.
> 

Pre-GLEPs don't need numbers.  We don't assign a number before the first
draft.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Alec Warner]

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

On Mon, Feb 17, 2020 at 8:18 AM William Hubbs <williamh@gentoo.org> wrote:

> All,
>
> I realize that comrel is a thankless job, but it is an important one
> that helps preserve the health of the community.
>
> To facilitate this, I think we need to have some changes in the way comrel
> operates, so I would like to propose them here to see what other folks
> think.
>
> Since comrel is a special TLP like QA, I think the comrel lead, like
> the qa lead, should be confirmed by the council.
>
> When an issue is filed with comrel, the issue should be addressed
> within a reasonable time frame. As someone who has filed issues, I have
> seen them sit for months with no action taken.
> With all respect to comrel, this is unacceptable. You have a published
> policy for how you will process issues, so follow it. If you don't, it
> is very upsetting for users/developers who reach out to you for
> assistance, weakens your credibility, and by extension negatively affects
> the
> reputation of the entire Gentoo community.
>
> To promote more transparency with comrel, I would like to
> require the comrel lead to send a report to the gentoo-project list monthly
> containing these statistics for the previous month:
>
> - number of bugs received
> - number of bugs pending (this is for bugs that are currently in process)
> - number of bugs resolved by actions (such as talking to
>   developers or disciplinary action)
> - number of bugs closed without action
>
> - number of mediation requests received
> - number of mediation requests resolved
> - number of mediation requests escalated to bugs
> - number of mediation requests dismissed without action
>
> The comrel lead should be replaced if this report is not sent for three
> consecutive months.
>
> What do others think?
>

I'm a little bit concerned that this addresses the symptoms instead of the
problem. Have you shared your concerns with comrel regarding their lack of
timely communication on reported issues? Do they even share the same goals
you enumerated?

My strawperson argument is that:
 - (0) The council will elect some lead.
 - The lead will never write reports (or write them but stop.)
 - The lead will get removed per policy.
 - Council will elect a new lead.
 - GOTO 0

This isn't to say I dislike the concept of publishing transparency report
(I do like it) but I'm not sure a report completely solves the problems
that comrel actually faces today and I'd be interested to learn more about

-A


>
> Thanks,
>
> William
>
>

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

Re: [gentoo-project] rfc: comrel changes

[Matt Turner]

On Tue, Feb 18, 2020 at 12:13 PM Alec Warner <antarus@gentoo.org> wrote:
>
>
>
> On Mon, Feb 17, 2020 at 8:18 AM William Hubbs <williamh@gentoo.org> wrote:
>>
>> All,
>>
>> I realize that comrel is a thankless job, but it is an important one
>> that helps preserve the health of the community.
>>
>> To facilitate this, I think we need to have some changes in the way comrel
>> operates, so I would like to propose them here to see what other folks think.
>>
>> Since comrel is a special TLP like QA, I think the comrel lead, like
>> the qa lead, should be confirmed by the council.
>>
>> When an issue is filed with comrel, the issue should be addressed
>> within a reasonable time frame. As someone who has filed issues, I have
>> seen them sit for months with no action taken.
>> With all respect to comrel, this is unacceptable. You have a published
>> policy for how you will process issues, so follow it. If you don't, it
>> is very upsetting for users/developers who reach out to you for
>> assistance, weakens your credibility, and by extension negatively affects the
>> reputation of the entire Gentoo community.
>>
>> To promote more transparency with comrel, I would like to
>> require the comrel lead to send a report to the gentoo-project list monthly
>> containing these statistics for the previous month:
>>
>> - number of bugs received
>> - number of bugs pending (this is for bugs that are currently in process)
>> - number of bugs resolved by actions (such as talking to
>>   developers or disciplinary action)
>> - number of bugs closed without action
>>
>> - number of mediation requests received
>> - number of mediation requests resolved
>> - number of mediation requests escalated to bugs
>> - number of mediation requests dismissed without action
>>
>> The comrel lead should be replaced if this report is not sent for three
>> consecutive months.
>>
>> What do others think?
>
>
> I'm a little bit concerned that this addresses the symptoms instead of the problem. Have you shared your concerns with comrel regarding their lack of timely communication on reported issues? Do they even share the same goals you enumerated?
>
> My strawperson argument is that:
>  - (0) The council will elect some lead.
>  - The lead will never write reports (or write them but stop.)
>  - The lead will get removed per policy.
>  - Council will elect a new lead.
>  - GOTO 0
>
> This isn't to say I dislike the concept of publishing transparency report (I do like it) but I'm not sure a report completely solves the problems that comrel actually faces today and I'd be interested to learn more about
>

I've discussed it with William (and am a member of ComRel). The hope
is that transparency reports will dissuade ComRel from ignoring
reports.

I've heard from other ComRel members in favor as well, FWIW.

I think we're entirely open to suggestions.

Re: [gentoo-project] rfc: comrel changes

[Roy Bamford]

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

On 2020.02.18 22:06, Matt Turner wrote:
> On Tue, Feb 18, 2020 at 12:13 PM Alec Warner <antarus@gentoo.org>
> wrote:
> >
> >
> >
> > On Mon, Feb 17, 2020 at 8:18 AM William Hubbs <williamh@gentoo.org>
> wrote:
> >>
> >> All,
> >>
> >> I realize that comrel is a thankless job, but it is an important
> one
> >> that helps preserve the health of the community.
> >>
> >> To facilitate this, I think we need to have some changes in the way
> comrel
> >> operates, so I would like to propose them here to see what other
> folks think.
> >>
> >> Since comrel is a special TLP like QA, I think the comrel lead,
> like
> >> the qa lead, should be confirmed by the council.
> >>
> >> When an issue is filed with comrel, the issue should be addressed
> >> within a reasonable time frame. As someone who has filed issues, I
> have
> >> seen them sit for months with no action taken.
> >> With all respect to comrel, this is unacceptable. You have a
> published
> >> policy for how you will process issues, so follow it. If you don't,
> it
> >> is very upsetting for users/developers who reach out to you for
> >> assistance, weakens your credibility, and by extension negatively
> affects the
> >> reputation of the entire Gentoo community.
> >>
> >> To promote more transparency with comrel, I would like to
> >> require the comrel lead to send a report to the gentoo-project list
> monthly
> >> containing these statistics for the previous month:
> >>
> >> - number of bugs received
> >> - number of bugs pending (this is for bugs that are currently in
> process)
> >> - number of bugs resolved by actions (such as talking to
> >>   developers or disciplinary action)
> >> - number of bugs closed without action
> >>
> >> - number of mediation requests received
> >> - number of mediation requests resolved
> >> - number of mediation requests escalated to bugs
> >> - number of mediation requests dismissed without action
> >>
> >> The comrel lead should be replaced if this report is not sent for
> three
> >> consecutive months.
> >>
> >> What do others think?
> >
> >
> > I'm a little bit concerned that this addresses the symptoms instead
> of the problem. Have you shared your concerns with comrel regarding
> their lack of timely communication on reported issues? Do they even
> share the same goals you enumerated?
> >
> > My strawperson argument is that:
> >  - (0) The council will elect some lead.
> >  - The lead will never write reports (or write them but stop.)
> >  - The lead will get removed per policy.
> >  - Council will elect a new lead.
> >  - GOTO 0
> >
> > This isn't to say I dislike the concept of publishing transparency
> report (I do like it) but I'm not sure a report completely solves the
> problems that comrel actually faces today and I'd be interested to
> learn more about
> >
> 
> I've discussed it with William (and am a member of ComRel). The hope
> is that transparency reports will dissuade ComRel from ignoring
> reports.
> 
> I've heard from other ComRel members in favor as well, FWIW.
> 
> I think we're entirely open to suggestions.
> 
> 

Metrics allow the current state to be measured and compared to 
future states. They are the first step in gauging the magnatude of 
a problem, if one exists. 

Metrics won't help fix any problems though. Fixes require causes
to be established and addressed, which in turn requires that the 
operation of comrel be looked into somehow.

-- 
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: comrel changes

[Michael 'veremitz' Everitt]

[-- Attachment #1.1.1: Type: text/plain, Size: 4005 bytes --]

On 18/02/20 20:12, Alec Warner wrote:
>
>
> On Mon, Feb 17, 2020 at 8:18 AM William Hubbs <williamh@gentoo.org
> <mailto:williamh@gentoo.org>> wrote:
>
>     All,
>
>     I realize that comrel is a thankless job, but it is an important one
>     that helps preserve the health of the community.
>
>     To facilitate this, I think we need to have some changes in the way
>     comrel
>     operates, so I would like to propose them here to see what other
>     folks think.
>
>     Since comrel is a special TLP like QA, I think the comrel lead, like
>     the qa lead, should be confirmed by the council.
>
>     When an issue is filed with comrel, the issue should be addressed
>     within a reasonable time frame. As someone who has filed issues, I have
>     seen them sit for months with no action taken.
>     With all respect to comrel, this is unacceptable. You have a published
>     policy for how you will process issues, so follow it. If you don't, it
>     is very upsetting for users/developers who reach out to you for
>     assistance, weakens your credibility, and by extension negatively
>     affects the
>     reputation of the entire Gentoo community.
>
>     To promote more transparency with comrel, I would like to
>     require the comrel lead to send a report to the gentoo-project list
>     monthly
>     containing these statistics for the previous month:
>
>     - number of bugs received
>     - number of bugs pending (this is for bugs that are currently in process)
>     - number of bugs resolved by actions (such as talking to
>       developers or disciplinary action)
>     - number of bugs closed without action
>
>     - number of mediation requests received
>     - number of mediation requests resolved
>     - number of mediation requests escalated to bugs
>     - number of mediation requests dismissed without action
>
>     The comrel lead should be replaced if this report is not sent for three
>     consecutive months.
>
>     What do others think?
>
>
> I'm a little bit concerned that this addresses the symptoms instead of
> the problem. Have you shared your concerns with comrel regarding their
> lack of timely communication on reported issues? Do they even share the
> same goals you enumerated?
>
> My strawperson argument is that:
>  - (0) The council will elect some lead.
>  - The lead will never write reports (or write them but stop.)
>  - The lead will get removed per policy.
>  - Council will elect a new lead.
>  - GOTO 0
>
> This isn't to say I dislike the concept of publishing transparency report
> (I do like it) but I'm not sure a report completely solves the problems
> that comrel actually faces today and I'd be interested to learn more about 
>
> -A
>  
>
>
>     Thanks,
>
>     William
>
Here is an interesting timeline report of an example ComRel bug, all
details redacted to protect the "innocent" ...

[redacted] 2020-02-10 15:18:53 GMT

[redacted] 2020-02-10 15:19:19 GMT

Comment 1 [redacted] 2020-02-10 15:20:35 GMT

Comment 2 [redacted] 2020-02-10 20:05:37 GMT

Comment 3 [redacted] 2020-02-10 22:17:43 GMT

Comment 4 [redacted] 2020-02-11 08:31:21 GMT

Comment 5 [redacted] 2020-02-11 10:16:42 GMT

Comment 6 [redacted] 2020-02-11 10:21:26 GMT

Comment 7 [redacted] 2020-02-11 10:28:10 GMT

Comment 8 [redacted] 2020-02-11 20:48:33 GMT

Comment 9 [redacted] 2020-02-14 11:19:48 GMT

Comment 10 [redacted] 2020-02-18 16:06:19 GMT

Comment 11 [redacted] 2020-02-18 16:17:34 GMT

Comment 12 [redacted] 2020-02-18 21:30:53 GMT

And we don't even have a vote of all ComRel members yet, on a matter that
either Proctors would ordinarily have enacted, and probably even would have
expired by this late-in-the-game. OK so the proposal is more "serious" than
the proctors are currently responsible for, but I feel it shines a light on
one of the probable perceived issues of ComRel's .. action.. or inaction...

[-- Attachment #1.1.2: Type: text/html, Size: 6335 bytes --]

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

Re: [gentoo-project] rfc: comrel changes

[Chí-Thanh Christopher Nguyễn]

Alec Warner schrieb:

> I'm a little bit concerned that this addresses the symptoms instead of the  problem. Have you shared your concerns with comrel regarding their lack of  timely communication on reported issues? Do they even share the same goals  you enumerated?
> 
> My strawperson argument is that:
>   - (0) The council will elect some lead.
>   - The lead will never write reports (or write them but stop.)
>   - The lead will get removed per policy.
>   - Council will elect a new lead.
>   - GOTO 0

My suggestion is in that case of missed report deadline, Council asks for 
volunteers from the developer community to step up, and appoints two of them 
to go through ComRel records and produce the transparency report.

Regular independent review of ComRel activity is what NeddySeagoon and I 
originally suggested and discussed with ComRel a while back. But they seemed 
completely against it, so we eventually dropped it.


Best regards,
Chí-Thanh Christopher Nguyễn

Re: [gentoo-project] rfc: comrel changes

[Thomas Deutschmann]

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

Hi,

I also don't understand what you expect from metrics.

Imagine the following metrics for January:

> - number of bugs received:                               22
> - number of bugs pending:                                10
> - number of bugs resolved by actions:                    2
> - number of bugs closed without action:                  10
> 
> - number of mediation requests received:                 0
> - number of mediation requests resolved:                 0
> - number of mediation requests escalated to bugs:        0
> - number of mediation requests dismissed without action: 0

Now what? :-)

These numbers have no real meaning. Without knowing why 10 bugs are
pending you don't know if ComRel people are slackers or if bugs were
just filed in the last day(s) of January.

Without knowing details nobody can answer if ComRel people are slackers,
acting like the US supreme court or if it was OK to close 10 bugs
without any action.

The thing is, people *will* read *something* into these numbers which
can only go wrong and won't help us. For me, it's the same like the
transparency reports from Google, Facebook, Twitter: The number of
requests is increasing each year. Is that happening because authorities
around the world are more and more persecuting their citizen? Or is it
just because more and more authorities gained access to that instrument
which can now be used using some kind of standards? How does everything
correlate to service usage at all? You don't know but you can use such
reports to generate whatever message you like to send out. In the end,
these transparency reports are just some kind of show to keep people
quiet (Look, we do something!).

If we are interested in transparency, how about the following 'radical'
change: Let's make bugs *public*, at least for project members. In this
way, each project member can form their own view/opinion based on real
facts.

Maybe not from the beginning like some court hearings (trials) aren't
public as well. But because ComRel is speaking 'in the name of the
project', bugs should become accessible at least for project members
when ComRel's job is done like court decision are usually published.


-- 
Regards,
Thomas Deutschmann / Gentoo Linux Developer
fpr: 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] rfc: comrel changes

[Luca Barbato]

On 21/02/2020 00:40, Thomas Deutschmann wrote:

> If we are interested in transparency, how about the following 'radical'
> change: Let's make bugs *public*, at least for project members. In this
> way, each project member can form their own view/opinion based on real
> facts.
> 
> Maybe not from the beginning like some court hearings (trials) aren't
> public as well. But because ComRel is speaking 'in the name of the
> project', bugs should become accessible at least for project members
> when ComRel's job is done like court decision are usually published.

We could do that but this would have some chilling effect.

We also could do that the issues are opened only if all the people 
involved agree to make them open to the project members.

I would not make them public and I would still require some modicum of 
confidentiality.

lu

Re: [gentoo-project] rfc: comrel changes

[Mikle Kolyada]

On 21.02.2020 11:17, Luca Barbato wrote:
> On 21/02/2020 00:40, Thomas Deutschmann wrote:
>
>> If we are interested in transparency, how about the following 'radical'
>> change: Let's make bugs *public*, at least for project members. In this
>> way, each project member can form their own view/opinion based on real
>> facts.
>>
>> Maybe not from the beginning like some court hearings (trials) aren't
>> public as well. But because ComRel is speaking 'in the name of the
>> project', bugs should become accessible at least for project members
>> when ComRel's job is done like court decision are usually published.
>
> We could do that but this would have some chilling effect.
>
> We also could do that the issues are opened only if all the people 
> involved agree to make them open to the project members.
>
> I would not make them public and I would still require some modicum of 
> confidentiality.
>
> lu
>
>

...this is not to mention that some people who are somehow involved in 
ComRel cases explicitly ask us not to disclosure the data we receive as 
it may be considered sensitive even after some considerable amount of time.

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Fri, 2020-02-21 at 00:40 +0100, Thomas Deutschmann wrote:
> These numbers have no real meaning. Without knowing why 10 bugs are
> pending you don't know if ComRel people are slackers or if bugs were
> just filed in the last day(s) of January.
> 
> Without knowing details nobody can answer if ComRel people are slackers,
> acting like the US supreme court or if it was OK to close 10 bugs
> without any action.

You are right here.

> If we are interested in transparency, how about the following 'radical'
> change: Let's make bugs *public*, at least for project members. In this
> way, each project member can form their own view/opinion based on real
> facts.
> 

This is not going to work.  If you forcibly require all ComRel bugs to
be public, some people will just stop filing them.  While some people
might now read into it that we have less problems, in practice it will
just mean less people admit to the existence of problems.

You should note that some people are really toxic.  I know that you
reserve this term for me but believe me, there are much worse people
around here.  People who are going to harass you in every way possible
if you stand up to them, people who will seek retaliation.  You don't
want to get on their blacklist.

I'm not saying this is always possible.  But in the general case of,
say, someone repeatedly misbehaving on public mailing lists, you can
handle the case without having to blame a specific person (people) for
requesting it, and therefore putting them in the crosshairs.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Thu, 2020-02-20 at 22:24 +0100, Chí-Thanh Christopher Nguyễn wrote:
> Alec Warner schrieb:
> 
> > I'm a little bit concerned that this addresses the symptoms instead of the  problem. Have you shared your concerns with comrel regarding their lack of  timely communication on reported issues? Do they even share the same goals  you enumerated?
> > 
> > My strawperson argument is that:
> >   - (0) The council will elect some lead.
> >   - The lead will never write reports (or write them but stop.)
> >   - The lead will get removed per policy.
> >   - Council will elect a new lead.
> >   - GOTO 0
> 
> My suggestion is in that case of missed report deadline, Council asks for 
> volunteers from the developer community to step up, and appoints two of them 
> to go through ComRel records and produce the transparency report.
> 
> Regular independent review of ComRel activity is what NeddySeagoon and I 
> originally suggested and discussed with ComRel a while back. But they seemed 
> completely against it, so we eventually dropped it.
> 

All things considered, maybe creating a separate 'revision' group would
be better, independently of the reports.  Either split ComRel in two, or
appoint something independent.  Let 'core' ComRel do their work, while
the 'revision' group merely monitor their activities without getting
directly involved in the process.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Luca Barbato]

On 21/02/2020 10:19, Michał Górny wrote:
> All things considered, maybe creating a separate 'revision' group would
> be better, independently of the reports.  Either split ComRel in two, or
> appoint something independent.  Let 'core' ComRel do their work, while
> the 'revision' group merely monitor their activities without getting
> directly involved in the process.
> 

That would be a good idea in general, but shall we keep in mind that 
comrel activity should be 0 most of the time?

I know that the assumption of being able to get along w/out having a 
third party involved is really strong but...

lu

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Fri, 2020-02-21 at 10:26 +0100, Luca Barbato wrote:
> On 21/02/2020 10:19, Michał Górny wrote:
> > All things considered, maybe creating a separate 'revision' group would
> > be better, independently of the reports.  Either split ComRel in two, or
> > appoint something independent.  Let 'core' ComRel do their work, while
> > the 'revision' group merely monitor their activities without getting
> > directly involved in the process.
> > 
> 
> That would be a good idea in general, but shall we keep in mind that 
> comrel activity should be 0 most of the time?
> 

I don't see that as really relevant here.  If it wasn't clear, I meant
that the 'revision' group would have access to all bugs and mails.  Its
main purpose would be to raise the alarm if ComRel doesn't seem to do
their work properly.

That said, I'm not claiming that this will make any real difference
in practice.  I guess it could end up in having ComRel-A with their own
opinion vs. ComRel-B with their own opinion.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Luca Barbato]

On 21/02/2020 10:38, Michał Górny wrote:
> On Fri, 2020-02-21 at 10:26 +0100, Luca Barbato wrote:
>> On 21/02/2020 10:19, Michał Górny wrote:
>>> All things considered, maybe creating a separate 'revision' group would
>>> be better, independently of the reports.  Either split ComRel in two, or
>>> appoint something independent.  Let 'core' ComRel do their work, while
>>> the 'revision' group merely monitor their activities without getting
>>> directly involved in the process.
>>>
>>
>> That would be a good idea in general, but shall we keep in mind that
>> comrel activity should be 0 most of the time?
>>
> 
> I don't see that as really relevant here.  If it wasn't clear, I meant
> that the 'revision' group would have access to all bugs and mails.  Its
> main purpose would be to raise the alarm if ComRel doesn't seem to do
> their work properly.
> 
> That said, I'm not claiming that this will make any real difference
> in practice.  I guess it could end up in having ComRel-A with their own
> opinion vs. ComRel-B with their own opinion.
> 

That's another kind of problem. I guess we should try to unpack a bit 
what's comrel about.

lu

Re: [gentoo-project] rfc: comrel changes

[Roy Bamford]

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

On 2020.02.21 09:19, Michał Górny wrote:
> On Thu, 2020-02-20 at 22:24 +0100, Chí-Thanh Christopher Nguyễn wrote:
> > Alec Warner schrieb:
> > 
> > > I'm a little bit concerned that this addresses the symptoms
> instead of the  problem. Have you shared your concerns with comrel
> regarding their lack of  timely communication on reported issues? Do
> they even share the same goals  you enumerated?
> > > 
> > > My strawperson argument is that:
> > >   - (0) The council will elect some lead.
> > >   - The lead will never write reports (or write them but stop.)
> > >   - The lead will get removed per policy.
> > >   - Council will elect a new lead.
> > >   - GOTO 0
> > 
> > My suggestion is in that case of missed report deadline, Council
> asks for 
> > volunteers from the developer community to step up, and appoints two
> of them 
> > to go through ComRel records and produce the transparency report.
> > 
> > Regular independent review of ComRel activity is what NeddySeagoon
> and I 
> > originally suggested and discussed with ComRel a while back. But
> they seemed 
> > completely against it, so we eventually dropped it.
> > 
> 
> All things considered, maybe creating a separate 'revision' group
> would
> be better, independently of the reports.  Either split ComRel in two,
> or
> appoint something independent.  Let 'core' ComRel do their work, while
> the 'revision' group merely monitor their activities without getting
> directly involved in the process.
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

This 'revision' group alread exists. Its called the Gentoo council.
Unless, that is, council have no oversight of comrel?

-- 
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: comrel changes

[Michał Górny]

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

On Fri, 2020-02-21 at 22:11 +0000, Roy Bamford wrote:
> On 2020.02.21 09:19, Michał Górny wrote:
> > On Thu, 2020-02-20 at 22:24 +0100, Chí-Thanh Christopher Nguyễn wrote:
> > > Alec Warner schrieb:
> > > 
> > > > I'm a little bit concerned that this addresses the symptoms
> > instead of the  problem. Have you shared your concerns with comrel
> > regarding their lack of  timely communication on reported issues? Do
> > they even share the same goals  you enumerated?
> > > > My strawperson argument is that:
> > > >   - (0) The council will elect some lead.
> > > >   - The lead will never write reports (or write them but stop.)
> > > >   - The lead will get removed per policy.
> > > >   - Council will elect a new lead.
> > > >   - GOTO 0
> > > 
> > > My suggestion is in that case of missed report deadline, Council
> > asks for 
> > > volunteers from the developer community to step up, and appoints two
> > of them 
> > > to go through ComRel records and produce the transparency report.
> > > 
> > > Regular independent review of ComRel activity is what NeddySeagoon
> > and I 
> > > originally suggested and discussed with ComRel a while back. But
> > they seemed 
> > > completely against it, so we eventually dropped it.
> > > 
> > 
> > All things considered, maybe creating a separate 'revision' group
> > would
> > be better, independently of the reports.  Either split ComRel in two,
> > or
> > appoint something independent.  Let 'core' ComRel do their work, while
> > the 'revision' group merely monitor their activities without getting
> > directly involved in the process.
> 
> This 'revision' group alread exists. Its called the Gentoo council.
> Unless, that is, council have no oversight of comrel?

No, that's not how things work.  You don't have an appeal body
proactively look into what all projects are doing.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Michael 'veremitz' Everitt]

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

On 22/02/20 05:39, Michał Górny wrote:
> On Fri, 2020-02-21 at 22:11 +0000, Roy Bamford wrote:
>> On 2020.02.21 09:19, Michał Górny wrote:
>>> On Thu, 2020-02-20 at 22:24 +0100, Chí-Thanh Christopher Nguyễn wrote:
>>>> Alec Warner schrieb:
>>>>
>>>>> I'm a little bit concerned that this addresses the symptoms
>>> instead of the  problem. Have you shared your concerns with comrel
>>> regarding their lack of  timely communication on reported issues? Do
>>> they even share the same goals  you enumerated?
>>>>> My strawperson argument is that:
>>>>>   - (0) The council will elect some lead.
>>>>>   - The lead will never write reports (or write them but stop.)
>>>>>   - The lead will get removed per policy.
>>>>>   - Council will elect a new lead.
>>>>>   - GOTO 0
>>>> My suggestion is in that case of missed report deadline, Council
>>> asks for 
>>>> volunteers from the developer community to step up, and appoints two
>>> of them 
>>>> to go through ComRel records and produce the transparency report.
>>>>
>>>> Regular independent review of ComRel activity is what NeddySeagoon
>>> and I 
>>>> originally suggested and discussed with ComRel a while back. But
>>> they seemed 
>>>> completely against it, so we eventually dropped it.
>>>>
>>> All things considered, maybe creating a separate 'revision' group
>>> would
>>> be better, independently of the reports.  Either split ComRel in two,
>>> or
>>> appoint something independent.  Let 'core' ComRel do their work, while
>>> the 'revision' group merely monitor their activities without getting
>>> directly involved in the process.
>> This 'revision' group alread exists. Its called the Gentoo council.
>> Unless, that is, council have no oversight of comrel?
> No, that's not how things work.  You don't have an appeal body
> proactively look into what all projects are doing.
>
Why not? An appeal has specific information that the review body won't
ordinarily have access to? Or so I would expect?

We're not expecting council to actively be a part of ComRel, just monitor
it? Or does that take away from council simply being a passive body?


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

Re: [gentoo-project] rfc: comrel changes

[Alec Warner]

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

On Fri, Feb 21, 2020 at 9:39 PM Michał Górny <mgorny@gentoo.org> wrote:

> On Fri, 2020-02-21 at 22:11 +0000, Roy Bamford wrote:
> > On 2020.02.21 09:19, Michał Górny wrote:
> > > On Thu, 2020-02-20 at 22:24 +0100, Chí-Thanh Christopher Nguyễn wrote:
> > > > Alec Warner schrieb:
> > > >
> > > > > I'm a little bit concerned that this addresses the symptoms
> > > instead of the  problem. Have you shared your concerns with comrel
> > > regarding their lack of  timely communication on reported issues? Do
> > > they even share the same goals  you enumerated?
> > > > > My strawperson argument is that:
> > > > >   - (0) The council will elect some lead.
> > > > >   - The lead will never write reports (or write them but stop.)
> > > > >   - The lead will get removed per policy.
> > > > >   - Council will elect a new lead.
> > > > >   - GOTO 0
> > > >
> > > > My suggestion is in that case of missed report deadline, Council
> > > asks for
> > > > volunteers from the developer community to step up, and appoints two
> > > of them
> > > > to go through ComRel records and produce the transparency report.
> > > >
> > > > Regular independent review of ComRel activity is what NeddySeagoon
> > > and I
> > > > originally suggested and discussed with ComRel a while back. But
> > > they seemed
> > > > completely against it, so we eventually dropped it.
> > > >
> > >
> > > All things considered, maybe creating a separate 'revision' group
> > > would
> > > be better, independently of the reports.  Either split ComRel in two,
> > > or
> > > appoint something independent.  Let 'core' ComRel do their work, while
> > > the 'revision' group merely monitor their activities without getting
> > > directly involved in the process.
> >
> > This 'revision' group alread exists. Its called the Gentoo council.
> > Unless, that is, council have no oversight of comrel?
>
> No, that's not how things work.  You don't have an appeal body
> proactively look into what all projects are doing.
>

I think by definition this is reactive. Comrel publishes a report[0], and
the Council[1] reviews it. Could it lead to horrific fishing expeditions?
Sure. But there is always risk in oversight. Building an ideal system is
not possible; there are trade offs in engineering and there are tradeoffs
in organizational structure and accountability.

In some new system where there is oversight of comrel we will have people
who can peek into the decision making process and:
 - leak private details
 - potentially reverse decisions
 - potentially force action with incomplete information (e.g. to meet some
arbitrary deadline to "make cases be resolved faster."

These are all potential risks. Will they happen? Hard to know without
trying.

-A

[0] FWIW the Trustees are also potentially interested in the report.
[1] The council can always delegate it to someone. Accountability (I am
accountable for X) and Responsibility (I will literally do X) are not the
same thing.


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

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

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Sat, 2020-02-22 at 22:35 -0800, Alec Warner wrote:
> On Fri, Feb 21, 2020 at 9:39 PM Michał Górny <mgorny@gentoo.org> wrote:
> 
> > On Fri, 2020-02-21 at 22:11 +0000, Roy Bamford wrote:
> > > This 'revision' group alread exists. Its called the Gentoo council.
> > > Unless, that is, council have no oversight of comrel?
> > 
> > No, that's not how things work.  You don't have an appeal body
> > proactively look into what all projects are doing.
> > 
> 
> I think by definition this is reactive. Comrel publishes a report[0], and
> the Council[1] reviews it.

I thought we've already established that the reports are meaningless.

The way I see it, your system basically means that, repeatedly:

1. ComRel does their job.

2. ComRel wastes their time publishing a meaningless report.

3. Since the report is meaningless, Council has to audit ComRel's work.

Since digging for past data is usually more effort than processing it
as it flows, Council may as well start proactively auditing everything. 
Except that's not its purpose, and I don't see why we should throw
random extra tasks on their plate just because.

In my opinion, if we are to go for auditing ComRel, we should select
a separate group of people for that, people that choose to put their
effort into auditing rather than incidentally get dragged into it.
Furthermore, I believe this group should not have any direct deciding
power.  Instead, they should bring any issues their find to ComRel's
attention and/or appeal them to the Council.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Mikle Kolyada]

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


On 24.02.2020 10:47, Michał Górny wrote:
> On Sat, 2020-02-22 at 22:35 -0800, Alec Warner wrote:
>> On Fri, Feb 21, 2020 at 9:39 PM Michał Górny <mgorny@gentoo.org> wrote:
>>
>>> On Fri, 2020-02-21 at 22:11 +0000, Roy Bamford wrote:
>>>> This 'revision' group alread exists. Its called the Gentoo council.
>>>> Unless, that is, council have no oversight of comrel?
>>> No, that's not how things work.  You don't have an appeal body
>>> proactively look into what all projects are doing.
>>>
>> I think by definition this is reactive. Comrel publishes a report[0], and
>> the Council[1] reviews it.
> I thought we've already established that the reports are meaningless.
>
> The way I see it, your system basically means that, repeatedly:
>
> 1. ComRel does their job.
>
> 2. ComRel wastes their time publishing a meaningless report.
>
> 3. Since the report is meaningless, Council has to audit ComRel's work.
>
> Since digging for past data is usually more effort than processing it
> as it flows, Council may as well start proactively auditing everything. 
> Except that's not its purpose, and I don't see why we should throw
> random extra tasks on their plate just because.
>
> In my opinion, if we are to go for auditing ComRel, we should select
> a separate group of people for that, people that choose to put their
> effort into auditing rather than incidentally get dragged into it.
> Furthermore, I believe this group should not have any direct deciding
> power.  Instead, they should bring any issues their find to ComRel's
> attention and/or appeal them to the Council.
>

This is meaningless also, because an individual who finds ComRel
decision unacceptable can appeal to Council directly, you do not need
third party layer here.



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

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Mon, 2020-02-24 at 11:08 +0300, Mikle Kolyada wrote:
> On 24.02.2020 10:47, Michał Górny wrote:
> > On Sat, 2020-02-22 at 22:35 -0800, Alec Warner wrote:
> > > On Fri, Feb 21, 2020 at 9:39 PM Michał Górny <mgorny@gentoo.org> wrote:
> > > 
> > > > On Fri, 2020-02-21 at 22:11 +0000, Roy Bamford wrote:
> > > > > This 'revision' group alread exists. Its called the Gentoo council.
> > > > > Unless, that is, council have no oversight of comrel?
> > > > No, that's not how things work.  You don't have an appeal body
> > > > proactively look into what all projects are doing.
> > > > 
> > > I think by definition this is reactive. Comrel publishes a report[0], and
> > > the Council[1] reviews it.
> > I thought we've already established that the reports are meaningless.
> > 
> > The way I see it, your system basically means that, repeatedly:
> > 
> > 1. ComRel does their job.
> > 
> > 2. ComRel wastes their time publishing a meaningless report.
> > 
> > 3. Since the report is meaningless, Council has to audit ComRel's work.
> > 
> > Since digging for past data is usually more effort than processing it
> > as it flows, Council may as well start proactively auditing everything. 
> > Except that's not its purpose, and I don't see why we should throw
> > random extra tasks on their plate just because.
> > 
> > In my opinion, if we are to go for auditing ComRel, we should select
> > a separate group of people for that, people that choose to put their
> > effort into auditing rather than incidentally get dragged into it.
> > Furthermore, I believe this group should not have any direct deciding
> > power.  Instead, they should bring any issues their find to ComRel's
> > attention and/or appeal them to the Council.
> > 
> 
> This is meaningless also, because an individual who finds ComRel
> decision unacceptable can appeal to Council directly, you do not need
> third party layer here.

The individual can only judge the reply to his own request.  He lacks
the wider context to audit the process and decisions (or lack of them)
wrt multiple different requests.

This works both ways.  People are also making accusations and claim
about ComRel based on what they guess might be happening.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Mikle Kolyada]

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


On 24.02.2020 11:19, Michał Górny wrote:
> On Mon, 2020-02-24 at 11:08 +0300, Mikle Kolyada wrote:
>> On 24.02.2020 10:47, Michał Górny wrote:
>>> On Sat, 2020-02-22 at 22:35 -0800, Alec Warner wrote:
>>>> On Fri, Feb 21, 2020 at 9:39 PM Michał Górny <mgorny@gentoo.org> wrote:
>>>>
>>>>> On Fri, 2020-02-21 at 22:11 +0000, Roy Bamford wrote:
>>>>>> This 'revision' group alread exists. Its called the Gentoo council.
>>>>>> Unless, that is, council have no oversight of comrel?
>>>>> No, that's not how things work.  You don't have an appeal body
>>>>> proactively look into what all projects are doing.
>>>>>
>>>> I think by definition this is reactive. Comrel publishes a report[0], and
>>>> the Council[1] reviews it.
>>> I thought we've already established that the reports are meaningless.
>>>
>>> The way I see it, your system basically means that, repeatedly:
>>>
>>> 1. ComRel does their job.
>>>
>>> 2. ComRel wastes their time publishing a meaningless report.
>>>
>>> 3. Since the report is meaningless, Council has to audit ComRel's work.
>>>
>>> Since digging for past data is usually more effort than processing it
>>> as it flows, Council may as well start proactively auditing everything. 
>>> Except that's not its purpose, and I don't see why we should throw
>>> random extra tasks on their plate just because.
>>>
>>> In my opinion, if we are to go for auditing ComRel, we should select
>>> a separate group of people for that, people that choose to put their
>>> effort into auditing rather than incidentally get dragged into it.
>>> Furthermore, I believe this group should not have any direct deciding
>>> power.  Instead, they should bring any issues their find to ComRel's
>>> attention and/or appeal them to the Council.
>>>
>> This is meaningless also, because an individual who finds ComRel
>> decision unacceptable can appeal to Council directly, you do not need
>> third party layer here.
> The individual can only judge the reply to his own request.  He lacks
> the wider context to audit the process and decisions (or lack of them)
> wrt multiple different requests.
>
> This works both ways.  People are also making accusations and claim
> about ComRel based on what they guess might be happening

The same applies to any third party review body. let's imagine:


1. A review body finds something unacceptable and want it to be reviewed
by council

1a. A review body requests more details from ComRel to understand a case
better

1b. ComRel provides more details

1c. A review body decides to appeal to the Council

2. Council starts to review the decision

2a. Council requests data a review body collected

2b. Council requests input from ComRel (because there maybe something
missing by chance, etc)


As a result we have more busywork, this all can be conveyed to Council
directly. Also this is unclear to me how a review body will decide what
to appeal and what hot to, as the data is still being kept private and
reviewers are going to only have a decision on hands. Having only
decision is not enough to start thinking ComRel did anything wrong
(well, unless there were direct rules violation, which, to my knowledge
has never been the case).




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

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Mon, 2020-02-24 at 11:36 +0300, Mikle Kolyada wrote:
> As a result we have more busywork, this all can be conveyed to Council
> directly. Also this is unclear to me how a review body will decide what
> to appeal and what hot to, as the data is still being kept private and
> reviewers are going to only have a decision on hands. Having only
> decision is not enough to start thinking ComRel did anything wrong
> (well, unless there were direct rules violation, which, to my knowledge
> has never been the case).

The whole point is that the review body has direct access to all
the data (i.e. bugzilla privs, comrel@ alias, IRC channels).  Unlike
your 'individual' it is considered trusted and therefore you don't have
to 'prepare' data for it.

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Mikle Kolyada]

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


On 24.02.2020 11:39, Michał Górny wrote:
> On Mon, 2020-02-24 at 11:36 +0300, Mikle Kolyada wrote:
>> As a result we have more busywork, this all can be conveyed to Council
>> directly. Also this is unclear to me how a review body will decide what
>> to appeal and what hot to, as the data is still being kept private and
>> reviewers are going to only have a decision on hands. Having only
>> decision is not enough to start thinking ComRel did anything wrong
>> (well, unless there were direct rules violation, which, to my knowledge
>> has never been the case).
> The whole point is that the review body has direct access to all
> the data (i.e. bugzilla privs, comrel@ alias, IRC channels).  Unlike
> your 'individual' it is considered trusted and therefore you don't have
> to 'prepare' data for it.
>
Then as a result you are going to have yet another semi-closed process 
which does not make the entire procedure more transparent (which was the
main concern of this thread).



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

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Mon, 2020-02-24 at 11:47 +0300, Mikle Kolyada wrote:
> On 24.02.2020 11:39, Michał Górny wrote:
> > On Mon, 2020-02-24 at 11:36 +0300, Mikle Kolyada wrote:
> > > As a result we have more busywork, this all can be conveyed to Council
> > > directly. Also this is unclear to me how a review body will decide what
> > > to appeal and what hot to, as the data is still being kept private and
> > > reviewers are going to only have a decision on hands. Having only
> > > decision is not enough to start thinking ComRel did anything wrong
> > > (well, unless there were direct rules violation, which, to my knowledge
> > > has never been the case).
> > The whole point is that the review body has direct access to all
> > the data (i.e. bugzilla privs, comrel@ alias, IRC channels).  Unlike
> > your 'individual' it is considered trusted and therefore you don't have
> > to 'prepare' data for it.
> > 
> Then as a result you are going to have yet another semi-closed process 
> which does not make the entire procedure more transparent (which was the
> main concern of this thread).
> 

Obviously.  When you can't publish all the data, an 'independent' audit
is the best you can get.


-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Roy Bamford]

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

On 2020.02.24 08:55, Michał Górny wrote:
> On Mon, 2020-02-24 at 11:47 +0300, Mikle Kolyada wrote:
> > On 24.02.2020 11:39, Michał Górny wrote:
> > > On Mon, 2020-02-24 at 11:36 +0300, Mikle Kolyada wrote:
> > > > As a result we have more busywork, this all can be conveyed to
> Council
> > > > directly. Also this is unclear to me how a review body will
> decide what
> > > > to appeal and what hot to, as the data is still being kept
> private and
> > > > reviewers are going to only have a decision on hands. Having
> only
> > > > decision is not enough to start thinking ComRel did anything
> wrong
> > > > (well, unless there were direct rules violation, which, to my
> knowledge
> > > > has never been the case).
> > > The whole point is that the review body has direct access to all
> > > the data (i.e. bugzilla privs, comrel@ alias, IRC channels). 
> Unlike
> > > your 'individual' it is considered trusted and therefore you don't
> have
> > > to 'prepare' data for it.
> > > 
> > Then as a result you are going to have yet another semi-closed
> process 
> > which does not make the entire procedure more transparent (which was
> the
> > main concern of this thread).
> > 
> 
> Obviously.  When you can't publish all the data, an 'independent'
> audit
> is the best you can get.
> 
> 
> -- 
> Best regards,
> Michał Górny
> 
> 

Team,

We are trying to define a solution before the problem(s) we want to solve
has/have been framed.

What problems, (if any), need to be addressed?

Once problems and potential solutions have been agreed then metrics
can be designed to measure the efficacy (or oherwise) of the solutions.

So what are the perceived problem(s) ?

Potential solutions and metrics are out of scope meanwhile. 
-- 
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: comrel changes

[Matt Turner]

On Mon, Feb 24, 2020 at 1:04 PM Roy Bamford <neddyseagoon@gentoo.org> wrote:
> Team,
>
> We are trying to define a solution before the problem(s) we want to solve
> has/have been framed.
>
> What problems, (if any), need to be addressed?
>
> Once problems and potential solutions have been agreed then metrics
> can be designed to measure the efficacy (or oherwise) of the solutions.
>
> So what are the perceived problem(s) ?
>
> Potential solutions and metrics are out of scope meanwhile.

<comrel-hat>
Inside of ComRel I see way too much analysis paralysis. Discussion of
the most minute details ad infinitum. Endless debate about whether
it's more appropriate to use "should" or "needs to" in a response
(among three non-native speakers! :D). Large differences in opinion
among ComRel members about the efficacy of punishments, about the
severity of infractions, etc. Very little cohesion. The aim of the
monthly reports, in my view, would be to act as a forcing function to
respond more quickly to reports.

People will be pissed if ComRel bans someone and people will be pissed
if ComRel doesn't ban that same someone. That's more or less to be
expected. The thing that's missing (in my view) is a sense of
legitimacy on the part of ComRel to act on behalf of the greater
community. I sense this lack of legitimacy pretty often among
developers.

Complaints probably follow the 80/20 rule
(https://en.wikipedia.org/wiki/Pareto_principle) (80% of reports are
about 20% of people). It's not clear that some of these cases are
"solvable" in a way that keeps both the reporter and reportee in the
community. How do we balance that? Knowing how devs feel about general
questions like this would inform at least me about how I should vote.
</comrel-hat>

Outside of ComRel the problem I've personally had is that reports have
been ignored. In fact, one report lead to agreement that a ComRel
action should take place and then... nothing. Once ComRel responded
again the lead at the time said too much time had passed (~a month) to
punish the person now. Extremely frustrating for reporters. I don't
think I'm the only one with this sort of experience. (I suggest that
we require bugs to be filed -- not emailed to comrel@ -- so they're
more easily tracked).

That's at least what comes to mind most immediately...

Re: [gentoo-project] rfc: comrel changes

[William Hubbs]

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

On Mon, Feb 24, 2020 at 05:27:53PM -0800, Matt Turner wrote:
> On Mon, Feb 24, 2020 at 1:04 PM Roy Bamford <neddyseagoon@gentoo.org> wrote:
> > Team,
> >
> > We are trying to define a solution before the problem(s) we want to solve
> > has/have been framed.
> >
> > What problems, (if any), need to be addressed?
> >
> > Once problems and potential solutions have been agreed then metrics
> > can be designed to measure the efficacy (or oherwise) of the solutions.
> >
> > So what are the perceived problem(s) ?
> >
> > Potential solutions and metrics are out of scope meanwhile.
> 
> <comrel-hat>
> Inside of ComRel I see way too much analysis paralysis. Discussion of
> the most minute details ad infinitum. Endless debate about whether
> it's more appropriate to use "should" or "needs to" in a response
> (among three non-native speakers! :D). Large differences in opinion
> among ComRel members about the efficacy of punishments, about the
> severity of infractions, etc. Very little cohesion. The aim of the
> monthly reports, in my view, would be to act as a forcing function to
> respond more quickly to reports.
> 
> People will be pissed if ComRel bans someone and people will be pissed
> if ComRel doesn't ban that same someone. That's more or less to be
> expected. The thing that's missing (in my view) is a sense of
> legitimacy on the part of ComRel to act on behalf of the greater
> community. I sense this lack of legitimacy pretty often among
> developers.
> 
> Complaints probably follow the 80/20 rule
> (https://en.wikipedia.org/wiki/Pareto_principle) (80% of reports are
> about 20% of people). It's not clear that some of these cases are
> "solvable" in a way that keeps both the reporter and reportee in the
> community. How do we balance that? Knowing how devs feel about general
> questions like this would inform at least me about how I should vote.
> </comrel-hat>
 
As a non-comrel member, I think that at some point you have to act in a
way that makes things better for the community over-all. If this means
removing someone, especially someone who generates multiple reports,
thats unfortunately part of the job. I'm sure comrel is a thankless job,
but if it isn't done and the hard decisions are not made, the community suffers.

https://www.youtube.com/watch?v=wE_SpIdIGK4
http://www.brendangregg.com/blog/2017-11-13/brilliant-jerks.html

> Outside of ComRel the problem I've personally had is that reports have
> been ignored. In fact, one report lead to agreement that a ComRel
> action should take place and then... nothing. Once ComRel responded
> again the lead at the time said too much time had passed (~a month) to
> punish the person now. Extremely frustrating for reporters. I don't
> think I'm the only one with this sort of experience. (I suggest that
> we require bugs to be filed -- not emailed to comrel@ -- so they're
> more easily tracked).

Agreed, this is very demoralizing. Besides your suggestion of requiring
bugs to be filed, I would consider a hard timeout of 7-14 days when a
bug is filed. Once that timeout passes with no action from comrel, the
bug goes to the council. If this happens too many times (we could
discuss/agree on a number) it brings the affectiveness of comrel into
question and the council can take action such as replacing the lead.

Thoughts?

William


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

Re: [gentoo-project] rfc: comrel changes

[Rich Freeman]

On Wed, Feb 26, 2020 at 11:54 AM William Hubbs <williamh@gentoo.org> wrote:
>
> > Outside of ComRel the problem I've personally had is that reports have
> > been ignored. In fact, one report lead to agreement that a ComRel
> > action should take place and then... nothing. Once ComRel responded
> > again the lead at the time said too much time had passed (~a month) to
> > punish the person now. Extremely frustrating for reporters. I don't
> > think I'm the only one with this sort of experience. (I suggest that
> > we require bugs to be filed -- not emailed to comrel@ -- so they're
> > more easily tracked).
>
> Agreed, this is very demoralizing. Besides your suggestion of requiring
> bugs to be filed, I would consider a hard timeout of 7-14 days when a
> bug is filed. Once that timeout passes with no action from comrel, the
> bug goes to the council.

I think that this depends a bit on your definition of "no action."  Do
you mean no final decision?  Or simply no activity?  The former is
easy to measure, the latter is going to potentially a lot of heartbeat
activities that just kick the can.

I think comrel activities by their nature tend to require a bit of
investigation/etc.  They're also not intended to be purely punitive.
That is, the goal isn't just to decide "do we kick them out or not?"
The ideal comrel outcome would be if the parties involved were able to
resolve their differences, agree to work together in a more
mutually-agreeable fashion in the future, and for over the long term
this to actually happen.  Obviously this doesn't always happen, but
this ideal outcome is the sort that is actually the fuzziest to
measure:

1.  It probably takes a while to be "completed."  Kicking somebody out
or telling the complainant to go away is simpler than getting them to
hash out their issues.
2.  It doesn't involve a top-down decision so much as the parties
coming to an agreement.
3.  Its ultimate success isn't really demonstrated until much later in time.

Plus if you send it to council you're now faced with council having to
actually do all the investgating, arbitration, and so on.  When there
have been council appeals it has been more about examining descisions
to kick somebody out, with the investigations/etc already being done.
So, this was more about examining all the data and just affirming or
reversing the decision that was made.  However, stepping in earlier
means council members having to get their hands dirty.

Generally we've tried to make the council more of a decision body and
less of a hands-dirty body, deferring to QA/comrel/etc for these
activities.  This gives more people access to those roles, and also
allows council to effectively have their hands in everything while not
getting bogged down.

> I'm sure comrel is a thankless job, but if it isn't done and the hard decisions are not made, the community suffers.

IMO it isn't helpful for comrel to operate without ANY positive
feedback.  I think the current design makes it hard for people to
offer any kind of meaningful feedback.  However, if a job is important
to the community, then people should not feel that it is thankless.

It isn't just about making people feel good either.  Without any
positive feedback all you have is the negative, and it really does
become difficult to tell if you're having a positive impact.

Proctors basically hasn't done anything in the last 6 months or so and
I think part of it is that the few actions that have been taken have
almost exclusively received negative feedback.  I can't remember the
last time that somebody thanked me for taking some action (and unlike
Comrel the actions of proctors are much more visible).  How is that to
be interpreted as anything other than a community consensus that the
actions were inappropriate?  And if so, why would we want to keep
doing it?  Perhaps ignoring all requests for intervention is an
improvement.  Certainly I've seen far fewer complaints about inaction
than past actions.  No doubt this isn't helping with the Comrel
workload.

I guess the point is that if we want these bodies to do something,
there should be positive as well as negative reinforcement for the
actions they do/don't take.

-- 
Rich

Re: [gentoo-project] rfc: comrel changes

[William Hubbs]

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

On Wed, Feb 26, 2020 at 12:18:54PM -0500, Rich Freeman wrote:
> On Wed, Feb 26, 2020 at 11:54 AM William Hubbs <williamh@gentoo.org> wrote:
> >
> > > Outside of ComRel the problem I've personally had is that reports have
> > > been ignored. In fact, one report lead to agreement that a ComRel
> > > action should take place and then... nothing. Once ComRel responded
> > > again the lead at the time said too much time had passed (~a month) to
> > > punish the person now. Extremely frustrating for reporters. I don't
> > > think I'm the only one with this sort of experience. (I suggest that
> > > we require bugs to be filed -- not emailed to comrel@ -- so they're
> > > more easily tracked).
> >
> > Agreed, this is very demoralizing. Besides your suggestion of requiring
> > bugs to be filed, I would consider a hard timeout of 7-14 days when a
> > bug is filed. Once that timeout passes with no action from comrel, the
> > bug goes to the council.
> 
> I think that this depends a bit on your definition of "no action."  Do
> you mean no final decision?  Or simply no activity?  The former is
> easy to measure, the latter is going to potentially a lot of heartbeat
> activities that just kick the can.

Rich,

with all respect, did you even read Matt's comment above? We are
discussing bugs that get ignored.

*snip*

> > I'm sure comrel is a thankless job, but if it isn't done and the hard decisions are not made, the community suffers.
> 
> IMO it isn't helpful for comrel to operate without ANY positive
> feedback.  I think the current design makes it hard for people to
> offer any kind of meaningful feedback.  However, if a job is important
> to the community, then people should not feel that it is thankless.
 
 It is thankless in the sense that they are the ones who have to make
 the hard decisions about keeping the community healthy and more than
 likely someone somewhere will be angry with them.

> It isn't just about making people feel good either.  Without any
> positive feedback all you have is the negative, and it really does
> become difficult to tell if you're having a positive impact.
> 
> Proctors basically hasn't done anything in the last 6 months or so and
> I think part of it is that the few actions that have been taken have
> almost exclusively received negative feedback.  I can't remember the
> last time that somebody thanked me for taking some action (and unlike
> Comrel the actions of proctors are much more visible).  How is that to
> be interpreted as anything other than a community consensus that the
> actions were inappropriate?  And if so, why would we want to keep
> doing it?  Perhaps ignoring all requests for intervention is an
> improvement.  Certainly I've seen far fewer complaints about inaction
> than past actions.  No doubt this isn't helping with the Comrel
> workload.
 
 Do you seriously believe that ignoring all requests for intervention is
 an improvement or is this trolling?

 Thanks,

 William


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

Re: [gentoo-project] rfc: comrel changes

[Rich Freeman]

On Wed, Feb 26, 2020 at 1:14 PM William Hubbs <williamh@gentoo.org> wrote:
>
> On Wed, Feb 26, 2020 at 12:18:54PM -0500, Rich Freeman wrote:
> >
> > I think that this depends a bit on your definition of "no action."  Do
> > you mean no final decision?  Or simply no activity?  The former is
> > easy to measure, the latter is going to potentially a lot of heartbeat
> > activities that just kick the can.
>
> with all respect, did you even read Matt's comment above? We are
> discussing bugs that get ignored.

I've completely read every email in this thread.  I'm well-aware of
your frustration.

My point is that measuring "no action" is a lot harder than just
having a casual conversation about it.  If you want to trigger some
kind of escalation you actually need to define the trigger.

Also, you need to consider that the presence of a trigger could
influence what happens.

Right now maybe a bug gets filed with no comments for 4 weeks.  You
set up a rule that a bug with no comments after 2 weeks gets
escalated.  Suddenly every bug has a comment every week, but no real
progress.  What you measure is what you get.

I'm not trying to be obstructive.  I'm just pointing out that simple
policies end up not being so simple when they involve stuff that is
this warm and fuzzy.

That is why I suggested that final decisions are more measurable.
Resolved bugs are easier to measure than "active" bugs.

But, you could at least require periodic comments on bugs.

>  Do you seriously believe that ignoring all requests for intervention is
>  an improvement or is this trolling?

It isn't intended as trolling at all.  I'm just pointing out what
might be perceived as a problem, or not.

Those who object to Proctors taking action at all probably consider it
an improvement.  Those who feel otherwise have yet to actually say
anything about the current state.  It is really hard to tell what the
general sentiment is.  When Proctors so much as issues a warning we
usually end up with 30 post arguments on the lists.  I've yet to see a
single post complaining about all the bugs that have been dormant, or
emails sent to the alias that didn't lead to bugs.

I'll also comment that in some of these cases the tone of the threads
that triggered the bugs tended to improve after the bugs were filed,
which probably also lead to increased hesitation to intervene.

I guess my overall point is that I do think these are serious issues.
I just don't see what the answer is.  I'm always happy to chat about
them.  If you're not sure if I'm trolling, perhaps consider just
asking me instead of posting accusations on the lists.

And, honestly, this reaction is part of why nobody probably likes
bringing these issues up.  They're just unpleasant to talk about, and
there is a lot of difference in opinion.  Who wants to deal with that?

-- 
Rich

Re: [gentoo-project] rfc: comrel changes

[Andreas K. Huettel]

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

Am Mittwoch, 26. Februar 2020, 18:18:54 CET schrieb Rich Freeman:

> Proctors basically hasn't done anything in the last 6 months or so and
> I think part of it is that the few actions that have been taken have
> almost exclusively received negative feedback.  I can't remember the
> last time that somebody thanked me for taking some action (and unlike
> Comrel the actions of proctors are much more visible).  How is that to
> be interpreted as anything other than a community consensus that the
> actions were inappropriate?  And if so, why would we want to keep
> doing it?  Perhaps ignoring all requests for intervention is an
> improvement.  Certainly I've seen far fewer complaints about inaction
> than past actions.  No doubt this isn't helping with the Comrel
> workload.

This. Whenever comrel actually does something feedback is at least 90% 
negative, and everyone else thinks he knows better what should have been done.
The result is a dozen mailing list threads, weeks if not months long infighting 
and people not talking to each other.

I haven't read most of the thread (and only bother with the latest mails 
because Mikle asked me to) since I have enough of the same arguments being 
brought up for years and years. It's just wasting time. Time that could be 
used more productively, both inside comrel and for normal work contributing to 
Gentoo.

-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer 
(council, qa, toolchain, base-system, perl, libreoffice)

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

Re: [gentoo-project] rfc: comrel changes

[Mikle Kolyada]

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


On 26.02.2020 19:54, William Hubbs wrote:
> Agreed, this is very demoralizing. Besides your suggestion of requiring
> bugs to be filed, I would consider a hard timeout of 7-14 days when a
> bug is filed. Once that timeout passes with no action from comrel, the
> bug goes to the council. If this happens too many times (we could
> discuss/agree on a number) it brings the affectiveness of comrel into
> question and the council can take action such as replacing the lead.
>
> Thoughts?
>
> William
>

Simply inefficient measure,  ComRel lags are generally caused by the
fact that we have different people with different opinions, not just
because someone ignores something on purpose. The only way is only to
extend the timeouts.



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

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Wed, 2020-02-26 at 10:54 -0600, William Hubbs wrote:
> Agreed, this is very demoralizing. Besides your suggestion of requiring
> bugs to be filed, I would consider a hard timeout of 7-14 days when a
> bug is filed. Once that timeout passes with no action from comrel, the
> bug goes to the council. If this happens too many times (we could
> discuss/agree on a number) it brings the affectiveness of comrel into
> question and the council can take action such as replacing the lead.

This is not that simple.  While I'm not on ComRel, I can imagine
the problems they need to face.

Let's say someone files ComRel request with some data.  Before ComRel
can take any action, it probably needs to gather more data, to verify
what it has, to talk to other side.  Now imagine that the other side
might be away, have little time, or simply be stalling.  Not to mention
discussion and voting lag after collecting all this.

I don't think it's feasible for all this to happen within 14 days,
even 30 days may be too short in some cases.  If you force hard timeouts
down ComRel's throat, you're going to either cause ComRel to issue
premature decisions or cause issues to repeatedly move to the Council.

To give a real example, it took me almost a month to communicate with
a certain developer before opening a ComRel case against him.  After two
weeks, he requested more time to reply.  So far the bug is open for over
a month waiting for the reply from the other side.  Do you believe
ComRel should be forced to make a decision earlier and say 'sorry, we
can't wait for you'?

-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[William Hubbs]

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

On Wed, Feb 26, 2020 at 07:57:33PM +0100, Michał Górny wrote:
> On Wed, 2020-02-26 at 10:54 -0600, William Hubbs wrote:
> > Agreed, this is very demoralizing. Besides your suggestion of requiring
> > bugs to be filed, I would consider a hard timeout of 7-14 days when a
> > bug is filed. Once that timeout passes with no action from comrel, the
> > bug goes to the council. If this happens too many times (we could
> > discuss/agree on a number) it brings the affectiveness of comrel into
> > question and the council can take action such as replacing the lead.
> 
> This is not that simple.  While I'm not on ComRel, I can imagine
> the problems they need to face.

*snip*

As I've said earlier in the thread, I'm not talking about bugs that are
in process. I'm talking about bugs where nothing has started to happen.

William


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

Re: [gentoo-project] rfc: comrel changes

[William Hubbs]

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

On Wed, Feb 26, 2020 at 02:13:17PM -0600, William Hubbs wrote:
> As I've said earlier in the thread, I'm not talking about bugs that are
> in process. I'm talking about bugs where nothing has started to happen.

So, if we don't want hard timeouts, is there another option?

My concern is when a reporter opens a bug then the bug sits there for an
extended period of time with no one addressing it.
I would argue that after a certain time window passes the reporter starts to
think that comrel doesn't care about the issue,
and the reportee would not like it either if action was taken
against them for something they did 6 months ago. Imo comrel
reports/complaints/whatever you want to call them are time sensitive.

William


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

Re: [gentoo-project] rfc: comrel changes

[Michał Górny]

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

On Wed, 2020-02-26 at 14:22 -0600, William Hubbs wrote:
> On Wed, Feb 26, 2020 at 02:13:17PM -0600, William Hubbs wrote:
> > As I've said earlier in the thread, I'm not talking about bugs that are
> > in process. I'm talking about bugs where nothing has started to happen.
> 
> So, if we don't want hard timeouts, is there another option?
> 
> My concern is when a reporter opens a bug then the bug sits there for an
> extended period of time with no one addressing it.

I agree there.  Paradoxically, ComRel seems to have communication
problems.  All it really takes is making sure the user gets *some*
response in time, be it 'we are looking into this, this will take some
time, we will notice you as things progress'.


-- 
Best regards,
Michał Górny


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

Re: [gentoo-project] rfc: comrel changes

[Raymond Jennings]

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

Personally I concur that Comrel cases take too long.  I've contacted them
before and had a case go stale before I heard anything back about it.

I believe it is indeed correct to call them "time sensitive" and idly I'm
curious if there could be more division of labor.  From what I understand
current procedure is to require a group decision, and adding more members
to comrel would ironically slow the process because it adds more to what
must be done to evaluate consensus.  In sort, comrel doesn't seem to be
very "multi-threaded".

Would it benefit comrel to allow cases to be handled immediately and
unilaterally by any individual comrel member, subject to later review by
the group as a whole if it is found warranted?  Or are such cases best left
to proctors?

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