Re: [tr] Proposed New Outline

On Tue, 26 Nov 2013 18:47:37 +0700, Arthur Barstow <art.barstow@nokia.com>
wrote:

> On 11/25/13 11:45 PM, ext fantasai wrote:
>> Current outline:
>>  #  General requirements for Technical Reports
>>  #  7.1 Maturity Levels
>>  #  7.2 General Requirements for Advancement on the Recommendation Track
>>  #      7.2.1 Substantive Change
>>  #      7.2.2 Wide Review
>>  #      7.2.3 Implementation Experience
>>  #  7.3 Reviews and Review Responsibilities
>>  #  7.4 Advancing a Technical Report to Recommendation
>>  #      7.4.1 Working Draft
>>  #          7.4.1.a First Public Working Draft
>>  #          7.4.1.b Revised Public Working Drafts
>>  #      7.4.2 Last Call Candidate Recommendation
>>  #      7.4.3 Publication of a W3C Recommendation
>>  #          7.4.3.a Publishing a Last Call Candidate Recommendation
>>  #                  as a W3C Recommendation
>>  #          7.4.3.b Publishing an Edited Recommendation
>>  #          7.4.3.c For all W3C Recommendations
>>  #  7.5 Publishing a Working Group or Interest Group Note
>>  #  7.6 Modifying a W3C Recommendation
>>  #      7.6.1 Errata Management
>>  #      7.6.2 Classes of Changes to a Recommendation
>>  #  7.7 Rescinding a W3C Recommendation
>>  #  Good practices
>>
>> Proposed Outline:
>>  | General Publication Requirements
>>  | Technical Report Types
>>  |   Notes vs. Recommendations
>>  |   Maturity Levels
>>  | Review Responsibilities
>>  |   Wide Review
>>  |   Implementation Experience
>>  |   Classes of Changes / Substantive Changes [merge]

I agree with cleaning up the stuff on changes. I already had one go at it
- although you can't read all the discussions since many of them happened
when this was still being done "in the dark" you can see what I did in
earlier editor's drafts.

But these three sections are really definitions of key terms. The stuff
about review responsibilities could do with a deep editorial sweep.

And yes, the reordering of these bits makes sense. I have so far generally
tried to be conservative about changing the order, except where it came
   from combining two sections that were separate.

>>  | General Transition Requirements
>>  | Recommendation Track
>>  |   Working Draft
>>  |     First Public Working Draft
>>  |     Revising Working Drafts
>>  |   Candidate Recommendation
>>  |     Transitioning to Candidate Recommendation
>>  |     Revising Candidate Recommendations
>>  |   Recommendation
>>  |     Transitioning to Recommendation
>>  |     Revising Recommendations
>>  | Note Track
>>  |   Working Draft [refer to section above for steps; here for  
>> parallelism]
>>  |   Group Note

If you describe the difference between Recommendations and Notes above
(which I think is reasonable) I don't think you need to make a whole "Note
Track" section. Stuff can (and in some cases should) be moved to Notes at
any time, or it can be planned as a note from the beginning - e.g. IG
Notes because IGs are not chartered to produce Recs.

So I think the key stuff is what is needed to make a Note, when something
should be one instead of a Rec, and when something can go from Note back
into the Rec Track.

>>  | Ending Work on a Technical Report
>>  |   Abandoning a Technical Report
>>  |   Rescinding a Recommendation
>>  | Further Reading
>>
>> What am I doing here?
>>   * shor section titles; some of them are awkwardly long
>>   * Defining Note vs. Recommendation up front before we start talking
>>     about how to get there, so you know what you're trying to get *to*
>>     while you're reading how to get there.
>>   * Putting together all review requirements. Note that implementation
>>     experience is a type of review, as far as we're concerned here.
>>   * Combining Classes of Changes to a Recommendation with Substantive
>>     Changes, because they're both trying to describe the same thing,
>>     except the former has a finer breakdown.

Agree with all the above.

>>   * Creating parallel tracks for Note and Rec in the document structure

As explained, I'm not sure that's a goal, since the tracks are in practice
interwoven.

>>   * Making keeping a Recommendation up-to-date a core part of the  
>>     process, which it should be. Similarly added a section on revising
>>     a CR to parallel revising WDs and RECs.

Yep, makes sense.

>> Comments on the proposal or its intentions welcome.
>
> I support this change and consider it a blocker.

Do you mean you wouldn't support any attempt to adopt current proposal
without this change, or without some change along these lines?

> To help with the tracking, I created the following issue:
>
>    <https://www.w3.org/community/w3process/track/issues/59>

Thanks.

>> If people think
>> this is a worthwhile endeavor, I will start to put together exact
>> changes. I think this gives a better structure to support other
>> editorial improvements to the document.
>
> Given you willingness to help, I nominate you to the Editor team, not  
> only because you are willing to help but I think it's important this  
> document be positioned as not just an AB effort.

(The process is the responsibility of the AB. I believe it is
inappropriate for you to tell the AB how to organise its work. On the
other hand, I'd welcome Elika, or anyone else who does real work, as a
co-editor.)

> I also think this doc should be moved to GitHub to encourage and  
> facilitate the evolution of these processes by people beyond the  
> Consortium. I created the following issue to track this:
>
>    <https://www.w3.org/community/w3process/track/issues/60>

As noted in reply to that issue, I think that's actually a bad idea.

> -Thanks, AB
>
>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals@yandex-team.ru         Find more at http://yandex.com

Received on Sunday, 1 December 2013 07:17:59 UTC