Re: [gentoo-project] [RFC] Asynchronous Council

[Michał Górny]

On Fri, 2020-06-26 at 13:59 +0200, Ulrich Mueller wrote:
> > > > > > On Fri, 26 Jun 2020, Michał Górny wrote:
> > This is the idea I'd like to submit for the first meeting of the new
> > Council.  I'd like to hear your feedback first.
> > TL;DR: Council requests should always be discussed publicly
> > on the mailing lists.  Council members should vote on them via bugs when
> > the discussion finishes.  Meeting should focus on loose discussion
> > without decision making.
>
> I hope this isn't another of your belated April 1st jokes. :)

The rule is at most one joke per year, I guess ;-).  No, this is
a serious thought.

>
> > The problem
> > ===========
> > Currently, most of the Council decisions are made during the monthly
> > meetings.  This causes a few problems.
> > Firstly, it is hard to 'fit' the public discussion just for the meeting.
> >  If it doesn't conclude before the meeting, Council is either operating
> > with partial feedback or defers the matter another month.  If it
> > concludes earlier, things get forgotten.
> > Secondly, sometimes new arguments are brought during the Council
> > meeting.  This often means that the Council has either to defer
> > the matter further to give people a chance to update their feedback,
> > or make decisions without giving people not present at the meeting to
> > reply.
> > Thirdly, this means that some people end up being inconvenienced to
> > appear at the meetings to support their cause.  These meetings may
> > easily end up very late for some people, and it doesn't help when they
> > end up being very long because of the ongoing discussion.
>
> Could you substantiate these claims by some examples, preferably from
> a recent Council period?

The usual meeting time collided with my 'family time'.  But I was
thinking more of Japan, somewhat in reference to the bigger problem
Trustees have.  We're running a world-wide project, and we can't expect
to be able to manage to satisfy everyone, so we're effectively
discouraging some part of the community from taking active part in this.

>
> > Proposed solution
> > =================
> > Roughly, the proposal would be that:
> > 1. All public matters are discussed on the appropriate mailing lists.
> > 2. A request to the Council is made via filing a bug.  If the request is
> > suitable for public debate, the discussion is linked in the bug.
> >  Otherwise, appropriate restrictions are set on it and the discussion is
> > carried on the bug.
> > 3. Council members participate in the discussion, possibly acting
> > as moderators as well (i.e. asking people for clarifications,
> > encouraging them to express their opinions, keeping the discussion
> > on topic).
> > 4. If necessary, Council members may also discuss the matters via IRC,
> > possibly during ad-hoc meetings.  However, the result of these
> > discussions must be brought to the mailing lists for feedback.
>
> So, who would be responsible for recording the log and writing a summary
> for these ad-hoc meetings? I see it as a huge advantage of the monthly
> meetings that the schedule is well structured and everything is in the
> log and summary.

I don't think it's important to set this in stone right now.  A few
possibilities: whoever called for it, a person chosen at the beginning
of the meeting, the chair for the month that the meeting takes place
in...

> Plus, regular meetings are currently being announced some time in
> advance, so developers can take notice and participate.
>
> > 5. When the discussion settles (either reaching a conclusion or
> > saturating all the arguments), the Council votes on the bug.
>
> As a matter of fact, that hasn't really worked so well in the past.
> It sometimes took quite a while until all votes were collected.

I believe this would change if this became the primary workflow.

An extra benefit is that it would make sure that Council members
participate more often than one hour a month.

> > 6. Decisions are announced on the -dev-announce mailing lists.
> > If multiple votes are carried simultaneously, multiple decisions can be
> > announced in one mail.
> > What about the meetings?
> > ========================
> > The Council can continue to meet monthly with the two common agenda
> > items: reiteration of open bugs and open floor.  The former can serve
> > as a synchronization mechanism for other requests.  The latter provides
> > the community an opportunity to find all of the Council members
> > available at the same time.
>
> Nope, the Council *must* continue to have at least one monthly meeting,
> because GLEP 39 mandates it:
> - The council must hold an open meeting at least once per month.
> - Council decisions are by majority vote of those who show up (or their
>   proxies).

While I do know the complications of changing GLEP 39, if we want to
change workflow we should obviously account for the possibility of
changing it.

>
> IMHO it would also be against the spirit of GLEP 39 if most Council
> decisions were to take place outside of monthly meetings.
>
> > How does that improve things?
> > =============================
> > Most importantly, all the discussion is carried off in public.
>
> Council meetings are public already, so no difference there.

I'm sorry, 'public' does not carry my meaning correctly.  My point is,
mailing list discussion provides a better opportunity for people
(possibly having little time, restricted schedule, mismatched timezone,
needing to do more research) to participate than a meeting that requires
participation at a particular time and reasonably fast answers.

> > The privileged position of people attending Council meetings is removed.
> >  Decisions aren't made in the middle of public discussion, or long after
> > it settled.  Council members bring their arguments to the debate
> > earlier.
> > Since the Council is no longer bound by the monthly cycle, decisions can
> > be made faster if there is overall agreement.
>
> If there's overall agreement (e.g., consensus in gentoo-dev), you
> normally don't even need a decision by the Council.

GLEPs are one thing I was thinking of.  Even if the GLEP is clear-cut
and nobody raises any concerns, we have to wait for the meeting or call
for non-standard bug vote.

> > The meetings become shorter, on one hand saving Council members' time,
> > on the other making it possible for developers to participate in open
> > floor without waiting for all agenda items to be processed.
>
> That would be easy to solve by putting open floor first on the agenda.
>

I don't think that would be desirable when we expect to have on-topic
discussion on the agenda.

> > WDYT?
>
> Overall, this sounds like replacing a well structured workflow by
> something that would be more irregular and intransparent. Especially,
> discussions would be scattered over several bugs and mailing list
> postings, instead of having them in one place.
>

They already are.  Actually, they would less scattered as the IRC would
no longer be present in primary discussion flow (in favor
of the original ml discussion).

-- 
Best regards,
Michał Górny