Status of the 12 High Priority Topics considered for Process2014.

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.

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.


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

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