Re: Status of the 12 High Priority Topics considered for Process2014.

On 9/11/2014 12:49 PM, Stephen Zilles wrote:
>
> ABers,
>
> I have an AB Action Item [1] to review the 12 (of 27 possible [2]) 
> topics that were prioritized by a survey of the AC, Chairs and Team 
> for action during the development of Process 2014. The purpose of the 
> review is to determine which of these topics need further 
> consideration and should be raised as issues in Tracker of the Process 
> Community Group.
>

Thanks for this thorough review. One small comment in-line.

> Topics
>
> 1.1 . "Integrating implementations into the Process."
> >From an efficiency and testing point-of-view, it is good to obtain 
> implementation early in the process and well before the call for 
> implementations (Candidate Recommendation). Often implementation of a 
> feature exposes further issues which might be beneficially resolved. 
> An early implementation might clear these up before the initial Last 
> Call and so reduce the potential for multiple loops from Candidate 
> Recommendation and back to last Call. Some have proposed that a 
> document might be introduced into Last Call in an incremental manner 
> with just those portions that have been changed subject to review and 
> exclusion.
>
> Status: The Introduction to Chapter 7 says that the Tech Report 
> development process is design to, "facilitate royalty-free, 
> interoperable implementations of Web Standards".  Section 7.2.2 which 
> describes what requests for advancing a specification to a new 
> maturity level, says a WG, "SHOULD provide information about 
> implementations known to the Working Group." This is a (weak) 
> encouragement to WGs to begin to develop implementation experience (a 
> term which is described in Section 7.2.4). Section 7.4 Candidate 
> Recommendation requires that the WG, "MUST document how adequate 
> implementation experience will be demonstrated." (This is the earliest 
> of the current set of maturity levels at which a reasonable 
> requirement on implementations (and here, only a plan for them).) 
> Summary, this topic was dealt with in Process 2014. No new issues will 
> be raised.
>
> 2."Process document does not match modern development methodologies & 
> tools."
> The Process Document was written with stable (a.k.a "dead") documents 
> in mind. Modern development approaches are much more incremental in 
> nature. Using a "living" document has been proposed as have modular 
> and incremental standards development.  Might a document exist at 
> several levels of maturity in some combined manner -- perhaps sections 
> described as "Recommendation", sections marked "For test 
> implementation", others perhaps marked "Experimental"? Might multiple 
> versions of the document exist each one at a decreasing certainty of 
> stability?
>
> Status: This is clearly a topic will continue to be of interest as 
> development methodologies and tools continue to evolve. There is not, 
> however, any particular issue to raise in the broad sense.
>
> 3."Can we improve input from 'horizontal' groups (WAI, I18N, ...)"
> Horizontal groups have the difficult task of helping with the 
> development of all the specifications being developed within the W3C. 
> These groups have expertise that is (often, unfortunately) not well 
> represented in the WG developing a particular specification. How can 
> the concerns of the 'horizontal' groups best be input into the 
> process? Review at Last Call can be too late.
>
> Status: This was not resolved by Process 2014. An Issue will be raised.
>

This was actually addressed prior to Process2014 when W3C put into its 
guidebook that the Team is obligated to look at horizontal review even 
prior to releasing a Charter.

Even though it was addressed, it does not mean that we have fixed 
everything.  So I don't object to your raising an issue.

> 4."Desire for stable reference."
> Some communities desire a reference that is stable and controlled from 
> release-to-release. These might include, for example, end users and 
> international standards bodies. It may be acceptable for some to say 
> that they have implemented all of the HTML5 spec as of a certain date, 
> but others might be interested in a document that actually corresponds 
> to that implementation level and is useful to ensure interoperability 
> with other implementations. Others describe a form of document that is 
> described as a "living" specification. Stable progressed and final 
> specifications, by contrast, are supposed to be "dead" and stable.
>
> Status: The current Process does have maturity levels and 
> Recommendations which are stable. See the next topic for the handling 
> of Editor's Drafts. No issue will be raised.
>
> 5."Official drafts are disconnected from some audience needs."
> The rules for placing a draft (Working or higher) on the Technical 
> Reports (TR) page (http://www.w3.org/TR/) require a resolution to do 
> so by the Working Group. Many WGs now do all of their technical work 
> in a public space so their work is always visible. With both public 
> drafts and the TR Page, some users of the documents become confused as 
> to where to look. In addition, because the work is public, sometimes 
> WGs fail to update the TR Page with a current draft. Should the TR 
> page point to public drafts (as well as WG sanctioned ones)? Should 
> the tools make publication on the TR Page very convenient? Should 
> there be some sort of "time-line" display of documents that might be 
> browsable by all parties -- that incorporates all versions of a 
> document, clearly marked as to status?
>
> Status: The main point here is whether people are finding the most 
> relevant document for a given specification. Historically, both 
> navigation (via the TR page) and searching sent people to the most 
> current public Working Draft. This is, currently, often out of date 
> and infrequently updated. That has meant the implementations and uses 
> have been generated from incorrect information. The desire is that the 
> documents people retrieve be more up-to-date.
>
> The Team is taking steps to resolve this problem. The Team has 
> implemented dual pointers on the TR pages (one to the current stable 
> draft and the other to an in-progress draft (called a Nightly Draft)) 
> for each document where both references are known (to the Team). [See 
> http://www.w3.org/TR/#tr_CSS Drafts, for example.] Secondly, the Team 
> has proposed an improvement in the publications process
> http://www.w3.org/2014/08/pubworkflow.html
>
> that will allow updates of the "stable" document to occur more 
> frequently.
>
> These steps do not entirely solve the problem from some people's 
> viewpoint. Since the process says that the Working Group must record 
> the group's decision to request publication, this can be interpreted 
> as requiring a Working Group action prior to each update to the TR 
> page or it can be interpreted as allowing the Working Group to 
> authorize the Editor to (responsibly) update the TR page whenever he 
> or she has a coherent draft. There is already an issue:
>
> http://www.w3.org/community/w3process/track/issues/126 
> <http://www.w3.org/community/w3process/track/issues/126>
>
> that points out that depending on how the Working Group action is 
> handled, the control of the what is "published" could shift from the 
> Working Group to the Editor.
>
> One approach to mitigating this concern is to allow two kinds of 
> Working Drafts (called, for example, Provisional Working Drafts and 
> Working Drafts) where the first kind could be posted by the Editor 
> without prior review by the Working Group and the later would require 
> a Working Group action. The status section and formatting of the two 
> kinds would be different so avoid confusion. Some of the requirements, 
> such as having a list of changes would apply only to the second kind 
> of Working Draft.
>
> 6."The social contract with contributors to specifications."
> Within the Open Source community, there is a social contract that 
> anyone can take their work elsewhere; for example as a fork of the 
> source files. Some believe that the same should hold for contributions 
> to specifications; that is, one should be able to 'fork' the 
> specification and take that fork in another direction if they are 
> unsatisfied with the specification they are forking. In particular, if 
> they believe that the specification is becoming "stale" due to lack of 
> attention by the owning organization. Opponents to 'forking' argue it 
> is important to prevent the creation of competing versions of the same 
> specification.
>
> Status: This seems to be a continuing discussion even without having a 
> Tracked Issue. No new issue will be created.
>
> 7."Last Call (LC) may not be as useful as intended."
> It seems there are two purposes for Last Call. One is to trigger 
> patent exclusion calls; another is to produce a review document for 
> external entities. These purposes are unrelated.
>
> Status: Last Call was removed in Process 2014. No new issue will be 
> raised.
>
> 8."Going to Last Call (LC) is misleading for Candidate Recommendation 
> (CR) changes."
> People generally feel this is an arbitrary mandate in the process. The 
> way the process document reads, it seems to some like an arbitrary 
> penalty for making changes at the CR level.
>
> Status: Last Call was removed in Process 2014. No new issue will be 
> raised.
>
> 9."Lack of test cases is a major contributor to schedule delay."
> If tests are not created until the Candidate Recommendation (CR) 
> timeframe, then it is likely delay will occur, since the 
> process-defined review period is relatively short. Since test cases 
> are one factor of testing that is necessary for a spec to progress 
> from Candidate Recommendation to Proposed Recommendation, they are a 
> key process item determining speed to Recommendation. Test case 
> production is often under-resourced.
>
> Status: As noted above, additional emphasis on having a plan to 
> demonstrate the implementablity and inter-operablity of features has 
> been added to Process 2014. However, this does little to help with 
> getting tests written when that plan calls for testing. An issue will 
> be raised for this topic.
>
> 10."Find ways to allow experimentation."
> A number of participants have indicated, by their actions, that there 
> needs to be a way to experiment with increased functionality, to allow 
> innovation. Some have proposed that allowing specifications to be 
> "forked" is the way to  do this. Others have used vendor prefixed 
> keywords to introduce new functionality. There are problems with both 
> of these solutions, problems such as achieving interoperability when 
> unprefixed keywords are used before a specification is stable versus 
> the pain of having multiple prefixes extent when stability seems to be 
> achieved. What is a good way to allow innovation and experimentation 
> as well as interoperability?
>
> Status: Prefixing is still in use. Some vendors use unprefixed version 
> but limit their use to users that turn on a given feature switch an 
> author cannot really distribute content using the new (unprefixed) 
> features. This topic remains a problem area, but no new issue will be 
> raised.
>
> 11."Value of the Advisory Board (AB) & Technical Advisory Group (TAG)."
> have they outlived their usefulness?
> * Is the TAG providing expertise desired from the point-of-view of the 
> specification development communities?
> * Does the AB adequately represent the diverse interests of the 
> membership, and should we change something?
>
> * Are some constituents 'more equal' than others?
>
> Status: For the TAG, there is an AB issue
>
> https://www.w3.org/Member/Board/track/issues/10 
> <https://www.w3.org/Member/Board/track/issues/10>
>
> on What should the TAG do? For the AB, there is no issue in either the 
> AB or the Process CG trackers, but there is an active Task in the AB 
> workplan,
>
> https://www.w3.org/wiki/AB/2014-2015_Priorities#AB_role_and_function
>
> item number 2, that does address "representation" of the AC.
>
> To date, there is no specific issue for the Process CG so none will be 
> created.
>
> 12."Spec maintenance (including IPR commitments)."
>
> ·When a version of a spec is maintained, do we have adequate 
> commitments in place to ensure all of the prior licensing commitments 
> from the previous edition are maintained?
>
> Status: this was resolved in the Patent Policy FAQ:
> http://www.w3.org/2003/12/22-pp-faq.html#edlicensing
>
> ·Are exclusion calls in a maintained document limited to the changed 
> material?
> Status: Yes
>
> http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-with
>
> ·Are exclusion calls for a maintained document necessary?
> Status: Yes, but only if material new subject matter is added to the 
> document
> http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-exclusion-with
>
> ·
>
> ·What degree of change is appropriate for a maintained document (such 
> as the potential addition of new features)
> Status: New features may not be added without requiring new Patent 
> Commitments per the Patent Policy FAQ:
> http://www.w3.org/2003/12/22-pp-faq.html#edlicensing
>
> ·Substantive change is not supposed to be part of specification 
> maintenance however if the change is not substantive there is little 
> motivation.
> Status: Substantive changes are allow as long as they do not introduce 
> new features per the Patent Policy FAQ:
> http://www.w3.org/2003/12/22-pp-faq.html#edlicensing
>
>           No new items will be raised for the topic.
>
> Steve Zilles
>