W3C home > Mailing lists > Public > public-w3process@w3.org > December 2014

Re: What is Process Good For?

From: Jeff Jaffe <jeff@w3.org>
Date: Tue, 16 Dec 2014 08:22:42 -0500
Message-ID: <54903222.5040602@w3.org>
To: Sam Ruby <rubys@intertwingly.net>
CC: public-w3process@w3.org

On 12/16/2014 5:47 AM, Sam Ruby wrote:
> Noting that there doesn't seem to be others agreeing with my points, 
> perhaps this thread should be wound down.  At a minimum, I'll respond 
> less frequently.
>
> On 12/15/2014 05:52 PM, Jeff Jaffe wrote:
>> On 12/15/2014 3:51 PM, Sam Ruby wrote:
>>> On 12/15/2014 03:03 PM, Jeff Jaffe wrote:
>>>> On 12/15/2014 2:32 PM, Sam Ruby wrote:
>>>
>>> And while fragmentations is a theoretical possibility, it is one that
>>> rarely occurs.
>>
>> Fragmentation in open source is quite frequent.  Linux has many forks
>> and many incompatibilities.  This might be a feature - a similar code
>> base has different requirements in different systems. But fragmentation
>> happens.
>
> Valid.  But if you use that definition of fragmentation, then 
> fragmentation of standards is also a reality.  To keep this 
> conversation lighthearted, I'll steer away from anything contentious.
>
> Select pretty much anything at this web site: http://caniuse.com/
>
> Different browsers are implementing different features at different 
> rates.  All, however, are heading in the same general direction.
>
> This is what you see with Linux.

This is only my opinion.  The way that Linux has fragmented (different 
file systems, different virtualization technologies, different GUIs) is 
not what we want to see for the Web.  Sure caniuse points to different 
rates of implementation and in some cases real fragmentation on some 
features.  But in the large we need an interoperable Web.

> Neither Linux 3.19 nor ECMAScript 6 are released yet, but both will 
> roll out over the next few years.
>
>>> Can you name a fork of the Apache Web Server?  In fact, it has been my
>>> observation that there has is a greater fragmentation around standards
>>> (*cough* URI *cough* IRI *cough* URL *cough*) than there is around
>>> software.
>>
>> If it is true that standards tend to fragment, some might view that as
>> an important reason to discourage fragmentation.
>
> My concern is that the fragmentation counter-measures that have been 
> selected to date have the effect of DIScouraging cooperation, which 
> will indirectly ENcourage fragmentation.

Here we agree.  I have tried for several years to find ways to encourage 
cooperation.  We have instituted substantial process change.  I accept 
that this has not succeeded.  That is why I laud your efforts to take it 
to the next step.

>
>>> And the ASF has an equally strong position on the need for consensus.
>>>
>>> I'd encourage you to not dismiss this so readily:
>>
>> I don't know what led you to believe that I was dismissive of anything.
>> I noted that software and standards are different.  And I explained why
>> fragmentation in standards is bad.  I don't consider that as being
>> dismissive.
>
> OK.  In that case, I disagree that they are different in ways that 
> affect community, consensus, fragmentation, or other topics that we 
> have discussed.
>
>>> Meanwhile, I will caution you: if you continue to attempt to keep a
>>> tight grip on the standards you have through onerous Invited Expert
>>> terms and conditions and Document Licenses, what I suspect is that you
>>> will increasingly find that standards will be defined -- WITH
>>> CONSENSUS! -- elsewhere.  And the W3C will be reduced to belatedly
>>> giving their stamp of approval.
>>
>>> In fact, an instance of this is exactly what I briefed the AB on
>>> earlier today:
>>>
>>> https://github.com/webspecs/url/blob/develop/docs/workmode.md#preface
>>>
>>> Is that leadership?
>>
>> I'm not sure I understand this question.
>>
>> You have been proposing a workmode for URL and I have been encouraging
>> you all the way in my remarks in this process CG.  Are you suggesting I
>> should not be supporting this proposal?
>
> Consider the fact that it is a different model.  One where all work is 
> being made available under the CC0 license.  One where contributors 
> are defined as people who contribute and not by being named by member 
> companies.  One where contributors become editors by sustained 
> contributions rather than being named by chairs.  One where a growing 
> team of editors make technical decisions rather than chairs or directors.

I am on the record as supporting the notion that rapid progress can be 
made by informed editors making technical decisions [1].  I wouldn't 
argue much against your pov here.

Most of the W3C infrastructure (consensus, transition requests, wide 
review, objections) - especially in Process2014 - is to ensure due 
process to the larger Web community.  Aside from some details that still 
need to be worked out, I think your proposal nicely blends editor 
empowerment with due process.

In terms of the CC0 license, my impression is that the AC is not there 
yet, although clearly some in the W3C community support that notion.  
And personally I'm not convinced that it is a good idea since CC0 
advocates have been explicit that they like the idea that they could 
create derivative specs elsewhere (which would lead to fragmentation).

[1] 
http://www.w3.org/blog/2014/10/decision-by-consensus-or-by-informed-editor-which-is-better/

>
> Ponder whether this is a prototype for a new way of working.
>
> I will say this: I'm personally 33 years into a 30 year career with 
> IBM.  I have no plans on leaving, but at some point IBM may have other 
> ideas.

I know how you feel.  I never thought I would leave IBM, but after 20 
years I did.  You have more longevity than I.

> At which point, I will likely retire instead of looking for another 
> employer.  Even so, I expect I will continue to work on the URL 
> specification, but I will have no interest in signing the current 
> Invited Expert agreement.

So we should work on that requirement.

>
> - Sam Ruby
Received on Tuesday, 16 December 2014 13:22:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:51:25 UTC