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

[Ulrich Mueller]

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

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

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.

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

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.

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

> If decisions need being deferred, there is no longer implicit one
> month delay.  People don't have to find time to attend to meetings in
> case they needed to answer some questions.

The Council already has the option of deferring decisions to a bug, or
having an additional meeting, if it believes that the matter should not
be delayed by another month. IMHO that doesn't imply that deferring to
bugs should become the standard.

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

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

Ulrich