Re: [tr] Proposed New Outline

Having looked a bit closer at how to do this...

On Sun, 01 Dec 2013 05:17:25 +0100, Charles McCathie Nevile  
<chaals@yandex-team.ru> wrote:

>> On 11/25/13 11:45 PM, ext fantasai wrote:
[current outline. Moved to the end...]
>>> Proposed Outline:
>>>  | General Publication Requirements

Actually, I think we can skip that and start with:

>>>  | Technical Report Types
>>>  |   Notes vs. Recommendations
>>>  |   Maturity Levels

Followed by:

General Publication Requirements (status info, pubrules)
General Transition Requirements

>>>  | Review Responsibilities
>>>  |   Wide Review

I would merge these two...

>>>  |   Implementation Experience

>>>  |   Working Draft
>>>  |     First Public Working Draft
>>>  |     Revising Working Drafts
>>>  |   Candidate Recommendation
>>>  |     Transitioning to Candidate Recommendation
>>>  |     Revising Candidate Recommendations

Yes, this is important to put in. I would note that new CRs require  
director approval, but depending on the changes this may or may not be  
gated on a "Director's call" - and that in case of really large changes  
the director may send a spec back to WD

>>>  |   Recommendation
>>>  |     Transitioning to Recommendation
>>>  |     Revising Recommendations
then
>>>  |     Classes of Changes / Substantive Changes [merge]
>
> I agree with cleaning up the stuff on changes.
now raised as issue 72. I suggest actually defining them later, where we  
talk about revising Recs, as I explained in the description of that  
issue.>>>  | Note Track
>>>  |   Working Draft [refer to section above for steps; here for  
>>> parallelism]

I wouldn't say here there is a Note track. In the section on Recs and  
Notes I'd point out that docs may be explicitly note-track, or may be  
published as notes. And Working Drafts are the same so I'd just put the  
stuff specific to publishing Notes.(which isn't much).

>>>  |   Group Note
>>>  | Ending Work on a Technical Report
>>>  |   Abandoning a Technical Report
>>>  |   Rescinding a Recommendation
>>>  | Further Reading

Yep.

>>> If people think this is a worthwhile endeavor, I will start to
>>> put together exact changes.

Yep. Failing which, I will...

>>> I think this gives a better structure to support other
>>> editorial improvements to the document.

Yes. But I'd like to get this change in with a minimum of further content  
changes (some will be necessary to make this work, I think) before we  
embark on more changes, just so people can check that it really made sense.

cheers

Chaals

>>> 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
>>>



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

Received on Friday, 6 December 2013 21:29:15 UTC