[Tech-board-discuss] better hot-topic discussion processes was: Re: TAB non-nomination

[Jason Cooper]

+Kostantin

Hi Ted,

On Fri, Nov 09, 2018 at 02:03:05PM -0500, Theodore Y. Ts'o wrote:
> So what was done with the update to the CoC was that a proposed set of
> changes was sent out to the top 200 or so contributors to the kernel,
> by git statistics over the past year, asking for their comments and
> their sign-offs.  So there *was* community input, and that input did
> result in changes to the CoC update.
> 
> Could there be a better process?  I think we're all open to input.  If
> someone would like to suggest a better way to handle things, that
> would be great.  I will disclose upfront, though, that I will have to
> politely disagree with the proposition that completely free and open
> discussion is always the magic bullet solution.

Ok, I'll take a stab at that. :)

I'll make the assumption that there was nothing said in the "invited"
discussion that the speaker would object to being a matter of public
record.

So I see two possible avenues to improve the process.  Keeping in mind
that these are rare, and thus the process shouldn't be a burden.

The first is what I'll call a "delayed archive."  Basically, you Cc the
archive in along with the invitees to the discussion.  The archive
server then adds the emails to the public archive 90 days after the
email was sent.  This might also work well for the security ML.

The second is more of a "distributed moderation" model.  A mailinglist
would be added to the Cc where only members can post.  Non-member posts
are dropped.  However, there are also "subscribers"; they can't post,
but they receive posts to the ML.[1]  There is no delay.

So, if I'm just a subscriber, but I know James, and I want to contribute
to the discussion, I send my reply to him, and he can forward it if
relevant.[2]  James can filter any emails coming in against his address
book so he's not bothered with people he doesn't know (Don't we all
already do this? :-) ).  The same goes for all the other members.  The
idea here is avoid the single-point-of-failure of having a single
moderator.  Optionally, the "members" could be automatically assigned
that status based on the git history.

thx,

Jason.

[1] Another way to describe this is an ML for which posting is limited
to subscribers that meet a given threshold within the git history.

[2] programmatically, we could say that James' address is in the To: and
all others in the Cc:.  This would allow for easier spotting of "I'm
being asked to moderate this."