Re: After 5 - radical idea: no editors

On 09/16/2014 08:03 AM, Robin Berjon wrote:
>
> # We can change pretty much everything
>
> By this I mean: don't assume that the way things have worked in the
> past is representative of how they have to work in the future. You
> may have been told that some things can't be done that actually can
> be. You may have encountered barriers that can be lifted.

Just capturing some more ideas.  They may end up being dead ends, but as
I've brought them up in other contexts (like telecons) I thought it
would be worth capturing for this discussion.  At the moment, I have two
points to make.  I'll put each separate idea into a separate email with
a separate subject line.

- - -

I'll start by challenging a specific statement in Robin's proposal[1] (a
proposal that overall I will state that I largely agree with)

> To begin making HTML a hackable specification will be to split it up
> into as many pieces as required.

 From a hacking point of view, I don't buy this.  It is clearly possible
for multiple source files to produce a single document.  It is equally
as possible for a single source file to produce multiple documents.

[Note: in my next email, I'll be making the case that limited splitting 
may indeed be worthwhile, but in this email I'm focusing specifically on 
this topic as it relates to editors]

Later in Robin's document are what I consider to be the real issues:

> All of the split specifications will be actively seeking forking and
> pull requests.

and

> The present barriers to developer participation and our systemic
> inability to encourage more editors to join are hurting the
> platform.

I see the former as saying that we need more direct contributors; and
the latter as saying that we need more editors.  The latter also seems
to be acknowledging Conway's law[2] to some extent.

I agree with the former (and will note in passing that despite how it is
currently phrased, the statement doesn't strongly depend on how or even
if the specification is split), so I won't discuss it further here.

As to the latter, I will note that if we are successful in attracting
more direct contributors, the role of an "editor" will be one of pushing
buttons rather than writing prose.  Of course, editors can be
contributors too, but I will submit that if we can move to a model where
the document is contributed to collaboratively by the group then the the
"barrier to entry" to become an editor is radically lowered.

The model will become: anybody can contribute (subject only to W3C IP 
policies), and editors will be responsible for ensuring the document 
tracks consensus and meets WG requirements.  The latter is something 
that could potentially be augmented by implementing some subset of 
pubrules[4] with tools like Travis[3], as well as occasional reverts -- 
something that tools like git and github facilitate.

Taking this to its logical conclusion, and very much in the spirit of
Robin's "We can change pretty much everything", I'd like the WG to
consider a proposal made by Marcos Caceres[5], namely removing the list
of editors from documents produced by the Working Group.

- Sam Ruby

[1] http://darobin.github.io/after5/

[2] http://en.wikipedia.org/wiki/Conway%27s_law

[3] https://travis-ci.org/

[4] http://www.w3.org/2005/07/pubrules

[5] http://lists.w3.org/Archives/Public/spec-prod/2014AprJun/0002.html

Received on Thursday, 25 September 2014 18:29:03 UTC