From 77fede65080a85b9dd425626c181c071e2df8577 Mon Sep 17 00:00:00 2001 From: Ralph Swick Date: Mon, 7 Dec 2015 15:53:42 -0500 Subject: [PATCH 01/47] rename to bp.md --- bp.md | 130 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 130 insertions(+) create mode 100644 bp.md diff --git a/bp.md b/bp.md new file mode 100644 index 0000000..11b1327 --- /dev/null +++ b/bp.md @@ -0,0 +1,130 @@ +# Best Practices for Bringing Work to the W3C Recommendation Track + +## Status + +Last updated on 2015/11/25 + +NO OFFICIAL STATUS! Distributed to the W3C Advisory board for discussion + +## Purpose + +This best practices document aims to alleviate a number of problems: +- Criteria for when to take work to the Rec track are unclear. Is recognition of a problem enough, or should there be a solution on the table? +- Whatever the criteria may be, they are not applied consistently across domains. +- The process for creating working groups is not transparent. This is sometimes necessary + +Historically, the main criterion for creating a working group has been recognition of a *problem* that falls within W3C's area of expertise. +All too often that resulted in working groups developing solutions that may have been intended to "lead the Web to its full potential" +and did not get objections during W3C reviews, but still did not get widespread adoption on the actual Web. Clearly W3C Recommendations should describe technologies that +are, or are likely to soon be, used to power the World Wide Web. It is a best practice to consider the degree of support from those who would need to +implement, deploy, and use a specification before putting it on the Recommendation track. + +This document lists considerations to take into account when evaluating proposals to move specification work +to the W3C Recommendation track. It tries to strike a balance between two classes of criteria: +- "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters +- "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web + +In the past, these considerations have been applied differently in different areas of W3C. Some WGs are firmly grounded in the Empirical criteria +and are reluctant to take up work until it has ["matured through an incubation phase"](http://w3c.github.io/charter-html/group-charter.html#deliverables). +Other WGs focus on Aspirational criteria, chartered to provide non-normative advice or to develop charters for future normative work. This disparity +creates problems such as the nearly year-long discussion of charters for the WAI working groups that partly hinged on different understandings of the +criteria for chartering a WG. + +Also, discussion at the [October 2015 Advisory Committee meeting](https://www.w3.org/2015/10/27-ac-minutes.html#item02) +indicated disparate opinions about whether to insist that all W3C Recommendation Track work start in a Community Group. Points raised against and +exclusively Empircal approach include: +- Incubation isn't a silver bullet to be applied to every situation +- If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate them to take it to a WG for broad review +- If the CG did not work by consensus, the de facto standard might be imposed by a single strong editor or cabal of the top browsers +- There may be gaps in the patent commitment if all spec contributors don't join the WG + +To address the situation, this document collects best practices to guide those who are considering whether a body of work is ready +for the Recommendation track. The target audience include the Team and Director when evaluating proposals to create new Working Groups or rechartering +existing Working Groups to put new work in scope, working group Chairs when determining whether to publish First Public Working Drafts of +specs that are in a group's chartered scope, and by Advisory Committee representatives when voting on charters and Proposed Recommendations. + +##Readiness Criteria + + +Any of the factors described in this document are fodder for Director/Chair/Team consideration. +No single factor is decisive. Different cases will involve different combinations of these factors. In resolving any objections to +a decision about moving work to the Recommendation track, the Director may consider +other factors not listed in this document as well. + +These considerations may be used by the Working Group while evaluating the risk associated with specific design choices during the group’s deliberations. The Director may refer to this document when a transition request is being decided. +This document documents best practices for moving work to the Recommendation track. They are not binding on +Open source browser projects use an [intent to implement](https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit#) process to build the case for shipping +a new feature. The [Web Platform Incubator Community Group](https://www.w3.org/community/wicg/) has adopted +something similar to [determine when a spec under incubation is ready to propose to a Working Group](https://wicg.github.io/admin/intent-to-migrate.html). + + +### Problem statment +Proposers MUST describe what real-world problem this work would address, and why existing solutions are inadequate. +What are websites forced to do without this feature being available in a standardized way? +What fraction of websites are implementing a similar feature in a non-standardized way? +How would users benefit from this feature if standardized? + +### Success criteria +Proposers MUST identify which types of products (browsers, servers, frameworks, applications...) would need to support the spec for it to be +successful, and indicate what degree of critical mass would be needed. Is this spec serving a niche market and can be implemented only +by those who need to use it? Are their critical dependencies, e.g. the spec must be deployed on both the cloud/server and browser/client, +or must be supported both in products for producers and consumers of web content, to be really useful? + +### Risks +Proposers MUST consider whether standrdiing the spec could create more problems than it solves. +What are the potential downsides of having this feature standardized ...could it undermine security, privacy, accessibility, etc. +if broadly deployed? Are there scenarios under which we would regret standardizing this feature? + +### Socialized proposal +A draft spec SHOULD be written down (or at least sketched out) and socialized in a community where website +developer, framework/took developer, and core technology implementers are represented. That discussion MUST NOT +have generated sustained expressions of opposition or unwillingness to implement / make patent commitments +from key stakeholders. + +### Expressions of interest +The draft spec SHOULD elicit statement of support from key stakeholders about the value proposition for the feature +it describes. Is there a critical mass of implementers tentatively interested in shipping this feature +if standardized? Are there prototype / polyfill implementations that are used in experimental websites that site developers +find useful? + +### Evidence +Proposers SHOULD describe what implementation and user experience is there to back up the points above. +What fraction of websites are implementing a similar feature in a non-standardized way? +How many users would potentially benefit from this feature if standardized? +Hard data is preferred, but estimates backed up by detailed explanations are acceptable. + +### Incubation +The draft SHOULD have matured through an incubation phase in WICG or another CG, IG, or have been submitted by a member +organization based on product experience. The language in the +[Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) +describes a best practice: +> The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase. + +## Additional Considerations + +### Clear RF Licensing Commitments +W3C seeks to issue Recommendations that can be implemented on a [Royalty-Free](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requiremenst) basis. +1. Are the technologies in the initial available under terms that are compatible with the [W3C Royalty-Free licensing requirements](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements)? +3. Is the provenance of contributions to the draft reasonable clear? + +### The proposers are not seeking a rubber stamp from W3C +W3C Recommendations signify a broad consensus across the membership of W3C that a spec both serves a real mainstream need +and it is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and +who interact with various levels of trust. Thus the proposers of Recommendation-track work should be prepared to +accommodate feedback to make a spec more internationalizeable, accessible, secure, etc. Likewise it should not promote +the interests of one group of members at the expense of another, e.g. taking sides in a product-driven "standards war." + +##Conclusion + +The criteria above boil down to 3 basic questions: +- Does the work address a real un-met need or missed opportunity for the Web? +- Does the work start from a concrete proposal that has been socialized with key stakeholders but doesn't discriminate against others? +- Does standardizing the proposed spec have clear support from those who would need to implement and use the spec for it to be successful? + +Transition to the Recommendation Track should happen ... + +NO SOONER than the MUST criteria and a reasonable number of the SHOULD criteria above are met. + +NO LATER THAN a point where the spec is still fluid, and not frozen into shipping code used on many websites. + + From 786f4fae562423540e0781cec1cbca1f18705bbe Mon Sep 17 00:00:00 2001 From: Michael Champion Date: Mon, 7 Dec 2015 15:58:48 -0800 Subject: [PATCH 02/47] Update bp.md Responding to AB comments suggesting a tighter Purpose section --- bp.md | 26 +++++--------------------- 1 file changed, 5 insertions(+), 21 deletions(-) diff --git a/bp.md b/bp.md index 11b1327..e495cd4 100644 --- a/bp.md +++ b/bp.md @@ -2,37 +2,21 @@ ## Status -Last updated on 2015/11/25 +Last updated on 2015/12/08 NO OFFICIAL STATUS! Distributed to the W3C Advisory board for discussion ## Purpose -This best practices document aims to alleviate a number of problems: -- Criteria for when to take work to the Rec track are unclear. Is recognition of a problem enough, or should there be a solution on the table? -- Whatever the criteria may be, they are not applied consistently across domains. -- The process for creating working groups is not transparent. This is sometimes necessary - -Historically, the main criterion for creating a working group has been recognition of a *problem* that falls within W3C's area of expertise. -All too often that resulted in working groups developing solutions that may have been intended to "lead the Web to its full potential" -and did not get objections during W3C reviews, but still did not get widespread adoption on the actual Web. Clearly W3C Recommendations should describe technologies that -are, or are likely to soon be, used to power the World Wide Web. It is a best practice to consider the degree of support from those who would need to -implement, deploy, and use a specification before putting it on the Recommendation track. - This document lists considerations to take into account when evaluating proposals to move specification work to the W3C Recommendation track. It tries to strike a balance between two classes of criteria: - "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters - "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web -In the past, these considerations have been applied differently in different areas of W3C. Some WGs are firmly grounded in the Empirical criteria -and are reluctant to take up work until it has ["matured through an incubation phase"](http://w3c.github.io/charter-html/group-charter.html#deliverables). -Other WGs focus on Aspirational criteria, chartered to provide non-normative advice or to develop charters for future normative work. This disparity -creates problems such as the nearly year-long discussion of charters for the WAI working groups that partly hinged on different understandings of the -criteria for chartering a WG. - -Also, discussion at the [October 2015 Advisory Committee meeting](https://www.w3.org/2015/10/27-ac-minutes.html#item02) -indicated disparate opinions about whether to insist that all W3C Recommendation Track work start in a Community Group. Points raised against and -exclusively Empircal approach include: +Discussion at the [October 2015 Advisory Committee meeting](https://www.w3.org/2015/10/27-ac-minutes.html#item02) +indicated disparate opinions about whether to insist that proposed work should meet empirical criteria before being +put on the Recommendation track. Arguments against using W3C Community Groups to incubate proposals until they +met such criteria included: - Incubation isn't a silver bullet to be applied to every situation - If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate them to take it to a WG for broad review - If the CG did not work by consensus, the de facto standard might be imposed by a single strong editor or cabal of the top browsers From 797f957c181772f14b1817b7539e2bf48bcb671a Mon Sep 17 00:00:00 2001 From: Michael Champion Date: Wed, 9 Dec 2015 09:53:07 -0800 Subject: [PATCH 03/47] Updates based on AB feedback --- bp.md | 62 ++++++++++++++++++++++++++++++++++------------------------- 1 file changed, 36 insertions(+), 26 deletions(-) diff --git a/bp.md b/bp.md index e495cd4..bea5b53 100644 --- a/bp.md +++ b/bp.md @@ -1,17 +1,21 @@ -# Best Practices for Bringing Work to the W3C Recommendation Track +# Best Practices for Bringing Work to the W3C Recommendation Track ## Status -Last updated on 2015/12/08 +Last updated on 2015/12/09 NO OFFICIAL STATUS! Distributed to the W3C Advisory board for discussion ## Purpose This document lists considerations to take into account when evaluating proposals to move specification work -to the W3C Recommendation track. It tries to strike a balance between two classes of criteria: -- "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters +to the W3C Recommendation track. The target audience include the Team and Director when evaluating proposals to create new Working Groups or rechartering +existing Working Groups to put new work in scope, working group Chairs when determining whether to publish First Public Working Drafts of +specs that are in a group's chartered scope, and by Advisory Committee representatives when voting on charters and Proposed Recommendations. + +It tries to strike a balance between two classes of criteria: - "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web +- "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters Discussion at the [October 2015 Advisory Committee meeting](https://www.w3.org/2015/10/27-ac-minutes.html#item02) indicated disparate opinions about whether to insist that proposed work should meet empirical criteria before being @@ -22,51 +26,57 @@ met such criteria included: - If the CG did not work by consensus, the de facto standard might be imposed by a single strong editor or cabal of the top browsers - There may be gaps in the patent commitment if all spec contributors don't join the WG -To address the situation, this document collects best practices to guide those who are considering whether a body of work is ready -for the Recommendation track. The target audience include the Team and Director when evaluating proposals to create new Working Groups or rechartering -existing Working Groups to put new work in scope, working group Chairs when determining whether to publish First Public Working Drafts of -specs that are in a group's chartered scope, and by Advisory Committee representatives when voting on charters and Proposed Recommendations. +This document tries to identify *what* criteria promote the success of a Recommendation Track effort rather than prescribing *how* those +criteria are to be met. -##Readiness Criteria +##Readiness Criteria -Any of the factors described in this document are fodder for Director/Chair/Team consideration. -No single factor is decisive. Different cases will involve different combinations of these factors. In resolving any objections to -a decision about moving work to the Recommendation track, the Director may consider +The criteria here are used to evaluate whether a proposal indicates that a particular technical specification development effort is +ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids [RFC 2118]() "MUST" and "SHOULD" terminology, and should not be a taken +as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are +noted as "strongly recommended", and if not met an explanation of why they don't apply in a particular situation would +facilitate the Director's decision. Different cases will involve different combinations of these factors. In determining whether to +approve moving work to the Recommendation track, the Director may consider other factors not listed in this document as well. -These considerations may be used by the Working Group while evaluating the risk associated with specific design choices during the group’s deliberations. The Director may refer to this document when a transition request is being decided. -This document documents best practices for moving work to the Recommendation track. They are not binding on -Open source browser projects use an [intent to implement](https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit#) process to build the case for shipping -a new feature. The [Web Platform Incubator Community Group](https://www.w3.org/community/wicg/) has adopted -something similar to [determine when a spec under incubation is ready to propose to a Working Group](https://wicg.github.io/admin/intent-to-migrate.html). +In general, the "aspirational" criteria have been used by the team and Director for some time, and this document seeks to make them +more explicit and generally applicable. +The "emprical" criteria are inspired largely by the experience of some open source browser projects +that use an [intent to implement](https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit#) process +to build the case for shipping +a new feature. The [Web Platform Incubator Community Group](https://www.w3.org/community/wicg/) has adopted +something similar to [determine when a spec under incubation is ready to propose to a +Working Group](https://wicg.github.io/admin/intent-to-migrate.html). This document refines this approach to apply to Recommendation +Track transition decisions. -### Problem statment -Proposers MUST describe what real-world problem this work would address, and why existing solutions are inadequate. +### Problem statement +*Strongly Recommended*: The proposal identifies the real-world problem this work would address, and why existing solutions are inadequate. What are websites forced to do without this feature being available in a standardized way? What fraction of websites are implementing a similar feature in a non-standardized way? How would users benefit from this feature if standardized? ### Success criteria -Proposers MUST identify which types of products (browsers, servers, frameworks, applications...) would need to support the spec for it to be +*Strongly Recommended*: The proposal enumerates the types of products (browsers, servers, frameworks, applications...) would need to support the spec for it to be successful, and indicate what degree of critical mass would be needed. Is this spec serving a niche market and can be implemented only by those who need to use it? Are their critical dependencies, e.g. the spec must be deployed on both the cloud/server and browser/client, or must be supported both in products for producers and consumers of web content, to be really useful? ### Risks -Proposers MUST consider whether standrdiing the spec could create more problems than it solves. +The proposal considers whether standrdiing the spec could create more problems than it solves. What are the potential downsides of having this feature standardized ...could it undermine security, privacy, accessibility, etc. if broadly deployed? Are there scenarios under which we would regret standardizing this feature? ### Socialized proposal -A draft spec SHOULD be written down (or at least sketched out) and socialized in a community where website -developer, framework/took developer, and core technology implementers are represented. That discussion MUST NOT -have generated sustained expressions of opposition or unwillingness to implement / make patent commitments -from key stakeholders. +*Strongly Recommended*: A draft of the technical specification has been written down and socialized in a community where website +developer, framework/took developer, and core technology implementers are represented. If that discussion has +has generated sustained expressions of opposition or unwillingness to implement / make patent commitments +from key stakeholders, proposers are well advised to make a persuasive case for how the proposed Recommendation Track work +can be successful in the face of this opposition. ### Expressions of interest -The draft spec SHOULD elicit statement of support from key stakeholders about the value proposition for the feature +The proposal points to statementss of support from key stakeholders about the value proposition for the feature it describes. Is there a critical mass of implementers tentatively interested in shipping this feature if standardized? Are there prototype / polyfill implementations that are used in experimental websites that site developers find useful? From 43da443ff7c9db73d713dfd7444b7f88f23409fe Mon Sep 17 00:00:00 2001 From: michaelchampion Date: Sat, 12 Dec 2015 11:25:22 -0800 Subject: [PATCH 04/47] Updates ready for AB review Reviewed the AB threads on this topic and incorporated most suggestions. --- bp.md | 55 +++++++++++++++++++++++++++++++++++++------------------ 1 file changed, 37 insertions(+), 18 deletions(-) diff --git a/bp.md b/bp.md index bea5b53..023e210 100644 --- a/bp.md +++ b/bp.md @@ -1,15 +1,17 @@ -# Best Practices for Bringing Work to the W3C Recommendation Track +# Recommendation Track Readiness ## Status -Last updated on 2015/12/09 +Last updated on 2015/12/12 NO OFFICIAL STATUS! Distributed to the W3C Advisory board for discussion ## Purpose This document lists considerations to take into account when evaluating proposals to move specification work -to the W3C Recommendation track. The target audience include the Team and Director when evaluating proposals to create new Working Groups or rechartering +to the W3C Recommendation track. If offers *guidelines* that deserve consideration, and is +NOT a checklist of required items in every proposal, and meeting all the guidelines does not guarantee approval. +The target audience includes the Team and Director when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope, working group Chairs when determining whether to publish First Public Working Drafts of specs that are in a group's chartered scope, and by Advisory Committee representatives when voting on charters and Proposed Recommendations. @@ -19,15 +21,27 @@ It tries to strike a balance between two classes of criteria: Discussion at the [October 2015 Advisory Committee meeting](https://www.w3.org/2015/10/27-ac-minutes.html#item02) indicated disparate opinions about whether to insist that proposed work should meet empirical criteria before being -put on the Recommendation track. Arguments against using W3C Community Groups to incubate proposals until they -met such criteria included: +put on the Recommendation track. + +Arguments in favor of mandatory incubation included: +- The status quo "aspirational" approach assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers +tend to create specs that don't get used in the real world. +- Recommendation track documents that don't get implented or widely used do not advance W3C's mission or enhance its reputation +- W3C should join the industry trend toward more data-driven decision making +- It's useful to identify *what* criteria are prerequisites for a Recommendation Track effort, but not to prescribe *how* those +criteria are to be met. So incubation in a CG is just one way to meet the criteria, not the only way. + +Arguments against mandating using W3C Community Groups to incubate proposals until they +met empirical criteria included: - Incubation isn't a silver bullet to be applied to every situation - If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate them to take it to a WG for broad review - If the CG did not work by consensus, the de facto standard might be imposed by a single strong editor or cabal of the top browsers -- There may be gaps in the patent commitment if all spec contributors don't join the WG +- There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG -This document tries to identify *what* criteria promote the success of a Recommendation Track effort rather than prescribing *how* those -criteria are to be met. +The readiness criteria below outline the W3C community's sens of the best practices for striking an appropriate balance among these perspectives. +They encourage all involved in advancing work to the Recommendation track to have more evidence +*available* for the decision and to think carefully about how to interpret it. It does not propose an algorithmic process that uses only +hard data without a role for human judgment. ##Readiness Criteria @@ -64,31 +78,31 @@ by those who need to use it? Are their critical dependencies, e.g. the spec mus or must be supported both in products for producers and consumers of web content, to be really useful? ### Risks -The proposal considers whether standrdiing the spec could create more problems than it solves. +The proposal considers whether standardizing the spec could create more problems than it solves. What are the potential downsides of having this feature standardized ...could it undermine security, privacy, accessibility, etc. if broadly deployed? Are there scenarios under which we would regret standardizing this feature? ### Socialized proposal -*Strongly Recommended*: A draft of the technical specification has been written down and socialized in a community where website +*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where website developer, framework/took developer, and core technology implementers are represented. If that discussion has has generated sustained expressions of opposition or unwillingness to implement / make patent commitments from key stakeholders, proposers are well advised to make a persuasive case for how the proposed Recommendation Track work can be successful in the face of this opposition. ### Expressions of interest -The proposal points to statementss of support from key stakeholders about the value proposition for the feature +The proposal points to statements of support from key stakeholders about the value proposition for the feature it describes. Is there a critical mass of implementers tentatively interested in shipping this feature if standardized? Are there prototype / polyfill implementations that are used in experimental websites that site developers find useful? ### Evidence -Proposers SHOULD describe what implementation and user experience is there to back up the points above. +Proposers describes what implementation and user experience is there to back up the points above. What fraction of websites are implementing a similar feature in a non-standardized way? How many users would potentially benefit from this feature if standardized? Hard data is preferred, but estimates backed up by detailed explanations are acceptable. ### Incubation -The draft SHOULD have matured through an incubation phase in WICG or another CG, IG, or have been submitted by a member +The draft has matured through an incubation phase in WICG or another CG, IG, or have been submitted by a member organization based on product experience. The language in the [Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) describes a best practice: @@ -108,17 +122,22 @@ who interact with various levels of trust. Thus the proposers of Recommendation accommodate feedback to make a spec more internationalizeable, accessible, secure, etc. Likewise it should not promote the interests of one group of members at the expense of another, e.g. taking sides in a product-driven "standards war." +### Is the timing right? +The optimal timing for a transition to the Recommendation Track can be described as: +- NO SOONER than the MUST criteria and a reasonable number of the SHOULD criteria above are met. +- NO LATER THAN a point where the spec is still fluid, and not frozen into shipping code used on many websites. + +If the answer “the ship has sailed”, proposers whould explain how they propose to mitigate the situation without turning back the clock, +and what a Recommendation Track document could do to improve the situation. For example, clearly documenting what already interoperates, +and getting broader patent commitments on the interoperable behavior arguably has value. + ##Conclusion -The criteria above boil down to 3 basic questions: +The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions: - Does the work address a real un-met need or missed opportunity for the Web? - Does the work start from a concrete proposal that has been socialized with key stakeholders but doesn't discriminate against others? - Does standardizing the proposed spec have clear support from those who would need to implement and use the spec for it to be successful? -Transition to the Recommendation Track should happen ... - -NO SOONER than the MUST criteria and a reasonable number of the SHOULD criteria above are met. -NO LATER THAN a point where the spec is still fluid, and not frozen into shipping code used on many websites. From dc5cda879a6ef35a5bd1b7847381b21fea158bea Mon Sep 17 00:00:00 2001 From: Michael Champion Date: Mon, 14 Dec 2015 10:06:09 -0800 Subject: [PATCH 05/47] Editorial update incorporating Jeff's comments --- bp.md | 43 ++++++++++++++++++++++++------------------- 1 file changed, 24 insertions(+), 19 deletions(-) diff --git a/bp.md b/bp.md index 023e210..ac7fc52 100644 --- a/bp.md +++ b/bp.md @@ -2,13 +2,13 @@ ## Status -Last updated on 2015/12/12 +Last updated on 2015/12/14 NO OFFICIAL STATUS! Distributed to the W3C Advisory board for discussion ## Purpose -This document lists considerations to take into account when evaluating proposals to move specification work +This document lists criteria to consider when evaluating proposals to move specification work to the W3C Recommendation track. If offers *guidelines* that deserve consideration, and is NOT a checklist of required items in every proposal, and meeting all the guidelines does not guarantee approval. The target audience includes the Team and Director when evaluating proposals to create new Working Groups or rechartering @@ -24,7 +24,7 @@ indicated disparate opinions about whether to insist that proposed work should m put on the Recommendation track. Arguments in favor of mandatory incubation included: -- The status quo "aspirational" approach assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers +- The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers tend to create specs that don't get used in the real world. - Recommendation track documents that don't get implented or widely used do not advance W3C's mission or enhance its reputation - W3C should join the industry trend toward more data-driven decision making @@ -38,7 +38,7 @@ met empirical criteria included: - If the CG did not work by consensus, the de facto standard might be imposed by a single strong editor or cabal of the top browsers - There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG -The readiness criteria below outline the W3C community's sens of the best practices for striking an appropriate balance among these perspectives. +The readiness criteria below outline the W3C community's sense of the best practices for striking an appropriate balance among these perspectives. They encourage all involved in advancing work to the Recommendation track to have more evidence *available* for the decision and to think carefully about how to interpret it. It does not propose an algorithmic process that uses only hard data without a role for human judgment. @@ -60,21 +60,24 @@ more explicit and generally applicable. The "emprical" criteria are inspired largely by the experience of some open source browser projects that use an [intent to implement](https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit#) process to build the case for shipping -a new feature. The [Web Platform Incubator Community Group](https://www.w3.org/community/wicg/) has adopted -something similar to [determine when a spec under incubation is ready to propose to a -Working Group](https://wicg.github.io/admin/intent-to-migrate.html). This document refines this approach to apply to Recommendation +a new feature.This document refines this approach to apply to Recommendation Track transition decisions. +The [Web Platform Incubator Community Group](https://www.w3.org/community/wicg/) has adopted +something similar to [determine when a spec under incubation is ready to propose to a +Working Group](https://wicg.github.io/admin/intent-to-migrate.html). ### Problem statement *Strongly Recommended*: The proposal identifies the real-world problem this work would address, and why existing solutions are inadequate. What are websites forced to do without this feature being available in a standardized way? -What fraction of websites are implementing a similar feature in a non-standardized way? +What fraction of web sites / applications are implementing a similar feature in a non-standardized way? How would users benefit from this feature if standardized? ### Success criteria *Strongly Recommended*: The proposal enumerates the types of products (browsers, servers, frameworks, applications...) would need to support the spec for it to be -successful, and indicate what degree of critical mass would be needed. Is this spec serving a niche market and can be implemented only -by those who need to use it? Are their critical dependencies, e.g. the spec must be deployed on both the cloud/server and browser/client, +successful, and indicate what degree of critical mass would be needed. +Is this spec serving a niche market and can be implemented only +by those who need to use it? Are their critical dependencies, e.g. the spec must be deployed on both +the cloud/server and browser/client, or must be supported both in products for producers and consumers of web content, to be really useful? ### Risks @@ -83,20 +86,20 @@ What are the potential downsides of having this feature standardized ...could it if broadly deployed? Are there scenarios under which we would regret standardizing this feature? ### Socialized proposal -*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where website +*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where web stite / app developer, framework/took developer, and core technology implementers are represented. If that discussion has -has generated sustained expressions of opposition or unwillingness to implement / make patent commitments +generated sustained expressions of opposition or unwillingness to implement / make patent commitments from key stakeholders, proposers are well advised to make a persuasive case for how the proposed Recommendation Track work can be successful in the face of this opposition. ### Expressions of interest The proposal points to statements of support from key stakeholders about the value proposition for the feature it describes. Is there a critical mass of implementers tentatively interested in shipping this feature -if standardized? Are there prototype / polyfill implementations that are used in experimental websites that site developers -find useful? +if standardized? Are there prototype / polyfill implementations that are used in experimental apps / sites +that developers already find useful? ### Evidence -Proposers describes what implementation and user experience is there to back up the points above. +The propsal describes what implementation and user experience is there to back up the points above. What fraction of websites are implementing a similar feature in a non-standardized way? How many users would potentially benefit from this feature if standardized? Hard data is preferred, but estimates backed up by detailed explanations are acceptable. @@ -112,8 +115,11 @@ describes a best practice: ### Clear RF Licensing Commitments W3C seeks to issue Recommendations that can be implemented on a [Royalty-Free](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requiremenst) basis. -1. Are the technologies in the initial available under terms that are compatible with the [W3C Royalty-Free licensing requirements](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements)? -3. Is the provenance of contributions to the draft reasonable clear? +1. Are the technologies in the initial available under terms that are compatible with the +[W3C Royalty-Free licensing requirements](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements)? +2. Have those who seem most likely to have relevant patents made commitments to license them on +royalty-free terms? +3. Is the provenance of substantive contributions to the draft reasonably clear? ### The proposers are not seeking a rubber stamp from W3C W3C Recommendations signify a broad consensus across the membership of W3C that a spec both serves a real mainstream need @@ -124,7 +130,7 @@ the interests of one group of members at the expense of another, e.g. taking sid ### Is the timing right? The optimal timing for a transition to the Recommendation Track can be described as: -- NO SOONER than the MUST criteria and a reasonable number of the SHOULD criteria above are met. +- NO SOONER than the bulk of the criteria above are met. - NO LATER THAN a point where the spec is still fluid, and not frozen into shipping code used on many websites. If the answer “the ship has sailed”, proposers whould explain how they propose to mitigate the situation without turning back the clock, @@ -132,7 +138,6 @@ and what a Recommendation Track document could do to improve the situation. For and getting broader patent commitments on the interoperable behavior arguably has value. ##Conclusion - The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions: - Does the work address a real un-met need or missed opportunity for the Web? - Does the work start from a concrete proposal that has been socialized with key stakeholders but doesn't discriminate against others? From d3aaf95362299daa6aec0b3d3f060e3b669dcdea Mon Sep 17 00:00:00 2001 From: Michael Champion Date: Mon, 14 Dec 2015 11:31:44 -0800 Subject: [PATCH 06/47] Fixed reference to RFC 2119 --- bp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bp.md b/bp.md index ac7fc52..3435027 100644 --- a/bp.md +++ b/bp.md @@ -47,7 +47,7 @@ hard data without a role for human judgment. ##Readiness Criteria The criteria here are used to evaluate whether a proposal indicates that a particular technical specification development effort is -ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids [RFC 2118]() "MUST" and "SHOULD" terminology, and should not be a taken +ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) "MUST" and "SHOULD" terminology, and should not be a taken as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are noted as "strongly recommended", and if not met an explanation of why they don't apply in a particular situation would facilitate the Director's decision. Different cases will involve different combinations of these factors. In determining whether to From 06ff0213c2883c461f765f84fdf1f65b9ca0bf0b Mon Sep 17 00:00:00 2001 From: Michael Champion Date: Tue, 15 Dec 2015 13:32:24 -0800 Subject: [PATCH 07/47] "lead the web" Small editorial changes plus made explicit the traditional criterion that Rec-track work should "lead the web its its full potential" --- bp.md | 11 +++++++++-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/bp.md b/bp.md index 3435027..3a70ca8 100644 --- a/bp.md +++ b/bp.md @@ -9,8 +9,8 @@ NO OFFICIAL STATUS! Distributed to the W3C Advisory board for discussion ## Purpose This document lists criteria to consider when evaluating proposals to move specification work -to the W3C Recommendation track. If offers *guidelines* that deserve consideration, and is -NOT a checklist of required items in every proposal, and meeting all the guidelines does not guarantee approval. +to the W3C Recommendation track. If offers guidelines that deserve consideration, but is +not a checklist of required items in every proposal --meeting all the guidelines does not guarantee approval. The target audience includes the Team and Director when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope, working group Chairs when determining whether to publish First Public Working Drafts of specs that are in a group's chartered scope, and by Advisory Committee representatives when voting on charters and Proposed Recommendations. @@ -137,6 +137,13 @@ If the answer “the ship has sailed”, proposers whould explain how they propo and what a Recommendation Track document could do to improve the situation. For example, clearly documenting what already interoperates, and getting broader patent commitments on the interoperable behavior arguably has value. +### Lead the Web to its full potential? +Assessing work against the W3C mission statement +is the traditional criterion the Team and Director use to evaluate whether to start a working group or advance a +a specification. It remains the bottom line for Recommendation Track decisions. Applying this criterion requires a +judgment that balances an aspiration advance the Web with the need for real developers to make the Web work in practice. + + ##Conclusion The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions: - Does the work address a real un-met need or missed opportunity for the Web? From 8c264056ace56b74fbe97377c71625efb9b2acff Mon Sep 17 00:00:00 2001 From: michaelchampion Date: Mon, 21 Dec 2015 08:05:02 -0800 Subject: [PATCH 08/47] Editorial fixes --- bp.md | 45 +++++++++++++++++++++++---------------------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/bp.md b/bp.md index 3a70ca8..d458757 100644 --- a/bp.md +++ b/bp.md @@ -26,7 +26,7 @@ put on the Recommendation track. Arguments in favor of mandatory incubation included: - The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers tend to create specs that don't get used in the real world. -- Recommendation track documents that don't get implented or widely used do not advance W3C's mission or enhance its reputation +- Recommendation track documents that don't get implemented or widely used do not advance W3C's mission or enhance its reputation - W3C should join the industry trend toward more data-driven decision making - It's useful to identify *what* criteria are prerequisites for a Recommendation Track effort, but not to prescribe *how* those criteria are to be met. So incubation in a CG is just one way to meet the criteria, not the only way. @@ -54,13 +54,18 @@ facilitate the Director's decision. Different cases will involve different comb approve moving work to the Recommendation track, the Director may consider other factors not listed in this document as well. -In general, the "aspirational" criteria have been used by the team and Director for some time, and this document seeks to make them +Assessing proposed work's ability to fulfull the W3C mission to [lead the web to its full potential](http://www.w3.org/Consortium/mission) +is the traditional criterion the Team and Director use to evaluate whether to start a working group or advance +a specification. While this is "aspirational", it requires +judgment that balances the future potential the Web alongside the need for real developers to make the Web work in practice. +This document seeks to make the factors that go into this judgment more explicit and generally applicable. -The "emprical" criteria are inspired largely by the experience of some open source browser projects + +The "empirical" criteria are inspired largely by the experience of some open source browser projects that use an [intent to implement](https://docs.google.com/document/d/1vlTlsQKThwaX0-lj_iZbVTzyqY7LioqERU8DK3u3XjI/edit#) process to build the case for shipping -a new feature.This document refines this approach to apply to Recommendation +a new feature. This document refines this approach to apply to Recommendation Track transition decisions. The [Web Platform Incubator Community Group](https://www.w3.org/community/wicg/) has adopted something similar to [determine when a spec under incubation is ready to propose to a @@ -86,7 +91,7 @@ What are the potential downsides of having this feature standardized ...could it if broadly deployed? Are there scenarios under which we would regret standardizing this feature? ### Socialized proposal -*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where web stite / app +*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where web site / app developer, framework/took developer, and core technology implementers are represented. If that discussion has generated sustained expressions of opposition or unwillingness to implement / make patent commitments from key stakeholders, proposers are well advised to make a persuasive case for how the proposed Recommendation Track work @@ -99,7 +104,7 @@ if standardized? Are there prototype / polyfill implementations that are used in that developers already find useful? ### Evidence -The propsal describes what implementation and user experience is there to back up the points above. +The proposal describes what implementation and user experience is there to back up the points above. What fraction of websites are implementing a similar feature in a non-standardized way? How many users would potentially benefit from this feature if standardized? Hard data is preferred, but estimates backed up by detailed explanations are acceptable. @@ -111,6 +116,17 @@ organization based on product experience. The language in the describes a best practice: > The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase. + +### Is the timing right? +The optimal timing for a transition to the Recommendation Track can be described as: +- NO SOONER than the bulk of the criteria above are met. +- NO LATER THAN a point where the spec is still fluid, and not frozen into shipping code used on many websites. + +If the answer “the ship has sailed”, proposers should explain how they propose to mitigate the situation without turning back the clock, +and what a Recommendation Track document could do to improve the situation. For example, clearly documenting what already interoperates, +and getting broader patent commitments on the interoperable behavior arguably has value. + + ## Additional Considerations ### Clear RF Licensing Commitments @@ -125,24 +141,9 @@ royalty-free terms? W3C Recommendations signify a broad consensus across the membership of W3C that a spec both serves a real mainstream need and it is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and who interact with various levels of trust. Thus the proposers of Recommendation-track work should be prepared to -accommodate feedback to make a spec more internationalizeable, accessible, secure, etc. Likewise it should not promote +accommodate feedback to make a spec more internationalizeable, accessible, secure, etc. Likewise,it should not promote the interests of one group of members at the expense of another, e.g. taking sides in a product-driven "standards war." -### Is the timing right? -The optimal timing for a transition to the Recommendation Track can be described as: -- NO SOONER than the bulk of the criteria above are met. -- NO LATER THAN a point where the spec is still fluid, and not frozen into shipping code used on many websites. - -If the answer “the ship has sailed”, proposers whould explain how they propose to mitigate the situation without turning back the clock, -and what a Recommendation Track document could do to improve the situation. For example, clearly documenting what already interoperates, -and getting broader patent commitments on the interoperable behavior arguably has value. - -### Lead the Web to its full potential? -Assessing work against the W3C mission statement -is the traditional criterion the Team and Director use to evaluate whether to start a working group or advance a -a specification. It remains the bottom line for Recommendation Track decisions. Applying this criterion requires a -judgment that balances an aspiration advance the Web with the need for real developers to make the Web work in practice. - ##Conclusion The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions: From f8671d017d7ca6cc5552d3967309a163266d32dd Mon Sep 17 00:00:00 2001 From: ianbjacobs Date: Tue, 22 Dec 2015 08:45:08 -0600 Subject: [PATCH 09/47] Editorial * AC Reps don't vote on charters; they review them * --- bp.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/bp.md b/bp.md index d458757..a1b3d12 100644 --- a/bp.md +++ b/bp.md @@ -13,7 +13,7 @@ to the W3C Recommendation track. If offers guidelines that deserve consideratio not a checklist of required items in every proposal --meeting all the guidelines does not guarantee approval. The target audience includes the Team and Director when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope, working group Chairs when determining whether to publish First Public Working Drafts of -specs that are in a group's chartered scope, and by Advisory Committee representatives when voting on charters and Proposed Recommendations. +specs that are in a group's chartered scope, and by Advisory Committee representatives when reviewing charters and Proposed Recommendations. It tries to strike a balance between two classes of criteria: - "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web @@ -24,10 +24,9 @@ indicated disparate opinions about whether to insist that proposed work should m put on the Recommendation track. Arguments in favor of mandatory incubation included: -- The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers -tend to create specs that don't get used in the real world. +- The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers tend to create specs that don't get used in the real world. - Recommendation track documents that don't get implemented or widely used do not advance W3C's mission or enhance its reputation -- W3C should join the industry trend toward more data-driven decision making +- The industry overall is moving toward more data-driven decision making - It's useful to identify *what* criteria are prerequisites for a Recommendation Track effort, but not to prescribe *how* those criteria are to be met. So incubation in a CG is just one way to meet the criteria, not the only way. @@ -54,7 +53,7 @@ facilitate the Director's decision. Different cases will involve different comb approve moving work to the Recommendation track, the Director may consider other factors not listed in this document as well. -Assessing proposed work's ability to fulfull the W3C mission to [lead the web to its full potential](http://www.w3.org/Consortium/mission) +Assessing whether proposed work is likely to fulfull the W3C mission to [lead the web to its full potential](http://www.w3.org/Consortium/mission) is the traditional criterion the Team and Director use to evaluate whether to start a working group or advance a specification. While this is "aspirational", it requires judgment that balances the future potential the Web alongside the need for real developers to make the Web work in practice. From 3e0ef06463552745f4bf3fbb9407a4133fee6f26 Mon Sep 17 00:00:00 2001 From: Michael Champion Date: Mon, 4 Jan 2016 14:42:59 -0800 Subject: [PATCH 10/47] Incorporate Ivar Herman feedback Attempted to resolve the issues raised by Ivar --- bp.md | 73 +++++++++++++++++++++++++++++++---------------------------- 1 file changed, 38 insertions(+), 35 deletions(-) diff --git a/bp.md b/bp.md index a1b3d12..75f3715 100644 --- a/bp.md +++ b/bp.md @@ -2,7 +2,7 @@ ## Status -Last updated on 2015/12/14 +Last updated on 2016/01/04 NO OFFICIAL STATUS! Distributed to the W3C Advisory board for discussion @@ -72,35 +72,46 @@ Working Group](https://wicg.github.io/admin/intent-to-migrate.html). ### Problem statement *Strongly Recommended*: The proposal identifies the real-world problem this work would address, and why existing solutions are inadequate. -What are websites forced to do without this feature being available in a standardized way? -What fraction of web sites / applications are implementing a similar feature in a non-standardized way? +What are web developers forced to do without this feature being available in a standardized way? +What fraction of web sites, hybrid applications, data publishers, etc. are using a similar capability in a non-standardized way? How would users benefit from this feature if standardized? ### Success criteria -*Strongly Recommended*: The proposal enumerates the types of products (browsers, servers, frameworks, applications...) would need to support the spec for it to be +*Strongly Recommended*: The proposal enumerates the types of products (browsers, servers, frameworks, applications...) would need to +support the spec for it to be successful, and indicate what degree of critical mass would be needed. -Is this spec serving a niche market and can be implemented only -by those who need to use it? Are their critical dependencies, e.g. the spec must be deployed on both +Is this spec serving a specialized community and only that community needs to implement and adopt it for it to be successful? +by those who need to use it? Or are there critical ecosystem dependencies, e.g. the spec must be deployed on both the cloud/server and browser/client, or must be supported both in products for producers and consumers of web content, to be really useful? -### Risks -The proposal considers whether standardizing the spec could create more problems than it solves. -What are the potential downsides of having this feature standardized ...could it undermine security, privacy, accessibility, etc. -if broadly deployed? Are there scenarios under which we would regret standardizing this feature? - ### Socialized proposal -*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where web site / app -developer, framework/took developer, and core technology implementers are represented. If that discussion has -generated sustained expressions of opposition or unwillingness to implement / make patent commitments -from key stakeholders, proposers are well advised to make a persuasive case for how the proposed Recommendation Track work -can be successful in the face of this opposition. +*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where potential users, web site / app +developer, framework/took developer, and core technology implementers are represented. +The state of community consensus around the initial draft should be documented: Did potential users and key implementers participate openly +in the discussion? Are there any indications that social or economic pressure was applied to suppress dissent? Did the discussion generate sustained expressions of opposition or unwillingness to implement / use / make patent +commitments from key stakeholders? If there are indications that consensus in a WG will be difficult to achieve, proposers are well advised +to make a persuasive case for how the proposed Recommendation Track work can be successful. + +### The proposers are not seeking a rubber stamp from W3C +*Strongly Recommended*: W3C Recommendations signify a broad consensus across the membership of W3C that a spec both serves a real mainstream need +and it is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and +who interact with various levels of trust. Thus the proposers of Recommendation-track work should be prepared to +accommodate feedback to make a spec more internationalizeable, accessible, secure, etc. Likewise,it should not promote +the interests of one group of members at the expense of another, e.g. taking sides in a product-driven "standards war." + +### Incubation +The draft has matured through an incubation phase in WICG or another CG, IG, or have been submitted by a member +organization based on product experience. The language in the +[Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) +describes a best practice: +> The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase. ### Expressions of interest The proposal points to statements of support from key stakeholders about the value proposition for the feature -it describes. Is there a critical mass of implementers tentatively interested in shipping this feature +it describes. Is there strong demand from potential users? Is there a critical mass of implementers tentatively interested in shipping this feature if standardized? Are there prototype / polyfill implementations that are used in experimental apps / sites -that developers already find useful? +that the target audience already finds useful? ### Evidence The proposal describes what implementation and user experience is there to back up the points above. @@ -108,13 +119,10 @@ What fraction of websites are implementing a similar feature in a non-standardiz How many users would potentially benefit from this feature if standardized? Hard data is preferred, but estimates backed up by detailed explanations are acceptable. -### Incubation -The draft has matured through an incubation phase in WICG or another CG, IG, or have been submitted by a member -organization based on product experience. The language in the -[Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) -describes a best practice: -> The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase. - +### Risks +The proposal considers whether standardizing the spec could create more problems than it solves. +What are the potential downsides of having this feature standardized ...could it undermine security, privacy, accessibility, etc. +if broadly deployed? Are there scenarios under which we would regret standardizing this feature? ### Is the timing right? The optimal timing for a transition to the Recommendation Track can be described as: @@ -126,23 +134,18 @@ and what a Recommendation Track document could do to improve the situation. For and getting broader patent commitments on the interoperable behavior arguably has value. -## Additional Considerations - ### Clear RF Licensing Commitments -W3C seeks to issue Recommendations that can be implemented on a [Royalty-Free](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requiremenst) basis. + +W3C seeks to issue Recommendations that can be implemented and used on a [Royalty-Free](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requiremenst) basis. 1. Are the technologies in the initial available under terms that are compatible with the [W3C Royalty-Free licensing requirements](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements)? 2. Have those who seem most likely to have relevant patents made commitments to license them on royalty-free terms? 3. Is the provenance of substantive contributions to the draft reasonably clear? -### The proposers are not seeking a rubber stamp from W3C -W3C Recommendations signify a broad consensus across the membership of W3C that a spec both serves a real mainstream need -and it is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and -who interact with various levels of trust. Thus the proposers of Recommendation-track work should be prepared to -accommodate feedback to make a spec more internationalizeable, accessible, secure, etc. Likewise,it should not promote -the interests of one group of members at the expense of another, e.g. taking sides in a product-driven "standards war." - +### Team Engagement +It is advisable for groups considering Recommendation Track work to consult with the W3C +Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal. Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups do not, but they are encouraged to reach out to the W3C staff in advance. ##Conclusion The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions: From 4353027ac2927269d2b0b52c4e7b21e4c280587b Mon Sep 17 00:00:00 2001 From: Michael Champion Date: Thu, 7 Jan 2016 10:19:10 -0800 Subject: [PATCH 11/47] Editorial polishing --- bp.md | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/bp.md b/bp.md index 75f3715..0a44109 100644 --- a/bp.md +++ b/bp.md @@ -38,14 +38,13 @@ met empirical criteria included: - There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG The readiness criteria below outline the W3C community's sense of the best practices for striking an appropriate balance among these perspectives. -They encourage all involved in advancing work to the Recommendation track to have more evidence -*available* for the decision and to think carefully about how to interpret it. It does not propose an algorithmic process that uses only +They encourage all involved in advancing work to the Recommendation track to have more evidence available for the decision and to think carefully about how to interpret it. It does not propose an algorithmic process that uses only hard data without a role for human judgment. ##Readiness Criteria -The criteria here are used to evaluate whether a proposal indicates that a particular technical specification development effort is +The criteria here are used to evaluate whether a technical specification development effort is ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) "MUST" and "SHOULD" terminology, and should not be a taken as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are noted as "strongly recommended", and if not met an explanation of why they don't apply in a particular situation would @@ -81,30 +80,30 @@ How would users benefit from this feature if standardized? support the spec for it to be successful, and indicate what degree of critical mass would be needed. Is this spec serving a specialized community and only that community needs to implement and adopt it for it to be successful? -by those who need to use it? Or are there critical ecosystem dependencies, e.g. the spec must be deployed on both +Or are there critical ecosystem dependencies, e.g. the spec must be deployed on both the cloud/server and browser/client, or must be supported both in products for producers and consumers of web content, to be really useful? ### Socialized proposal -*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where potential users, web site / app +*Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where potential users, web site / app developer, framework/took developer, and core technology implementers are represented. -The state of community consensus around the initial draft should be documented: Did potential users and key implementers participate openly +The state of community consensus around the initial draft should be documented: Did potential users and key implementers actively participate in the discussion? Are there any indications that social or economic pressure was applied to suppress dissent? Did the discussion generate sustained expressions of opposition or unwillingness to implement / use / make patent commitments from key stakeholders? If there are indications that consensus in a WG will be difficult to achieve, proposers are well advised to make a persuasive case for how the proposed Recommendation Track work can be successful. ### The proposers are not seeking a rubber stamp from W3C -*Strongly Recommended*: W3C Recommendations signify a broad consensus across the membership of W3C that a spec both serves a real mainstream need -and it is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and -who interact with various levels of trust. Thus the proposers of Recommendation-track work should be prepared to -accommodate feedback to make a spec more internationalizeable, accessible, secure, etc. Likewise,it should not promote +*Strongly Recommended*: Proposers of Recommendation-track work should be prepared for the Working Group to +make substantive changes to the initial draft in response to feedback. A W3C Recommendation sigfifies that a specification has broad consensus across the membership of W3C. It is particularly important to ensure that a spec both serves a real mainstream need +*and* is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and +who interact with various levels of trust. Likewise, proposed Recommendation-track work should not promote the interests of one group of members at the expense of another, e.g. taking sides in a product-driven "standards war." ### Incubation The draft has matured through an incubation phase in WICG or another CG, IG, or have been submitted by a member organization based on product experience. The language in the [Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) -describes a best practice: +describes a good practice: > The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase. ### Expressions of interest From f94479a0df9f134ee225ca834b443f369f63ce5c Mon Sep 17 00:00:00 2001 From: Michael Champion Date: Thu, 7 Jan 2016 10:29:13 -0800 Subject: [PATCH 12/47] More editorial polishing --- bp.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/bp.md b/bp.md index 0a44109..8998021 100644 --- a/bp.md +++ b/bp.md @@ -2,7 +2,7 @@ ## Status -Last updated on 2016/01/04 +Last updated on 2016/01/06 NO OFFICIAL STATUS! Distributed to the W3C Advisory board for discussion @@ -102,8 +102,7 @@ the interests of one group of members at the expense of another, e.g. taking sid ### Incubation The draft has matured through an incubation phase in WICG or another CG, IG, or have been submitted by a member organization based on product experience. The language in the -[Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) -describes a good practice: +[Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) describes a good practice: > The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase. ### Expressions of interest @@ -144,7 +143,7 @@ royalty-free terms? ### Team Engagement It is advisable for groups considering Recommendation Track work to consult with the W3C -Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal. Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups do not, but they are encouraged to reach out to the W3C staff in advance. +Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal. Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups do not, but they are encouraged to reach out to the W3C staff well in advance of proposing a transition to the Recommendation Track. ##Conclusion The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions: From 0a10bb6b1794c50a1b021c7c0ad6092fa3b53d7d Mon Sep 17 00:00:00 2001 From: Wendy Seltzer Date: Fri, 29 Jan 2016 13:32:02 -0500 Subject: [PATCH 13/47] Add team involvement to develop proposals --- bp.md | 1 + 1 file changed, 1 insertion(+) diff --git a/bp.md b/bp.md index 8998021..ccca096 100644 --- a/bp.md +++ b/bp.md @@ -36,6 +36,7 @@ met empirical criteria included: - If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate them to take it to a WG for broad review - If the CG did not work by consensus, the de facto standard might be imposed by a single strong editor or cabal of the top browsers - There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG +- It may be valuable for W3C team to help develop one or more proposals in the incubation stage The readiness criteria below outline the W3C community's sense of the best practices for striking an appropriate balance among these perspectives. They encourage all involved in advancing work to the Recommendation track to have more evidence available for the decision and to think carefully about how to interpret it. It does not propose an algorithmic process that uses only From 0196b080fe1e0a8baf1f9b929b58bfff4dbb847a Mon Sep 17 00:00:00 2001 From: michaelchampion Date: Sun, 31 Jan 2016 09:23:32 -0800 Subject: [PATCH 14/47] Updated draft based on AC, AB, and GitHub comments MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Added an explicit list of the problems these best practices attempt to solve Made more explicit that that the criteria are most important at the FPWD stage, but may be applied earlier Incorporated language from those opposing mandatory incubation at the AC meeting and tried to stress that its the maturity of a proposal and not the way it got to maturity that is being assessed. Made incubation “strongly recommended” while attempting to defuse opposition from those uncomfortable with mandating that incubation happen in CGs. Stressed that while pre Rec Track processes don’t mandate consensus, mature proposals should indeed have broad consensus across relevant stakeholders Added a Process Considerations section to capture questions that have come up in discussions but are not in scope for this document --- bp.md | 153 ++++++++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 117 insertions(+), 36 deletions(-) diff --git a/bp.md b/bp.md index 8998021..576f258 100644 --- a/bp.md +++ b/bp.md @@ -1,21 +1,45 @@ -# Recommendation Track Readiness +# Recommendation Track Readiness Best Practices ## Status +Updated draft based on AC, AB, and GitHub comments -Last updated on 2016/01/06 +Last updated on 2016/01/31 -NO OFFICIAL STATUS! Distributed to the W3C Advisory board for discussion +## Problem Statement +The practices proposed in this document are intended to address some specific problems: -## Purpose +1. W3C wastes resources by working on standardization efforts that end up going nowhere -This document lists criteria to consider when evaluating proposals to move specification work -to the W3C Recommendation track. If offers guidelines that deserve consideration, but is -not a checklist of required items in every proposal --meeting all the guidelines does not guarantee approval. -The target audience includes the Team and Director when evaluating proposals to create new Working Groups or rechartering -existing Working Groups to put new work in scope, working group Chairs when determining whether to publish First Public Working Drafts of -specs that are in a group's chartered scope, and by Advisory Committee representatives when reviewing charters and Proposed Recommendations. +2. W3C tarnishes its credibility as a standards organization when publishing technical reports that have little relevance to +the Web as it actually exists. -It tries to strike a balance between two classes of criteria: +3. The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at "polishing" solid +proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities. + +4. The REC track sometimes confers unwarranted legitimacy to proposals that do not have buy-in from the stakeholders needed +get it to Recommendation and deployed on the real Web. + + +## Overview of a Solution + +To address these problems, W3C should and encourage specifications to be incubated outside the formal process, and more tightly focus its +formal standardization effors on specifications that are most likely to get consensus within the consortium +and be used on the real Web. This document proposes to do that by offering a short list of criteria to consider when evaluating proposals to move specification work +to the Recommendation track. That includes drafting the Deliverables section of a WG charter, but especially when publishing a FPWD. + +These are offered as guidelines, not a checklist of required items in every proposal. +Meeting all the guidelines will not guarantee Director approval of the charter or FPWD, nor will failing to meet some block approval. *The goal +of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by +WGs and judgment by the Director.* + +The target audience for this document includes: +- the Team and Director when evaluating proposals to create new Working Groups or rechartering +existing Working Groups to put new work in scope; +- working group Chairs determining whether to publish First Public Working Drafts of +specs that are in a group's chartered scope, +- Advisory Committee representatives reviewing charters and Proposed Recommendations. + +This document attempts to strike a balance between two classes of criteria: - "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web - "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters @@ -30,17 +54,18 @@ Arguments in favor of mandatory incubation included: - It's useful to identify *what* criteria are prerequisites for a Recommendation Track effort, but not to prescribe *how* those criteria are to be met. So incubation in a CG is just one way to meet the criteria, not the only way. -Arguments against mandating using W3C Community Groups to incubate proposals until they +Arguments against focused on mandating using W3C Community Groups to incubate proposals until they met empirical criteria included: - Incubation isn't a silver bullet to be applied to every situation -- If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate them to take it to a WG for broad review -- If the CG did not work by consensus, the de facto standard might be imposed by a single strong editor or cabal of the top browsers +- If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate proponents to take it to a WG for broad review +- Requiring external incubation in a venue that doesn't require broad consensus + could lead to key technical decisions being made in forums dominated by a few, + with "level playing field" discussion beginning only when implementation momentum makes change difficult. - There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG -The readiness criteria below outline the W3C community's sense of the best practices for striking an appropriate balance among these perspectives. -They encourage all involved in advancing work to the Recommendation track to have more evidence available for the decision and to think carefully about how to interpret it. It does not propose an algorithmic process that uses only -hard data without a role for human judgment. - +The readiness criteria below outline best practices for finding an appropriate balance among these perspectives. +They encourage all involved in advancing work to the Recommendation track to gather more evidence to drive the decision and to think carefully +about how to interpret it. They do not mandate any one mode of gathering that evidence or an algorithm to assess it. ##Readiness Criteria @@ -69,13 +94,13 @@ The [Web Platform Incubator Community Group](https://www.w3.org/community/wicg/ something similar to [determine when a spec under incubation is ready to propose to a Working Group](https://wicg.github.io/admin/intent-to-migrate.html). -### Problem statement +### Is there a clear problem statement? *Strongly Recommended*: The proposal identifies the real-world problem this work would address, and why existing solutions are inadequate. What are web developers forced to do without this feature being available in a standardized way? What fraction of web sites, hybrid applications, data publishers, etc. are using a similar capability in a non-standardized way? How would users benefit from this feature if standardized? -### Success criteria +### Are success criteria explicit? *Strongly Recommended*: The proposal enumerates the types of products (browsers, servers, frameworks, applications...) would need to support the spec for it to be successful, and indicate what degree of critical mass would be needed. @@ -84,7 +109,7 @@ Or are there critical ecosystem dependencies, e.g. the spec must be deployed on the cloud/server and browser/client, or must be supported both in products for producers and consumers of web content, to be really useful? -### Socialized proposal +### Is there a well-socialized proposal to address the problem? *Strongly Recommended*: An initial draft of the technical specification has been written down and socialized in a community where potential users, web site / app developer, framework/took developer, and core technology implementers are represented. The state of community consensus around the initial draft should be documented: Did potential users and key implementers actively participate @@ -92,32 +117,47 @@ in the discussion? Are there any indications that social or economic pressure wa commitments from key stakeholders? If there are indications that consensus in a WG will be difficult to achieve, proposers are well advised to make a persuasive case for how the proposed Recommendation Track work can be successful. -### The proposers are not seeking a rubber stamp from W3C +### Has the proposed spec been incubated to reasonable maturity? +*Strongly Recommended*: Charters do not list specs as deliverables, and WGs do not publish FWPDs, until there is +rough consensus across stakeholders that the spec solves a real problem, is likely to be implemented, and is likely to +be used on the Web. This consensus could emerge from an incubation phase in WICG or another CG, or in a WG that has an established +culture of taking and vetting suggestions from its public mailing list. + +The language in the +[Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) describes a one community's practice: +> The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community +Group or another similar incubation phase. + +If work is incubated in a CG, it is important to assess the degree of consensus behind a spec as well as its maturity. +While CG's are not required to work by consensus, those proposing work for the Recommendation track should favor proposals that +did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. + +The key word is "matured", and the key milestone is First Public Working Draft (FPWD). It may be inefficient to charter WGs that start with +a "blank sheet of paper" or multiple proposals with different use cases, but it hurts W3C's credibility to +publish a formal Technical Report that specifies a technology that does NOT meet clear user needs in a way that has a good chance to be implemented in products, tools, websites, +and web applications. However the incubation phase is done, and whichever of these criteria are applied before proposing standardization +or developing a charter,this document strongly recommends that only "mature" specs be published as FPWDs. + +### Is it clear the proposers are not seeking a rubber stamp from W3C? *Strongly Recommended*: Proposers of Recommendation-track work should be prepared for the Working Group to make substantive changes to the initial draft in response to feedback. A W3C Recommendation sigfifies that a specification has broad consensus across the membership of W3C. It is particularly important to ensure that a spec both serves a real mainstream need *and* is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and who interact with various levels of trust. Likewise, proposed Recommendation-track work should not promote the interests of one group of members at the expense of another, e.g. taking sides in a product-driven "standards war." -### Incubation -The draft has matured through an incubation phase in WICG or another CG, IG, or have been submitted by a member -organization based on product experience. The language in the -[Web Platform WG charter](http://w3c.github.io/charter-html/group-charter.html#deliverables) describes a good practice: -> The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase. - -### Expressions of interest +### Are there appropriate expressions of interest? The proposal points to statements of support from key stakeholders about the value proposition for the feature it describes. Is there strong demand from potential users? Is there a critical mass of implementers tentatively interested in shipping this feature if standardized? Are there prototype / polyfill implementations that are used in experimental apps / sites that the target audience already finds useful? -### Evidence +### Is there actual evidence to back up the answers? The proposal describes what implementation and user experience is there to back up the points above. What fraction of websites are implementing a similar feature in a non-standardized way? How many users would potentially benefit from this feature if standardized? Hard data is preferred, but estimates backed up by detailed explanations are acceptable. -### Risks +### Risks? The proposal considers whether standardizing the spec could create more problems than it solves. What are the potential downsides of having this feature standardized ...could it undermine security, privacy, accessibility, etc. if broadly deployed? Are there scenarios under which we would regret standardizing this feature? @@ -131,19 +171,60 @@ If the answer “the ship has sailed”, proposers should explain how they propo and what a Recommendation Track document could do to improve the situation. For example, clearly documenting what already interoperates, and getting broader patent commitments on the interoperable behavior arguably has value. +### Clear RF licensing commitments? -### Clear RF Licensing Commitments - -W3C seeks to issue Recommendations that can be implemented and used on a [Royalty-Free](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requiremenst) basis. +W3C seeks to issue Recommendations that can be implemented and used on a +[Royalty-Free](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requiremenst) basis. 1. Are the technologies in the initial available under terms that are compatible with the [W3C Royalty-Free licensing requirements](http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Requirements)? 2. Have those who seem most likely to have relevant patents made commitments to license them on royalty-free terms? 3. Is the provenance of substantive contributions to the draft reasonably clear? -### Team Engagement +### Team Engagement? It is advisable for groups considering Recommendation Track work to consult with the W3C -Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal. Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups do not, but they are encouraged to reach out to the W3C staff well in advance of proposing a transition to the Recommendation Track. +Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal. +Working Groups and Interest Groups have Team Contacts they can use for this purpose. +Community Groups do not, but they are encouraged to reach out to the W3C staff well in advance of proposing a transition to the Recommendation Track. + +##Process Considerations + +Discussion about these guidelines has generated a number of questions about how they relate to the W3C process and the Team's existing practices. +They are out of scope for this document, but they are listed for reference: + +###Granularity +Should the considerations above be applied at at the specification level or the feature level? + +###Charter Scopes and Deliverables +When chartering a new WG, is it appropriate to put in scope a number of features that are mostly "aspirational" and put in the deliverables +section only those that meet most of the criteria above? + +When an incubator spec is ready to move to a WG, does it wait (possibly a couple of years) +to get into a WG Charter or are is the expectation that WGs would re-charter to take on incubated spec proposals? + +Or is the best practice to make the *scope* of charters broad enough to encompass work that may be incubated during +the charter's lifetime, and the WG would only take up an actual deliverable once it is incubated? + + +###Community Groups and the W3C Process +How can we ensure that concerns raised at the TPAC 2015 AC meeting and the AC Forum thread on Mandatory Incubation are addressed +in the process or practice of W3C? + +###What to do when there is interest from users but not implementers? +Raised in the [AC discussions](https://lists.w3.org/Archives/Member/w3c-ac-forum/2016JanMar/0013.html). +Arguably this is what interest groups are for -- to build interest in new use cases. Creating WGs to standardize +solutions that are more expensive to implement than they return in value is part of the problem the readiness critia +exercise is trying to solve. + +###Should we revise the Process Document to talk about the role of CGs, IGs, and WGs in getting specs ready for the standards track? +There is little consistency across W3 subcommunities on domains on how CGs, IGs, and WGs relate to one another. +Is this appropriate flexibility or a prescription for confusion and contention? One could imagine adding some +more structure here, perhaps: +- IGs are focused on *users*, and primarily develop use cases for new Recommendations and guidelines for how to apply existing Recommendations. +- CGs are focused on *implementers*, and primarily develop spec proposals and prototypes. +- WGs are focused on building consensus across users and implementers to produce technical Recommendations that have demonstrable +value and interoperability. + ##Conclusion The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions: From f415532c7f3be9622402ad0d37694142303d39f5 Mon Sep 17 00:00:00 2001 From: michaelchampion Date: Mon, 1 Feb 2016 14:03:58 -0800 Subject: [PATCH 15/47] Additional updates after AB discussion Minor editorial changes, removed contentious points from the Process Considerations section --- ChangeLog.txt | 44 ++++++++++++++++++++++++++++++++++++++++++++ bp.md | 35 +++++++++++++++-------------------- 2 files changed, 59 insertions(+), 20 deletions(-) create mode 100644 ChangeLog.txt diff --git a/ChangeLog.txt b/ChangeLog.txt new file mode 100644 index 0000000..354b055 --- /dev/null +++ b/ChangeLog.txt @@ -0,0 +1,44 @@ +Change log 1/26/2016 + +Based on AB and other feedback, I've tried to explain the rationale for drafting this document. + +###Comment #1 Purpose first paragraph - "This document lists criteria to consider when evaluating proposals to move specification work to the W3C Recommendation track." + +In the text that follows it isn't clear whether this is about not allowing a deliverable to be listed in a proposed Charter or whether it means not allowing a deliverable to be published as a FPWD. "evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope" implies the former while "Chairs when determining whether to publish First Public Working Drafts" implies the latter. + +Is this about restricting what types of specs are permitted by the Charter or is it about what has to happen before a WG is permitted to undertake work on a spec that is permitted? + +"when reviewing charters and Proposed Recommendations" is at the end of the REC track, so doesn't seem to be related to decisions on moving to the REC track – it’s already on the REC track – maybe this also includes criteria for more than what is in the first sentence.. + + +###Comment #1 Purpose first paragraph - "This document lists criteria to consider when evaluating proposals to move specification work to the W3C Recommendation track." + +In the text that follows it isn't clear whether this is about not allowing a deliverable to be listed in a proposed Charter or whether it means not allowing a deliverable to be published as a FPWD. "evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope" implies the former while "Chairs when determining whether to publish First Public Working Drafts" implies the latter. + +Is this about restricting what types of specs are permitted by the Charter or is it about what has to happen before a WG is permitted to undertake work on a spec that is permitted? + +"when reviewing charters and Proposed Recommendations" is at the end of the REC track, so doesn't seem to be related to decisions on moving to the REC track – it’s already on the REC track – maybe this also includes criteria for more than what is in the first sentence.. + + + +#P1 - how is this applied to the many features in a proposed Charter? + +It is clear how this set of criteria apply in the WICG. Someone has a very specific proposal for one particular (often small) feature and they provide a bunch of evidence arguing it should transition to a WG. Is the idea that this to be done separately for every spec or every feature in the charter for a WG, like every feature or modification of a feature that the CSS WG will be permitted to work on? So if they have 15 new features in a recharter, they have 15 supplementary documents on how they meet the criteria? + +#P2 – what about hot topic WGs like Web Payments, IoT and W3C membership + +It seems fairly clear a WG like Web Payments wouldn’t come close to meeting these. I assume the same will be true for the upcoming IoT WG. Sometimes W3C seems to want a WG on a hot topic where the actual work could be done in an Interest Group. But an IG is viewed as not acceptable because potential members would not join just W3C for an IG. + +Should there be a new type of W3C WG for that? EWG – exploratory WG – nothing is REC track. It has an associated CG where it does incubator specs. You don’t get ultimate votes unless in the WG for whether to follow up in WG. + +#P3 – constant recharter churn? + +This increases the difficulty in getting specs into Charters. Charters are for 2 or 3 years. This would ban anything except work that has an incubator spec. Do incubator specs wait 2 years to the next recharter? Do the supergroups go into constant recharter mode? + +(the upcoming Hardware Security WG takes an approach to this problem where it has a “Restricted Scope” that it is allowed to produce specs on, but also may not – so it can add deliverables in that carefully described restricted scope) http://w3c.github.io/websec/hasec-charter + + +#P4 – long term impact on W3C – cg specs widely implemented get status + + + diff --git a/bp.md b/bp.md index b4eb8c7..f71b575 100644 --- a/bp.md +++ b/bp.md @@ -3,26 +3,27 @@ ## Status Updated draft based on AC, AB, and GitHub comments -Last updated on 2016/01/31 +Last updated on 2016/02/01 ## Problem Statement The practices proposed in this document are intended to address some specific problems: -1. W3C wastes resources by working on standardization efforts that end up going nowhere +1. W3C wastes resources when it invests in standardization efforts that end up going nowhere -2. W3C tarnishes its credibility as a standards organization when publishing technical reports that have little relevance to -the Web as it actually exists. +2. W3C tarnishes its credibility as a standards organization when publishing draft standards that have little relevance to +the Web as it actually exists. + +3. W3C sometimes confers unwarranted legitimacy to proposals that do not have buy-in from key stakeholders yet are published +as formal working drafts. 3. The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at "polishing" solid proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities. -4. The REC track sometimes confers unwarranted legitimacy to proposals that do not have buy-in from the stakeholders needed -get it to Recommendation and deployed on the real Web. ## Overview of a Solution -To address these problems, W3C should and encourage specifications to be incubated outside the formal process, and more tightly focus its +To address these problems, W3C should more tightly focus its formal standardization effors on specifications that are most likely to get consensus within the consortium and be used on the real Web. This document proposes to do that by offering a short list of criteria to consider when evaluating proposals to move specification work to the Recommendation track. That includes drafting the Deliverables section of a WG charter, but especially when publishing a FPWD. @@ -206,25 +207,19 @@ to get into a WG Charter or are is the expectation that WGs would re-charter to Or is the best practice to make the *scope* of charters broad enough to encompass work that may be incubated during the charter's lifetime, and the WG would only take up an actual deliverable once it is incubated? - ###Community Groups and the W3C Process How can we ensure that concerns raised at the TPAC 2015 AC meeting and the AC Forum thread on Mandatory Incubation are addressed in the process or practice of W3C? +Should the Process Document describe a role for CGs in getting specifications ready to be standardized? Should the Community +and Business Group Process say more about the importance of working by consensus, at least for specifications that +are to be proposed for the Recommendation Track? + ###What to do when there is interest from users but not implementers? Raised in the [AC discussions](https://lists.w3.org/Archives/Member/w3c-ac-forum/2016JanMar/0013.html). -Arguably this is what interest groups are for -- to build interest in new use cases. Creating WGs to standardize -solutions that are more expensive to implement than they return in value is part of the problem the readiness critia -exercise is trying to solve. - -###Should we revise the Process Document to talk about the role of CGs, IGs, and WGs in getting specs ready for the standards track? -There is little consistency across W3 subcommunities on domains on how CGs, IGs, and WGs relate to one another. -Is this appropriate flexibility or a prescription for confusion and contention? One could imagine adding some -more structure here, perhaps: -- IGs are focused on *users*, and primarily develop use cases for new Recommendations and guidelines for how to apply existing Recommendations. -- CGs are focused on *implementers*, and primarily develop spec proposals and prototypes. -- WGs are focused on building consensus across users and implementers to produce technical Recommendations that have demonstrable -value and interoperability. +Should the Process Document do more to describe a role for Interest Groups in developing use cases for new Recommendations, +and perhaps working in tandem with one or more Community Groups to develop credible technical proposals to address those +use cases? ##Conclusion From 314b92556f818449f99b849191a484671b5939c9 Mon Sep 17 00:00:00 2001 From: Wayne Carr Date: Wed, 3 Feb 2016 09:33:03 -0800 Subject: [PATCH 16/47] correct typos --- bp.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/bp.md b/bp.md index f71b575..770a102 100644 --- a/bp.md +++ b/bp.md @@ -74,7 +74,7 @@ about how to interpret it. They do not mandate any one mode of gathering that e The criteria here are used to evaluate whether a technical specification development effort is ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) "MUST" and "SHOULD" terminology, and should not be a taken as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are -noted as "strongly recommended", and if not met an explanation of why they don't apply in a particular situation would +noted as "strongly recommended", and, if not met, an explanation of why they don't apply in a particular situation would facilitate the Director's decision. Different cases will involve different combinations of these factors. In determining whether to approve moving work to the Recommendation track, the Director may consider other factors not listed in this document as well. @@ -82,7 +82,7 @@ other factors not listed in this document as well. Assessing whether proposed work is likely to fulfull the W3C mission to [lead the web to its full potential](http://www.w3.org/Consortium/mission) is the traditional criterion the Team and Director use to evaluate whether to start a working group or advance a specification. While this is "aspirational", it requires -judgment that balances the future potential the Web alongside the need for real developers to make the Web work in practice. +judgment that balances the future potential of the Web alongside the need for real developers to make the Web work in practice. This document seeks to make the factors that go into this judgment more explicit and generally applicable. @@ -142,7 +142,7 @@ or developing a charter,this document strongly recommends that only "mature" spe ### Is it clear the proposers are not seeking a rubber stamp from W3C? *Strongly Recommended*: Proposers of Recommendation-track work should be prepared for the Working Group to -make substantive changes to the initial draft in response to feedback. A W3C Recommendation sigfifies that a specification has broad consensus across the membership of W3C. It is particularly important to ensure that a spec both serves a real mainstream need +make substantive changes to the initial draft in response to feedback. A W3C Recommendation signifies that a specification has broad consensus across the membership of W3C. It is particularly important to ensure that a spec both serves a real mainstream need *and* is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and who interact with various levels of trust. Likewise, proposed Recommendation-track work should not promote the interests of one group of members at the expense of another, e.g. taking sides in a product-driven "standards war." From 6110802df6d090d1c7c974de1c4a7d2f89e46809 Mon Sep 17 00:00:00 2001 From: Wayne Carr Date: Wed, 3 Feb 2016 09:54:08 -0800 Subject: [PATCH 17/47] target audience - combine Director and AC bullets Director and AC both consider Charters and Proposed Recommendations. Bullets had AC only considering Charters and not Proposed Recommendations. So, can be consolidated into a single bullet. --- bp.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/bp.md b/bp.md index f71b575..782eeb7 100644 --- a/bp.md +++ b/bp.md @@ -34,11 +34,9 @@ of this effort is to add more structure and predictability to Rec track decision WGs and judgment by the Director.* The target audience for this document includes: -- the Team and Director when evaluating proposals to create new Working Groups or rechartering -existing Working Groups to put new work in scope; +- the Team and Director and Advisory Committee when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope (e.g. how specs reach maturation before FPWD), and in reviewing Proposed Recommendations; - working group Chairs determining whether to publish First Public Working Drafts of specs that are in a group's chartered scope, -- Advisory Committee representatives reviewing charters and Proposed Recommendations. This document attempts to strike a balance between two classes of criteria: - "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web From 7855ea09188bb0c13b629be937bf6e1f04390723 Mon Sep 17 00:00:00 2001 From: Wayne Carr Date: Wed, 3 Feb 2016 10:12:32 -0800 Subject: [PATCH 18/47] Reference W3C CG Charter template Reference optional W3C CG Charter template in the section about CG consensus. That charter is designed as a way to address the issues in that paragraph. --- bp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bp.md b/bp.md index f71b575..3177212 100644 --- a/bp.md +++ b/bp.md @@ -132,7 +132,7 @@ Group or another similar incubation phase. If work is incubated in a CG, it is important to assess the degree of consensus behind a spec as well as its maturity. While CG's are not required to work by consensus, those proposing work for the Recommendation track should favor proposals that -did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. +did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. An optional [W3C Community Group Charter Template](https://www.w3.org/community/council/wiki/Templates/CG_Charter) contains provisions designed to promote fairness in CGs. CGs are encouraged to consider using the template as a starting point. The key word is "matured", and the key milestone is First Public Working Draft (FPWD). It may be inefficient to charter WGs that start with a "blank sheet of paper" or multiple proposals with different use cases, but it hurts W3C's credibility to From 8f5311a81959c00c0980b6fc8be23da65f044ed1 Mon Sep 17 00:00:00 2001 From: Wayne Carr Date: Wed, 3 Feb 2016 10:22:45 -0800 Subject: [PATCH 19/47] problem statement downplays important WG roles wording sounds like WGs are just good at polishing near-finished specs. Add some other things WGs do. --- bp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bp.md b/bp.md index f71b575..c2f25a6 100644 --- a/bp.md +++ b/bp.md @@ -16,7 +16,7 @@ the Web as it actually exists. 3. W3C sometimes confers unwarranted legitimacy to proposals that do not have buy-in from key stakeholders yet are published as formal working drafts. -3. The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at "polishing" solid +3. The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at determining key use cases and requirements, choosing between alternative approaches to standardization, and "polishing" solid proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities. From f4c29d0c0843d1a421a7ab4ad586cb361480982a Mon Sep 17 00:00:00 2001 From: Wayne Carr Date: Wed, 17 Feb 2016 10:44:27 -0800 Subject: [PATCH 20/47] duplicating request #11 in latest version I went through and tried to reproduce the changes @chaals made - to make it easier to see in the diff. --- bp.md | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/bp.md b/bp.md index d684d68..438cb86 100644 --- a/bp.md +++ b/bp.md @@ -8,22 +8,12 @@ Last updated on 2016/02/01 ## Problem Statement The practices proposed in this document are intended to address some specific problems: -1. W3C wastes resources when it invests in standardization efforts that end up going nowhere +W3C wastes resources, and at worst tarnishes its credibility, when it invests in standardization efforts that end up going nowhere -2. W3C tarnishes its credibility as a standards organization when publishing draft standards that have little relevance to -the Web as it actually exists. -3. W3C sometimes confers unwarranted legitimacy to proposals that do not have buy-in from key stakeholders yet are published -as formal working drafts. +## Overview of a Proposed Solution -3. The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at determining key use cases and requirements, choosing between alternative approaches to standardization, and "polishing" solid -proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities. - - - -## Overview of a Solution - -To address these problems, W3C should more tightly focus its +W3C should more tightly focus its formal standardization effors on specifications that are most likely to get consensus within the consortium and be used on the real Web. This document proposes to do that by offering a short list of criteria to consider when evaluating proposals to move specification work to the Recommendation track. That includes drafting the Deliverables section of a WG charter, but especially when publishing a FPWD. @@ -46,12 +36,14 @@ Discussion at the [October 2015 Advisory Committee meeting](https://www.w3.org/2 indicated disparate opinions about whether to insist that proposed work should meet empirical criteria before being put on the Recommendation track. -Arguments in favor of mandatory incubation included: +Arguments raised in favor of mandatory incubation included: - The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers tend to create specs that don't get used in the real world. - Recommendation track documents that don't get implemented or widely used do not advance W3C's mission or enhance its reputation - The industry overall is moving toward more data-driven decision making - It's useful to identify *what* criteria are prerequisites for a Recommendation Track effort, but not to prescribe *how* those criteria are to be met. So incubation in a CG is just one way to meet the criteria, not the only way. + - The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at "polishing" solid proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities. + - The REC track sometimes confers unwarranted legitimacy to proposals that do not have buy-in from the stakeholders needed get it to Recommendation and deployed on the real Web. Arguments against focused on mandating using W3C Community Groups to incubate proposals until they met empirical criteria included: From f0a5d5346f48b81ff288ac12b7dc27f66d220d5e Mon Sep 17 00:00:00 2001 From: ianbjacobs Date: Tue, 10 May 2016 16:24:03 -0500 Subject: [PATCH 21/47] Link update to CG charter template --- bp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bp.md b/bp.md index 438cb86..d99c916 100644 --- a/bp.md +++ b/bp.md @@ -122,7 +122,7 @@ Group or another similar incubation phase. If work is incubated in a CG, it is important to assess the degree of consensus behind a spec as well as its maturity. While CG's are not required to work by consensus, those proposing work for the Recommendation track should favor proposals that -did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. An optional [W3C Community Group Charter Template](https://www.w3.org/community/council/wiki/Templates/CG_Charter) contains provisions designed to promote fairness in CGs. CGs are encouraged to consider using the template as a starting point. +did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. An optional [W3C Community Group Charter Template](https://github.com/w3c/cg-charter/blob/gh-pages/CGCharter.html) contains provisions designed to promote fairness in CGs. CGs are encouraged to consider using the template as a starting point. The key word is "matured", and the key milestone is First Public Working Draft (FPWD). It may be inefficient to charter WGs that start with a "blank sheet of paper" or multiple proposals with different use cases, but it hurts W3C's credibility to From 1664680b66f02ea6509ef44cf2c9520d4a989c86 Mon Sep 17 00:00:00 2001 From: ianbjacobs Date: Tue, 10 May 2016 16:27:59 -0500 Subject: [PATCH 22/47] Updated Team support for CGs There are new expectations about team support for some CGs; add a link to cg-support. Also added a link to the list of staff. --- bp.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/bp.md b/bp.md index d99c916..f9f1206 100644 --- a/bp.md +++ b/bp.md @@ -176,8 +176,8 @@ royalty-free terms? ### Team Engagement? It is advisable for groups considering Recommendation Track work to consult with the W3C Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal. -Working Groups and Interest Groups have Team Contacts they can use for this purpose. -Community Groups do not, but they are encouraged to reach out to the W3C staff well in advance of proposing a transition to the Recommendation Track. + +Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups generally do not (see [Team support for CGs](https://www.w3.org/2016/04/cg-support/), but CG participants are encouraged to reach out to the [W3C staff](http://www.w3.org/People/) well in advance of proposing a transition to the Recommendation Track. ##Process Considerations From aa6922bbcbaa731714c80cb4c9dac32e2297dc5e Mon Sep 17 00:00:00 2001 From: ianbjacobs Date: Tue, 10 May 2016 16:28:38 -0500 Subject: [PATCH 23/47] Editorial --- bp.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/bp.md b/bp.md index f9f1206..d3854d4 100644 --- a/bp.md +++ b/bp.md @@ -177,7 +177,7 @@ royalty-free terms? It is advisable for groups considering Recommendation Track work to consult with the W3C Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal. -Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups generally do not (see [Team support for CGs](https://www.w3.org/2016/04/cg-support/), but CG participants are encouraged to reach out to the [W3C staff](http://www.w3.org/People/) well in advance of proposing a transition to the Recommendation Track. +Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups generally do not (see [Team support for CGs](https://www.w3.org/2016/04/cg-support/)), but CG participants are encouraged to reach out to the [W3C staff](http://www.w3.org/People/) well in advance of proposing a transition to the Recommendation Track. ##Process Considerations From 0874047378310683ac7b4ebddf1aedd33846a155 Mon Sep 17 00:00:00 2001 From: Coralie Mercier Date: Fri, 26 Aug 2016 00:05:24 +0200 Subject: [PATCH 24/47] created index.html Created index.html to mirror content from GH on W3C Recommendation Track Readiness Best Practices --- index.html | 324 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 324 insertions(+) create mode 100644 index.html diff --git a/index.html b/index.html new file mode 100644 index 0000000..e62965c --- /dev/null +++ b/index.html @@ -0,0 +1,324 @@ + + + + + W3C Recommendation Track Readiness Best Practices + + + + + + + + + + + + + +
+

Also On This Page →

+ +
+
+

Nearby

+
    +
  • + @@ +
    • +
  • + @@ +
    • +
+
+
+

+ Status +

+

@@Intro statement@@

+

Comments or questions should be addressed to the W3C Communications Team at w3t-comm@w3.org.

+

+ Problem Statement +

+

The practices proposed in this document are intended to address some specific problems:

+

W3C wastes resources, and at worst tarnishes its credibility, when it invests in standardization efforts that end up going nowhere

+ +

+ Overview of the Proposed Solution +

+

W3C should more tightly focus its +formal standardization effors on specifications that are most likely to get consensus within the consortium +and be used on the real Web. This document proposes to do that by offering a short list of criteria to consider when evaluating proposals to move specification work +to the Recommendation track. That includes drafting the Deliverables section of a WG charter, but especially when publishing a FPWD.

+ +

These are offered as guidelines, not a checklist of required items in every proposal. +Meeting all the guidelines will not guarantee Director approval of the charter or FPWD, nor will failing to meet some block approval. The goal +of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by +WGs and judgment by the Director.

+ +

The target audience for this document includes:

+ +
    +
  • the Team and Director and Advisory Committee when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope (e.g. how specs reach maturation before FPWD), and in reviewing Proposed Recommendations;
    • +
  • working group Chairs determining whether to publish First Public Working Drafts of +specs that are in a group's chartered scope,
    • +
+ +

This document attempts to strike a balance between two classes of criteria:

+ +
    +
  • "aspirational" considerations such as whether the spec addresses an un-met need or expands the potential of the Web
    • +
  • "empirical" considerations such as whether drafts of the spec have momentum with implementers and early adopters
    • +
+ +

Discussion at the October 2015 Advisory Committee meeting +indicated disparate opinions about whether to insist that proposed work should meet empirical criteria before being +put on the Recommendation track.

+ +

Arguments raised in favor of mandatory incubation included:

+ +
    +
  • The "aspirational" approach often assumes that whatever a WG produces will be implemented, but WGs without a reality check from implementers tend to create specs that don't get used in the real world.
    • +
  • Recommendation track documents that don't get implemented or widely used do not advance W3C's mission or enhance its reputation
    • +
  • The industry overall is moving toward more data-driven decision making
    • +
  • It's useful to identify what criteria are prerequisites for a Recommendation Track effort, but not to prescribe how those +criteria are to be met. So incubation in a CG is just one way to meet the criteria, not the only way. + +
      +
    • The Working Groups Process is not well suited to innovation of new ideas; the formal consensus process is most effective at "polishing" solid proposals to make them more clear, specific, and useful across users with different languages, cultures, and abilities.
      • +
    • The REC track sometimes confers unwarranted legitimacy to proposals that do not have buy-in from the stakeholders needed get it to Recommendation and deployed on the real Web.
      • +
    • +
+ +

Arguments against focused on mandating using W3C Community Groups to incubate proposals until they +met empirical criteria included:

+ +
    +
  • Incubation isn't a silver bullet to be applied to every situation
    • +
  • If a CG incubates a spec that gets implemented in the browsers, it's hard to motivate proponents to take it to a WG for broad review
    • +
  • Requiring external incubation in a venue that doesn't require broad consensus +could lead to key technical decisions being made in forums dominated by a few, +with "level playing field" discussion beginning only when implementation momentum makes change difficult.
    • +
  • There may be gaps in the patent commitment if all spec contributors to the incubation don't join the WG
    • +
  • It may be valuable for W3C team to help develop one or more proposals in the incubation stage
    • +
+ +

The readiness criteria below outline best practices for finding an appropriate balance among these perspectives. +They encourage all involved in advancing work to the Recommendation track to gather more evidence to drive the decision and to think carefully +about how to interpret it. They do not mandate any one mode of gathering that evidence or an algorithm to assess it.

+ +

+ Readiness Criteria +

+ +

The criteria here are used to evaluate whether a technical specification development effort is +ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids RFC 2119 "MUST" and "SHOULD" terminology, and should not be a taken +as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are +noted as "strongly recommended", and, if not met, an explanation of why they don't apply in a particular situation would +facilitate the Director's decision. Different cases will involve different combinations of these factors. In determining whether to +approve moving work to the Recommendation track, the Director may consider +other factors not listed in this document as well.

+ +

Assessing whether proposed work is likely to fulfull the W3C mission to lead the web to its full potential +is the traditional criterion the Team and Director use to evaluate whether to start a working group or advance +a specification. While this is "aspirational", it requires +judgment that balances the future potential of the Web alongside the need for real developers to make the Web work in practice. +This document seeks to make the factors that go into this judgment +more explicit and generally applicable.

+ +

The "empirical" criteria are inspired largely by the experience of some open source browser projects +that use an intent to implement process +to build the case for shipping +a new feature. This document refines this approach to apply to Recommendation +Track transition decisions. +The Web Platform Incubator Community Group has adopted +something similar to determine when a spec under incubation is ready to propose to a +Working Group.

+ +

Is there a clear problem statement?

+ +

Strongly Recommended: The proposal identifies the real-world problem this work would address, and why existing solutions are inadequate.
+What are web developers forced to do without this feature being available in a standardized way? +What fraction of web sites, hybrid applications, data publishers, etc. are using a similar capability in a non-standardized way? +How would users benefit from this feature if standardized?

+ +

Are success criteria explicit?

+ +

Strongly Recommended: The proposal enumerates the types of products (browsers, servers, frameworks, applications...) would need to +support the spec for it to be +successful, and indicate what degree of critical mass would be needed.
+Is this spec serving a specialized community and only that community needs to implement and adopt it for it to be successful? +Or are there critical ecosystem dependencies, e.g. the spec must be deployed on both +the cloud/server and browser/client, +or must be supported both in products for producers and consumers of web content, to be really useful?

+ +

Is there a well-socialized proposal to address the problem?

+ +

Strongly Recommended: An initial draft of the technical specification has been written down and socialized in a community where potential users, web site / app +developer, framework/took developer, and core technology implementers are represented. +The state of community consensus around the initial draft should be documented: Did potential users and key implementers actively participate +in the discussion? Are there any indications that social or economic pressure was applied to suppress dissent? Did the discussion generate sustained expressions of opposition or unwillingness to implement / use / make patent +commitments from key stakeholders? If there are indications that consensus in a WG will be difficult to achieve, proposers are well advised +to make a persuasive case for how the proposed Recommendation Track work can be successful.

+ +

Has the proposed spec been incubated to reasonable maturity?

+ +

Strongly Recommended: Charters do not list specs as deliverables, and WGs do not publish FWPDs, until there is +rough consensus across stakeholders that the spec solves a real problem, is likely to be implemented, and is likely to +be used on the Web. This consensus could emerge from an incubation phase in WICG or another CG, or in a WG that has an established +culture of taking and vetting suggestions from its public mailing list.

+ +

The language in the +Web Platform WG charter describes a one community's practice:

+ +
+

The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community +Group or another similar incubation phase.

+
+ +

If work is incubated in a CG, it is important to assess the degree of consensus behind a spec as well as its maturity. +While CG's are not required to work by consensus, those proposing work for the Recommendation track should favor proposals that +did get strong and broad consensus during the incubation phase, and make W3C staff aware of points of contention, rival proposals, etc. An optional W3C Community Group Charter Template contains provisions designed to promote fairness in CGs. CGs are encouraged to consider using the template as a starting point.

+ +

The key word is "matured", and the key milestone is First Public Working Draft (FPWD). It may be inefficient to charter WGs that start with +a "blank sheet of paper" or multiple proposals with different use cases, but it hurts W3C's credibility to +publish a formal Technical Report that specifies a technology that does NOT meet clear user needs in a way that has a good chance to be implemented in products, tools, websites, +and web applications. However the incubation phase is done, and whichever of these criteria are applied before proposing standardization +or developing a charter,this document strongly recommends that only "mature" specs be published as FPWDs.

+ +

Is it clear the proposers are not seeking a rubber stamp from W3C?

+ +

Strongly Recommended: Proposers of Recommendation-track work should be prepared for the Working Group to +make substantive changes to the initial draft in response to feedback. A W3C Recommendation signifies that a specification has broad consensus across the membership of W3C. It is particularly important to ensure that a spec both serves a real mainstream need +and is inclusive of a diverse, worldwide community using different languages, with various levels of ability, and +who interact with various levels of trust. Likewise, proposed Recommendation-track work should not promote + +

Are there appropriate expressions of interest?

+ +

The proposal points to statements of support from key stakeholders about the value proposition for the feature +it describes. Is there strong demand from potential users? Is there a critical mass of implementers tentatively interested in shipping this feature +if standardized? Are there prototype / polyfill implementations that are used in experimental apps / sites +that the target audience already finds useful?

+ +

Is there actual evidence to back up the answers?

+ +

The proposal describes what implementation and user experience is there to back up the points above. +What fraction of websites are implementing a similar feature in a non-standardized way? +How many users would potentially benefit from this feature if standardized? +Hard data is preferred, but estimates backed up by detailed explanations are acceptable.

+ +

Risks?

+ +

The proposal considers whether standardizing the spec could create more problems than it solves. +What are the potential downsides of having this feature standardized ...could it undermine security, privacy, accessibility, etc. +if broadly deployed? Are there scenarios under which we would regret standardizing this feature?

+ +

Is the timing right?

+ +

The optimal timing for a transition to the Recommendation Track can be described as:

+ +
    +
  • NO SOONER than the bulk of the criteria above are met.
    • +
  • NO LATER THAN a point where the spec is still fluid, and not frozen into shipping code used on many websites.
    • +
+ +

If the answer “the ship has sailed”, proposers should explain how they propose to mitigate the situation without turning back the clock, +and what a Recommendation Track document could do to improve the situation. For example, clearly documenting what already interoperates, +and getting broader patent commitments on the interoperable behavior arguably has value.

+ +

Clear RF licensing commitments?

+ +

W3C seeks to issue Recommendations that can be implemented and used on a +Royalty-Free basis.

+
    +
  1. Are the technologies in the initial available under terms that are compatible with the +W3C Royalty-Free licensing requirements?
    2. +
  2. Have those who seem most likely to have relevant patents made commitments to license them on +royalty-free terms?
    3. +
  3. Is the provenance of substantive contributions to the draft reasonably clear?
    4. +
+ +

Team Engagement?

+ +

It is advisable for groups considering Recommendation Track work to consult with the W3C +Team early enough in the process for them to advise about potential problems and workarounds, and help draft a formal proposal.

+ +

Working Groups and Interest Groups have Team Contacts they can use for this purpose. Community Groups generally do not (see Team support for CGs), but CG participants are encouraged to reach out to the W3C staff well in advance of proposing a transition to the Recommendation Track.

+ + +

+ Process Considerations +

+ +

Discussion about these guidelines has generated a number of questions about how they relate to the W3C process and the Team's existing practices.
+They are out of scope for this document, but they are listed for reference:

+ +

Granularity

+ +

Should the considerations above be applied at at the specification level or the feature level?

+ +

Charter Scopes and Deliverables

+ +

When chartering a new WG, is it appropriate to put in scope a number of features that are mostly "aspirational" and put in the deliverables +section only those that meet most of the criteria above?

+ +

When an incubator spec is ready to move to a WG, does it wait (possibly a couple of years) +to get into a WG Charter or are is the expectation that WGs would re-charter to take on incubated spec proposals?

+ +

Or is the best practice to make the scope of charters broad enough to encompass work that may be incubated during +the charter's lifetime, and the WG would only take up an actual deliverable once it is incubated?

+ +

Community Groups and the W3C Process

+ +

How can we ensure that concerns raised at the TPAC 2015 AC meeting and the AC Forum thread on Mandatory Incubation are addressed +in the process or practice of W3C?

+ +

Should the Process Document describe a role for CGs in getting specifications ready to be standardized? Should the Community +and Business Group Process say more about the importance of working by consensus, at least for specifications that +are to be proposed for the Recommendation Track?

+ +

What to do when there is interest from users but not implementers?

+ +

Raised in the AC discussions.
+Should the Process Document do more to describe a role for Interest Groups in developing use cases for new Recommendations, +and perhaps working in tandem with one or more Community Groups to develop credible technical proposals to address those +use cases?

+ +

+ Conclusion +

+ +

The criteria above suggest that Recommendation Track work begin when there are satisfactory answers to 3 basic questions:

+ +
    +
  • Does the work address a real un-met need or missed opportunity for the Web?
    • +
  • Does the work start from a concrete proposal that has been socialized with key stakeholders but doesn't discriminate against others?
    • +
  • Does standardizing the proposed spec have clear support from those who would need to implement and use the spec for it to be successful?
    • +
+ +
+
+
Coralie Mercier for the Communications Team - Send comments and suggestions to w3t-comm@w3.org
+$Id: Overview.html,v 1.5 2016/05/04 22:07:06 coralie Exp $
+ + From 9eb182c76f82d34afe8ba35b482f511774076bdb Mon Sep 17 00:00:00 2001 From: Coralie Mercier Date: Fri, 26 Aug 2016 01:04:15 +0200 Subject: [PATCH 25/47] Update index.html Removed "$Id: Overview.html,v 1.5 2016/05/04 22:07:06 coralie Exp $" --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index e62965c..cf2fa6e 100644 --- a/index.html +++ b/index.html @@ -319,6 +319,6 @@

Coralie Mercier for the Communications Team - Send comments and suggestions to w3t-comm@w3.org
-$Id: Overview.html,v 1.5 2016/05/04 22:07:06 coralie Exp $
+ From 7f5785df2b302a80b3b2f1464a17395121e2b9da Mon Sep 17 00:00:00 2001 From: Coralie Mercier Date: Tue, 30 Aug 2016 11:39:31 +0200 Subject: [PATCH 26/47] link to github doc in status link to github doc in status --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index cf2fa6e..d03ec82 100644 --- a/index.html +++ b/index.html @@ -56,7 +56,7 @@

Status

@@Intro statement@@

-

Comments or questions should be addressed to the W3C Communications Team at w3t-comm@w3.org.

+

This document lives in Github, where changes can be tracked and pull requests are welcome. Comments or questions should be addressed to the W3C Communications Team at w3t-comm@w3.org.

Problem Statement

From 2345f5cc6272f1f56065b8a45b1c8ffeaf0e638a Mon Sep 17 00:00:00 2001 From: Coralie Mercier Date: Thu, 22 Sep 2016 14:49:41 +0100 Subject: [PATCH 27/47] status fleshed out status fleshed out --- index.html | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index d03ec82..591babb 100644 --- a/index.html +++ b/index.html @@ -44,18 +44,16 @@

Also On This Page →

Nearby

Status

-

@@Intro statement@@

+

This document was developed by a task force of the W3C Advisory Board, socialised to the W3C Advisory Committee and W3C Team.

This document lives in Github, where changes can be tracked and pull requests are welcome. Comments or questions should be addressed to the W3C Communications Team at w3t-comm@w3.org.

Problem Statement From 24e8609e80d7907cba9a404895387b04b47db5f1 Mon Sep 17 00:00:00 2001 From: Coralie Mercier Date: Thu, 22 Sep 2016 14:51:16 +0100 Subject: [PATCH 28/47] Update index.html added month and year to status --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 591babb..5530021 100644 --- a/index.html +++ b/index.html @@ -53,7 +53,7 @@

Nearby

Status

-

This document was developed by a task force of the W3C Advisory Board, socialised to the W3C Advisory Committee and W3C Team.

+

August 2016: This document was developed by a task force of the W3C Advisory Board, socialised to the W3C Advisory Committee and W3C Team.

This document lives in Github, where changes can be tracked and pull requests are welcome. Comments or questions should be addressed to the W3C Communications Team at w3t-comm@w3.org.

Problem Statement From 53b2ce4a5651a92eedab6b041c9b20dd2d73d078 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 18 Oct 2016 17:53:59 -0400 Subject: [PATCH 29/47] Initial draft for different modification paths --- stages.md | 95 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 95 insertions(+) create mode 100644 stages.md diff --git a/stages.md b/stages.md new file mode 100644 index 0000000..d8c528c --- /dev/null +++ b/stages.md @@ -0,0 +1,95 @@ +# Maintenance and Incubation + +## Status + +This is a proposal intended to facilitate maintenance of W3C Recommendations at W3C. + +## Problem Statement + +The W3C Technical Reports page contain a long list of W3C Recommendations that are not maintained properly, due to lack of editors, participants, or Working Groups. + +## Classes of Changes + +[Process 2016](https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#correction-classes) contains the following classes of changes: + +1. No changes to text content +2. Corrections that do not affect conformance +3. Corrections that do not add new features +4. New features + +We will refer to these classes in the different types of modifications below. + +## 7 Types of modifications + +We identify here 7 different types of modifications applicable to a W3C specification and the existing and recommended path to address them. + +All types of modifications, except for in-place modifications, will result in a new dated version of the W3C Recommendation. + +### 0. In-place modification of W3C Technical Reports + +There is a policy regarding the [in-place modification](https://www.w3.org/2003/01/republishing/) of W3C Recommendations. It allows the following types of modifications: + +1. Fixes to broken markup (e.g., invalid markup) (category 1) +2. Fixed to broken links (i.e., URIs) +3. Fixes to broken style sheets +4. Some visible status updates, such as indicating newer versions +5. An [individual's name upon request to a W3C Ombudsperson](https://www.w3.org/2016/02/trans-rec-edit.html) + +Except for those changes required by this [policy in section four](https://www.w3.org/2003/01/republishing/), no in-place changes to the text of a document, besides some visible status updates, are permitted, however minor. + +All those types of modifications are classified under the [Class of Change 1 and 2](https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#correction-classes), per Process 2016. + +Since the modifications are in-place, this will not result in a new dated version of a W3C Recommendation. + + +### 1. Editorial modifications + +Those modifications are classified under the [Class of Change 1 and 2](https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#correction-classes), per Process 2016 and cannot be done as an in-place modification. + +Editorial changes to a Recommendation require no technical review of the proposed changes and do not need to be part of an errata page initially. This will result in an Edited Recommendation, at the request of a W3C Working Group or done directly by W3C. + +### 2. Maintenance of an errata page for the W3C Recommendation + +Each W3C Recommendation contains a link to an errata page. This page is best maintained by the corresponding Working Group. If no such Working Group exists, the W3C is responsible for maintaining the errata page and may need assistance in doing so, such as requesting the help of a Community Group. + +All those types of errata are classified under the [Class of Change 1, 2, and 3](https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#correction-classes), per Process 2016. + +This will not result in an Edited Recommendation. + +Note: this diverges from Process 2016, where only Working Groups are allowed to decide how to document errata. + +### 3. Revising a Recommendation using an errata list + +A list of errata becomes part of a W3C Recommendation by the process for revising a Recommendation. To make corrections to a W3C Recommendation, a Working Group may request publication of a Candidate Recommendation. If no such Working Group exists, the W3C is responsible for requesting the publication of a Candidate Recommendation. If this is done at the request of W3C instead of a Working Group, the status should indicate that the substantive changes are NOT covered by the W3C Patent Policy. This is an acceptable trade-off between having a broken Recommendation with full patent policy coverage and a well-maintained Recommendation without RF commitments. However, the [disclosure requirement](https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-disclosure-requirements) still applies. + +All those types of errata are classified under the [Class of Change 1, 2, and 3](https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#correction-classes), per Process 2016. + +This will result in an Edited Recommendation, at the request of a W3C Working Group or done directly by W3C. + +Note: this diverges from Process 2016, where only Working Groups are allowed to request substantive corrections to a W3C Recommendation. + +### 4. New features that were previously classified "at risk" + +Working Groups may identify features in a document as "at risk". These features may be removed before advancement to Proposed Recommendation without a requirement to publish a new Candidate Recommendation, per [Process 2016](https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#candidate-rec). + +Such feature should stay within the scope of the Working Group and may be reincorporated in a future version of the W3C Recommendation. + +These features are classified under the [Class of Change 4](https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#correction-classes), per Process 2016. + +This will result in a new Recommendation, at the request of a W3C Working Group. + +### 5. New features under discussion but not included + +Working Groups may identify new features while working on a document but not have enough time to include them as part of the specification. + +Such discussion/feature should stay within the scope of the Working Group and may be incorporated in a future version of the W3C Recommendation. + +These features are classified under the [Class of Change 4](https://dvcs.w3.org/hg/AB/raw-file/default/cover.html#correction-classes), per Process 2016. + +This will result in a new Recommendation, at the request of a W3C Working Group. + +@@need example + +6. Brand new feature + +Those features were not listed or discussed sufficiently while working on the specification. As such, those should be incubated in a Community Group first. From 948a5fcd162d953e4415058efe73eaccc96200b5 Mon Sep 17 00:00:00 2001 From: Coralie Mercier Date: Wed, 9 Nov 2016 10:22:53 +0100 Subject: [PATCH 30/47] html5 markup --- index.html | 34 ++++++++++++++++------------------ 1 file changed, 16 insertions(+), 18 deletions(-) diff --git a/index.html b/index.html index 5530021..06f70ac 100644 --- a/index.html +++ b/index.html @@ -1,28 +1,26 @@ - - + + - + W3C Recommendation Track Readiness Best Practices - - - - - - - - - + + + + + + + + +
From b6010d1fd81c657c17a7c5186ea3a37d364145a1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tantek=20=C3=87elik?= Date: Sun, 11 Dec 2016 21:32:35 -0800 Subject: [PATCH 33/47] fix typo --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index e48a4cc..8d8f1ac 100644 --- a/index.html +++ b/index.html @@ -72,7 +72,7 @@

These are offered as guidelines, not a checklist of required items in every proposal. Meeting all the guidelines will not guarantee Director approval of the charter or FPWD, nor will failing to meet some block approval. The goal -of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by +of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovation by WGs and judgment by the Director.

The target audience for this document includes:

From f771d9bfa0e63a8cf743c4906836c1fd48733fcb Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 15 Sep 2020 14:14:48 -0400 Subject: [PATCH 34/47] Link to latest patent policy --- index.html | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/index.html b/index.html index e48a4cc..0457d64 100644 --- a/index.html +++ b/index.html @@ -247,12 +247,12 @@

Is the timing right?

Clear RF licensing commitments?

-

W3C seeks to issue Recommendations that can be implemented and used on a -Royalty-Free basis.

+

W3C seeks to issue Recommendations that can be implemented and used on a +Royalty-Free basis.

    -
  1. Are the technologies in the initial available under terms that are compatible with the -W3C Royalty-Free licensing requirements?
    2. -
  2. Have those who seem most likely to have relevant patents made commitments to license them on +
  3. Are the technologies in the initial available under terms that are compatible with the +W3C Royalty-Free licensing requirements?
    4. +
  4. Have those who seem most likely to have relevant patents made commitments to license them on royalty-free terms?
  5. Is the provenance of substantive contributions to the draft reasonably clear?
From 8be33191e5fc9815cf0146615eea09982fcfed61 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 15 Sep 2020 14:16:32 -0400 Subject: [PATCH 35/47] Fixed borken url fragment --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 0457d64..97f6fe5 100644 --- a/index.html +++ b/index.html @@ -248,7 +248,7 @@

Is the timing right?

Clear RF licensing commitments?

W3C seeks to issue Recommendations that can be implemented and used on a -Royalty-Free basis.

+Royalty-Free basis.

  1. Are the technologies in the initial available under terms that are compatible with the W3C Royalty-Free licensing requirements?
    2. From cab895de310c8acd8054d90af569bc14c6083d28 Mon Sep 17 00:00:00 2001 From: Chris Lilley Date: Mon, 23 Oct 2023 09:30:29 -0400 Subject: [PATCH 36/47] This Guide page no longer Member-only, use Participate instead --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 97f6fe5..0c7b224 100644 --- a/index.html +++ b/index.html @@ -23,7 +23,7 @@ W3C -
    Member → The Art of Consensus → +
    Participate → The Art of Consensus →

    W3C Recommendation Track Readiness Best Practices

    This Guidebook is the collected wisdom of the W3C Group Chairs and other collaborators.

    From b54b657ac86dab3a3dab19de9d045a6861696857 Mon Sep 17 00:00:00 2001 From: Chris Lilley Date: Mon, 23 Oct 2023 09:59:06 -0400 Subject: [PATCH 37/47] Define goals of this revision --- index.html | 1 + 1 file changed, 1 insertion(+) diff --git a/index.html b/index.html index 0c7b224..0f58446 100644 --- a/index.html +++ b/index.html @@ -53,6 +53,7 @@

    Nearby

    Status

    +

    October 2023: Document updated to account for changes in Process 2023, in particular the Director-free changes.

    August 2016: This document was developed by a task force of the W3C Advisory Board, socialised to the W3C Advisory Committee and W3C Team.

    This document lives in Github, where changes can be tracked and pull requests are welcome. Feedback and comments are welcome. Please use Github issues.

    From 6be834613c99e3be1fd826087dc7d339c8e5da50 Mon Sep 17 00:00:00 2001 From: Chris Lilley Date: Mon, 23 Oct 2023 10:15:16 -0400 Subject: [PATCH 38/47] charter approval is a W3C Decision --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 0f58446..622645e 100644 --- a/index.html +++ b/index.html @@ -72,9 +72,9 @@

    to the Recommendation track. That includes drafting the Deliverables section of a WG charter, but especially when publishing a FPWD.

    These are offered as guidelines, not a checklist of required items in every proposal. -Meeting all the guidelines will not guarantee Director approval of the charter or FPWD, nor will failing to meet some block approval. The goal +Meeting all the guidelines will not guarantee the W3C decision for approval of the charter, or advancement to FPWD, nor will failing to meet some block approval. The goal of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by -WGs and judgment by the Director.

    +WGs and determination of W3C Decisions.

    The target audience for this document includes:

    From 1755e1a942f3aacbd42d9478cdf74c89df212452 Mon Sep 17 00:00:00 2001 From: Chris Lilley Date: Mon, 23 Oct 2023 10:20:04 -0400 Subject: [PATCH 39/47] Director is no longer part of the target audience --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index 622645e..6c8a630 100644 --- a/index.html +++ b/index.html @@ -79,8 +79,8 @@

    The target audience for this document includes:

      -
    • the Team and Director and Advisory Committee when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope (e.g. how specs reach maturation before FPWD), and in reviewing Proposed Recommendations;
      • -
    • working group Chairs determining whether to publish First Public Working Drafts of +
    • the Team and Advisory Committee, when evaluating proposals to create new Working Groups or rechartering existing Working Groups to put new work in scope (e.g. how specs reach maturation before FPWD), and in reviewing Proposed Recommendations;
      • +
    • working group Chairs, when determining whether to publish First Public Working Drafts of specs that are in a group's chartered scope,
    From fbe64bef7d4a773081cd7b694b9a3647207da637 Mon Sep 17 00:00:00 2001 From: Chris Lilley Date: Mon, 23 Oct 2023 10:23:49 -0400 Subject: [PATCH 40/47] W3C Decision to start a WG --- index.html | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/index.html b/index.html index 6c8a630..d98be49 100644 --- a/index.html +++ b/index.html @@ -135,12 +135,12 @@

    ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids RFC 2119 "MUST" and "SHOULD" terminology, and should not be a taken as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are noted as "strongly recommended", and, if not met, an explanation of why they don't apply in a particular situation would -facilitate the Director's decision. Different cases will involve different combinations of these factors. In determining whether to -approve moving work to the Recommendation track, the Director may consider +facilitate the W3C decision. Different cases will involve different combinations of these factors. In determining whether to +approve moving work to the Recommendation track, the Team may consider other factors not listed in this document as well.

    Assessing whether proposed work is likely to fulfull the W3C mission to lead the web to its full potential -is the traditional criterion the Team and Director use to evaluate whether to start a working group or advance +is the traditional criterion the Team and Advisory Committee use to evaluate whether to start a working group or advance a specification. While this is "aspirational", it requires judgment that balances the future potential of the Web alongside the need for real developers to make the Web work in practice. This document seeks to make the factors that go into this judgment From 04835999cb2a71a8f72c461d62e70fa2bb1aa817 Mon Sep 17 00:00:00 2001 From: Chris Lilley Date: Mon, 23 Oct 2023 11:45:15 -0400 Subject: [PATCH 41/47] Update index.html Co-authored-by: Philippe Le Hegaret --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 2ef8a76..6ca4182 100644 --- a/index.html +++ b/index.html @@ -73,7 +73,7 @@

    These are offered as guidelines, not a checklist of required items in every proposal. -Meeting all the guidelines will not guarantee the W3C decision for approval of the charter, or advancement to FPWD, nor will failing to meet some block approval. The goal +Meeting all the guidelines will not guarantee the W3C decision for approval of the charter, or advancement to FPWD, nor will failing to meet some block approval. The goal of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by WGs and determination of W3C Decisions.

    From 220e7c57f57c4fd293e0ffaeb84241c5fa61a33b Mon Sep 17 00:00:00 2001 From: Chris Lilley Date: Mon, 23 Oct 2023 11:45:26 -0400 Subject: [PATCH 42/47] Update index.html Co-authored-by: Philippe Le Hegaret --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 6ca4182..033cb5f 100644 --- a/index.html +++ b/index.html @@ -137,7 +137,7 @@

    ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids RFC 2119 "MUST" and "SHOULD" terminology, and should not be a taken as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are noted as "strongly recommended", and, if not met, an explanation of why they don't apply in a particular situation would -facilitate the W3C decision. Different cases will involve different combinations of these factors. In determining whether to +facilitate the W3C decision. Different cases will involve different combinations of these factors. In determining whether to approve moving work to the Recommendation track, the Team may consider other factors not listed in this document as well.

    From 7c66f79f44bbde05fc7e639a63de8526b6143feb Mon Sep 17 00:00:00 2001 From: Chris Lilley Date: Mon, 23 Oct 2023 12:35:19 -0400 Subject: [PATCH 43/47] Update index.html Co-authored-by: Philippe Le Hegaret --- index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/index.html b/index.html index 033cb5f..c060227 100644 --- a/index.html +++ b/index.html @@ -73,7 +73,7 @@

    These are offered as guidelines, not a checklist of required items in every proposal. -Meeting all the guidelines will not guarantee the W3C decision for approval of the charter, or advancement to FPWD, nor will failing to meet some block approval. The goal +Meeting all the guidelines will not guarantee the W3C decision for approval of the charter, or advancement to FPWD, nor will failing to meet some block approval. The goal of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by WGs and determination of W3C Decisions.

    From 7c502f67d306bc59d6415b312cfcab43497a1128 Mon Sep 17 00:00:00 2001 From: plehegar Date: Thu, 26 Oct 2023 15:24:32 -0400 Subject: [PATCH 44/47] Stop using guide2006.css --- index.html | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/index.html b/index.html index c060227..aaa5b50 100644 --- a/index.html +++ b/index.html @@ -4,11 +4,10 @@ W3C Recommendation Track Readiness Best Practices - + - From 4af91e8aee1d32502016626434a47d4525bd2780 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 25 Jun 2024 16:58:03 -0400 Subject: [PATCH 45/47] Updates process links --- index.html | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/index.html b/index.html index aaa5b50..cc3314c 100644 --- a/index.html +++ b/index.html @@ -72,7 +72,7 @@

    These are offered as guidelines, not a checklist of required items in every proposal. -Meeting all the guidelines will not guarantee the W3C decision for approval of the charter, or advancement to FPWD, nor will failing to meet some block approval. The goal +Meeting all the guidelines will not guarantee the W3C decision for approval of the charter, or advancement to FPWD, nor will failing to meet some block approval. The goal of this effort is to add more structure and predictability to Rec track decisions while allowing plenty of room for innovtion by WGs and determination of W3C Decisions.

    @@ -136,7 +136,7 @@

    ready for the W3C Recommendation Track. No single factor is decisive, and this document avoids RFC 2119 "MUST" and "SHOULD" terminology, and should not be a taken as a checklist of necessary or sufficient criteria. Nevertheless, some criteria are noted as "strongly recommended", and, if not met, an explanation of why they don't apply in a particular situation would -facilitate the W3C decision. Different cases will involve different combinations of these factors. In determining whether to +facilitate the W3C decision. Different cases will involve different combinations of these factors. In determining whether to approve moving work to the Recommendation track, the Team may consider other factors not listed in this document as well.

    From b24e1fcab1ed92bea6cf91e33679de5e3f318852 Mon Sep 17 00:00:00 2001 From: plehegar Date: Tue, 25 Jun 2024 17:04:08 -0400 Subject: [PATCH 46/47] Fixes https://github.com/w3c/Guide/issues/237 --- index.html | 7 +++---- stages.md | 22 +++++++++++----------- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/index.html b/index.html index cc3314c..850f085 100644 --- a/index.html +++ b/index.html @@ -8,7 +8,6 @@ -