- From: Jeff Jaffe <jeff@w3.org>
- Date: Tue, 16 Dec 2014 08:22:42 -0500
- 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