-
Notifications
You must be signed in to change notification settings - Fork 1
/
fantasai.txt
50 lines (29 loc) · 7.63 KB
/
fantasai.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
Hi! This is fantasai. Florian and I are going to talk today a bit about the W3C Process proposal for 2020.
For those of you who don't know, the Process is the governing document for the standardization activities at W3C. The proposed update for 2020 represents some of the biggest changes to the Process in many years. The purpose of this presentation is to help you, the AC, understand the motivation behind these changes as well as the nature of the proposed changes themselves. The Process 2020 proposal is currently under informal review in the AC, so please study the materials and send us your questions and comments for consideration. We will be putting the revised Process forward for formal ratification by the AC after this comment period ends on May 31st.
[slide 3]
Specifications go through initial periods of development and evolution, and as they stabilize, gradually transition to maintenance. W3C’s Process currently has deficiencies in both phases.
For the development aspect, one major problem is that the current Process cannot easily represent the continuous model under which many software engineering teams now operate. Forking the specification into snapshot Recommendations that represent an arbitrary set of features passing implementation requirements at a given point in time is busy-work to such engineers, and the proliferation of copies increases the risk that the rest of the material gets out-of-sync with bugfixes.
Compounding this, for the maintenance aspect, every change to a Recommendation requires a lot of Process machinery that affects the status of the entire specification. Folding a single bugfix into a Recommendation requires three changes in maturity level and corresponding manual publications and communication efforts for the W3C staff; and by changing the status of the entire spec, it creates confusion about the maturity of the specification to its users.
[slide 4]
It is evident that the current W3C Process is not working as well as it ought to. We can see this in the number of out-of-date and unmaintained specifications, and in the way that work is shifting out of W3C Working Groups to other forums. Some projects have shifted out of W3C entirely, others are not formally adopted in a Working Group until implementations have already shipped, too late for significant feedback to be taken into account. And in many groups where work is still happening at W3C, the official specifications we publish on W3C’s own website are years out-of-date, with the active versions published elsewhere. This creates confusion regarding which publication implementers and reviewers should reference, and results in interoperability problems.
Clearly, we need to fix the Process. But in so doing, we want to also make sure we don't lose the qualities that make it valuable in the first place.
[slide 5]
W3C’s goal is to develop well thought-out, implementable, and relevant specifications. We value wide review, implementation experience, consensus, and royalty-free licensing as the means to that end. The role of the Process, ultimately, is to ensure that these values are deeply incorporated into W3C’s standards development practice; it exists for no other reason than to provide a repeatable framework for this.
It’s also important to note that the W3C community is very diverse. The Process needs to accommodate a wide variety of companies and industries, and to solicit excellence from both experienced standards experts in well-established Working Groups, as well as new participants and communities freshly started. To be a consistent, supportive framework, the Process needs both flexibility, and also formal structure. We can’t continue to demand that Working Groups conform to a process that does not suit their operational reality. But we also can’t just eliminate all formalism in favor of informal cultural expectations and expect that to work.
As Tim Berners-Lee likes to say, the Process is a tool. If it's not useful, it needs to be adjusted. So in 2020, we are going to adjust the Process.
[slide 6]
Our goals in adjusting this tool are:
- to allow continuous development of specifications so that they can evolve in sync with their respective implementations
- to simplify maintenance of existing and future W3C Recommendations
- to secure patent commitments to protect the pioneering implementations who fulfill our requirements for implementation experience (as well as those that come after)
- to reduce unnecessary bureaucratic overhead
- to continue the W3C commitment to wide review and consensus
[slide 7]
To implement these goals, we adopted the following design principles:
First, the normative content of a W3C Recommendation must continue to fulfill the same requirements as currently. We are not proposing to reduce the value proposition of a Recommendation. It must still satisfy the existing requirements for wide review, AC review, implementation experience, and Director’s approval.
Second, we resolved to make improvements to W3C's existing Recommendation Track for normative specifications, not to create a parallel track fulfilling the same purpose but under different process requirements and procedures.
Third, we want to enable Working Groups to consistently maintain their intended implementation target as their officially published specification on w3.org, such that off-site Editor's Drafts are no longer needed in a public-facing role. If we do not enable this in practical terms, we have failed as a standards organization: our purpose is to publish relevant standards, if what we publish on our own website is not relevant, what are we even doing?
Fourth, we want to make sure that “wide review” as required in the Process invites the participation of the broader community, not just internal experts. Many people refer to review by horizontal working groups such as Internationalization and the TAG as “wide review”; but this is only *part of* wide review. Wide review also includes the broader public; that is why W3C has always published it's work in progress for free on the Web. If relevant review materials are only ever available in the depths of a GitHub repository, they are effectively hidden, and will not receive a truly wide review. Therefore Process 2020 attempts to ensure that new material can be published *for* wide review, not just after “wide review”.
Fifth, we want to bring patent protection to early implementations and for continuously-developed specifications. Many W3C specs describe complex technology in extreme detail, and the refinement of these details takes place in the Candidate Recommendation phase, during which we invite implementations to help us figure them out and to prove the quality of the spec. We want these implementations to have the same protections as the later implementations that come after a specification has been ratified as a Recommendation.
Lastly, we intend to improve on the existing Process, not to rewrite one from scratch. The W3C Process has served us well in many ways for over a quarter century; we don't want to lose the positive aspects of the existing Process we have in order to fix its deficiencies. Reforming the Process rather than replacing it reduces the risk of regressions, and also makes the transition to the new Process much easier. Every change we propose here is additive and independent: Process 2020 reduces the friction in many procedures and makes some new things possible, but existing ways of working will remain valid.
I hope this helps you understand why the Process and the Patent Policy need to change, and why we are proposing the specific changes that we are. And now I will hand off to my indefatigable co-editor, Florian Rivoal, to explain the changes in this package of reforms.