- From: Wayne Carr <wayne.carr@linux.intel.com>
- Date: Tue, 25 Nov 2014 17:05:42 -0800
- To: Sam Ruby <rubys@intertwingly.net>, public-w3process@w3.org
On 2014-11-25 13:47, Sam Ruby wrote: > > > On 11/25/2014 02:07 PM, Domenic Denicola wrote: >>> I disagree (see below) >> >> I don't understand what you disagree with, even after reading the >> below. You quote your blog post: >> >>>> In particular, they are interested in evidence of wide review, >>>> evidence that issues have been addressed, evidence that there are >>>> implementations, and the IPR commitments that are captured along >>>> the way. >> >> In what ways is achieving these incompatible with the principle I >> stated, or with the examples I gave of how to satisfy it? Most of my >> concerns were about the snapshot document itself, whereas the things >> you mention are about process, issue tracking, testing, >> implementation reports, IPR submission forms... They seem unrelated. > > In my experience process and results are intertwingled. If you > forgive me, I'll give a lengthy answer which describes a process that > would work as you describe, why it is not often followed, and a > process that more closely match how specs are currently written, and > what the implications are for snapshots. > > But before I do, my basic point is that cowboy spec development (a.k.a > Commit-Then-Review) and discouraging stable snapshots is > counter-productive. > > For the longer answer, I'll start by introducing two terms from the > Apache Glossary[1]: Review-Then-Commit (RTC) and Commit-Then-Review > (CTR). > > In projects employing RTC, *NOTHING* goes into the product (in this > case a spec) until it has been throughly reviewed. As applied here, > that would mean that *NOTHING* would go into a spec until there was > evidence of wide review, evidence that issues have been addressed, > evidence that there are implementations, and evidence of the necessary > IPR commitments. > > Furthermore, in such projects, if an issue is identified, the > problematic part of the work is promptly backed out, and not > reintroduced until the issue is resolved. > > In such an environment, it is a true statement that static snapshots > are of little value as the latest version is always better. > > I will also state that projects that follow RTC are rare. That's > because such a process intentionally slows things down. Generally, > only mature, stable, and widely deployed projects follow this > process. In W3C terms, think "errata". > > Much, *much*, MUCH more common is CTR. What this means is that a > specification at any time may have a delightful mix of stable and > proven bits as well as flights of fancy, items that are unproven and > unstable, or were outright rejected by implementers. This is the part > that you left out. > > This is not a bad thing. In fact, it generally is necessary in order > to make rapid progress. But it does mean that depending on what you > are looking for, the latest and "greatest" isn't always better than > the trustworthy and proven version that was published last month or > even last year. > > In fact, there are known ways to compensate for this. Such ways > generally involve the creation of a stabilizing branch and removing > features that aren't quite ready for prime time in that branch. Such > efforts are short duration, and produce a reference-able snapshot. Instead of a stabilizing branch where separate work is done to get to it, couldn't non-stable, non-widely implemented sections be marked as one of the categories you mention above in the main document? so a snapshot is automatic - it just removes the sections that aren't mature. (so no separate "stabilizing" work - it's part of the main spec - or at most pointing out where the labels aren't set correctly. So new experimental stuff is clearly marked as new experimental stuff.) > > Note that such a snapshot is not merely for IPR purposes. It exists > to give spec writers the freedom and flexibility to explore new > areas. And consumers of the spec confidence in what they are reading. > > I'll also note that it is the nature of web standards that once a > standard is widely implemented -- or more importantly, there exist a > significant corpus of content deployed that depends on that standard > -- that "mulligans" or "do-over" opportunities are exceedingly rare. > > What this means in practice is that suitably prepared Recommendations > are rarely "stale"; and as long as errata is promptly prepared, they > remain proven and valuable. Newer versions, as they become available, > simply contain more features. > > - - - > > Now lets apply this to URL. The concept of a URL is clearly a > foundational concept of the web. It also is messy, there also are > many parts over which there isn't agreement (hello "file:"!). It is > by no means "done". That being said, I believe there would be value > in stabilizing the parts that can be stabilized in 2015 and putting > out a W3C Recommendation containing only those parts. I hope I can > get the WebApps Working Group to agree on this. > > In practice, doing so requires more work, and I believe I've > demonstrated that I'm fully prepared to do that work. > > And if people find value in that work (and trust me, there are many > that do), I want to make that work as useful, friendly, and appetizing > as possible. And that means, among other things, stylesheets. > > And furthermore, I don't plan to disappear after this work is done, > nor say "not my job" to the parts that won't be stable in 2015. > > I'm also introducing concepts along the way that I know you personally > agree with: a reference implementation and test-first development. I > believe that such things will ultimately lay the foundation for a > version of the spec under which "RTC" is possible, and new work is > done in separate specifications. > > - Sam Ruby > > [1] http://www.apache.org/foundation/glossary.html > >
Received on Wednesday, 26 November 2014 01:06:11 UTC