Coder Social home page Coder Social logo

w3process's Introduction

W3C Process Document repository

This repository is for the editor's draft of the World Wide Web Consortium Process Document.

The Process document is updated most years by the W3C. Discussion happens in the context of the W3C Process Community Group https://www.w3.org/community/w3process/, mostly in this Github repository, but also on the archived public mailing list.


Branches under development

main branch (current draft of the CG): Preview


Useful searches

PRs triaged into P2021 which are not priorities.


Bikeshed

This document is maintained using Bikeshed. See the section about markup in Bikeshed's documentation for full details about the syntax.

Only the source (index.bs) should be committed, as this repository is configured to run bikeshed server-side and push the result to the gh-pages branch.

To run Bikeshed locally, Follow the instructions in Bikeshed's documentation. Once Bikeshed is installed, just type bikeshed to compile the document.


Setting up Branches

To set up long-lived topic branches which get built server side and published to github.io, follow these steps:

  1. On the main branch edit deploy.sh to add the name of your topic branch to the TOPIC_BRANCHES array. Example:

    TOPIC_BRANCHES=("topic1" "topic2" "topic3")
  2. (Optional Step) Edit the README.md file to line for your topic branch. See the "Branches under development" section and use existing branches as a model.

  3. Commit the change(s) above, and push to github.com/w3c/w3process (not your personal fork). Example:

    git add deploy.sh README.md
    git commit -m "Register topic branch for topic3"
    git push upstream main
  4. Create a new branch from the main branch (after the previous commit), using the same name as the one you used in the TOPIC_BRANCHES array, and push it to github.com/w3process (not your personal fork). Example:

    git checkout -b topic3
    git push upstream topic3

w3process's People

Contributors

chaals avatar chrisn avatar cwilso avatar daniel-montalvo avatar dbaron avatar deniak avatar dwsinger avatar fantasai avatar frivoal avatar himorin avatar iherman avatar jyasskin avatar koalie avatar kpfleming avatar ljwatson avatar nigelmegitt avatar nrooney avatar plehegar avatar swickr avatar tabatkins avatar tallted avatar tantek avatar tidoust avatar tripu avatar vivienlacourba avatar w3cgruntbot avatar wseltzer avatar xfq avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

w3process's Issues

Updates to sections 5.2.2 and 2.1.3.1

This is related to #38 and #39 and is intended to reflect what has been done in practice since announcement in December 2014, namely, that AC reviews (of charters, Proposed Recommendations) have had the option to be "Public and send email to both w3c-ac-forum and public-new-work".

Proposed changes in bold:

5.2.2 Working Group and Interest Group Charter Development

W3C creates a charter based on interest from the Members and Team. The Team must notify the Advisory Committee when a charter for a new Working Group or Interest Group is in development. This is intended to raise awareness, even if no formal proposal is yet available. Advisory Committee representatives may provide feedback on the Advisory Committee discussion list and make their review public.

2.1.3.1 Advisory Committee Mailing Lists

The Team must provide two mailing lists for use by the Advisory Committee:

  1. One for official announcements (e.g., those required by this document) from the Team to the Advisory Committee. This list is read-only for Advisory Committee representatives.
  2. One for discussion among Advisory Committee representatives. Though this list is primarily for Advisory Committee representatives, the Team must monitor discussion and should participate in discussion when appropriate. Ongoing detailed discussions should be moved to other appropriate lists (new or existing, such as a mailing list created for a Workshop).

An Advisory Committee representative may request that additional individuals from their organization be subscribed to these lists. Failure to contain distribution internally may result in suspension of additional email addresses, at the discretion of the Team.

In addition, the Advisory Committee may share reviews of charters, Proposed Recommendations
on a public mail archive.

For those who refer to the Process Document, it would be useful to point to https://lists.w3.org/Archives/Public/public-new-work/ but I see that the mail archives for w3c-ac-members and w3c-ac-forum are not part of the process itself.

can the AB/TAG chair ask for a special election in *advance* of a known upcoming vacancy?

Section 2.5.3 Advisory Board and Technical Architecture Group Vacated Seats says:

When an elected seat on either the AB or TAG is vacated, the seat is filled at the next regularly scheduled election for the group unless the group Chair requests that W3C hold an election before then (for instance, due to the group's workload). The group Chair should not request an exceptional election if the next regularly scheduled election is fewer than three months away.

It seems to me that, since some vacancies are known in advance of when they occur, it ought to be possible for the Chair to ask for the election when an upcoming vacancy is known even if the seat is not yet vacant (much like regular elections are held before the terms expire), so that the vacant seat can be filled from the result of a special election more quickly.

It's not clear to me whether the above text allows this. I tend to think it should be clarified so that it does allow it.

Do we need a superseded status for older specs?

We have some older recommendations that are still published as they are important references (e.g. HTML 3, 4). The technology in them has been wholly subsumed by later versions, and we no longer want to maintain them actively. Do we need a process to mark them as superseded?

Definition of obsolete

The first sentence of the definition of an obsolete specification is difficult to read:

"An Obsolete Recommendation is a specification that W3C does not believe has sufficient market relevance to continue recommending that the community implement it, but does not consider that there are fundamental problems that require the Recommendation be Rescinded.">

Could it be simplified? Perhaps:

"An obsolete Recommendation is a specification that the W3C believes no longer has enough market relevance to continue recommending it for implementation, but does not have fundamental problems that would require it to be rescinded.">

What should be the effect of voting for No Other Candidate

Section 2.5.2 of the Process Document https://www.w3.org/2017/Process-20170301/ states:
"The Advisory Board and a portion of the Technical Architecture Group are elected by the Advisory Committee, using a Single Transferable Vote system. An election begins when the Team sends a Call for Nominations to the Advisory Committee. Any Call for Nominations specifies the number of available seats, the deadline for nominations, details about the specific vote tabulation system selected by the Team for the election, and operational information such as how to nominate a candidate."

In the most recent AB election, the Team added an option to the ballot "No (other) candidate" that could be ranked along with the listed nominees. But there appears to be no definition of what it means to rank this option above actual candidates.

Should the Process Document define what happens if "No (other) candidate" gets enough votes by the team-selected STV vote tabulation system to have "won" one or more of the open seats? Alternatively, should the Process Document specify that only actual nominated candidates appear on the ballot?

Strawman proposal if there is a consensus to keep this option on future ballots: The Process Document should stipulate that no one getting less support than "No (other) candidate" would be seated, and those seats would remain open until the next election. This would allow members to vote AGAINST candidates that they consider to be unsuitable, and in the presumably unlikely event that a candidate garners such strong opposition that "nobody" is preferred by the AC, that candidate would not be seated.

Adopting this approach might suggest removing the text in 2.5.2 after "If, after the deadline for nominations, the number of nominees is" specifying "Equal to the number of available seats, those nominees are thereby elected." Arguably, an election could be held to determine whether any of the nominees get so much opposition that the AC would prefer the seat to remain vacant.

Consistency issue: is it 28 days or four weeks?

The time limits for candidate recommendations is set to four weeks, as in:

must specify the deadline for further comments, which MUST be at least four weeks after publication,

In section 6.4.1. Just a few lines below (in 6.5), it says:

deadline for Advisory Committee review, which MUST be at least 28 days after the publication of the Proposed Recommendation...

Can we try to be consistent and speak either of four weeks or of 28 days? Actually, neither of the two are optimal, if there are, say, Xmas vacations in between, so I believe the ideal would be to say “at least 20 business days”. (This, I believe, is actually the current practice used by the Working Groups.)

Clarify the voting process

The last line in Section 7.3 (about votes) says

'In the case of Advisory Board and TAG elections, "one vote" means "one vote per available seat".'

I think this line is a holdover from previous voting procedures. We now use STV. A literal interpretation of this line is that (e.g.) in an AB election with 4 open seats, each AC rep would have 4 votes: i.e. 4 opportunities to use STV. This is absurd.

I recommend dropping this line.

ToC/document mismatches

Section in the expanded table of contents, but not in the document:

  • 6.2.2.1 Substantive Change

Sections in the document, but not in the expanded table of contents:

  • 2.1.2.1 Membership Consortia
  • 2.1.2.2 Related Members
  • 2.1.3.1 Advisory Committee Mailing Lists
  • 2.1.3.2 Advisory Committee Meetings
  • 5.2.1.1 Member Representative in a Working Group
  • 5.2.1.2 Member Representative in an Interest Group
  • 5.2.1.3 Invited Expert in a Working Group
  • 5.2.1.4 Invited Expert in an Interest Group
  • 5.2.1.5 Team Representative in a Working Group
  • 5.2.1.6 Team Representative in an Interest Group

Title mismatches between ToC and document:

  • 6.2.5 "Classes of Changes to a Recommendation" vs. "Classes of Changes"
  • 10.4 "Rejection of a Submission Request" vs. "Rejection of a Submission Request, and Submission Appeals"

Reference mismatch:

In 6.7.1 Errata Management, there's a reference to "7.2.5 Classes of Changes", but it should be "6.2.5 Classes of Changes".

Version checked: Process Document 1 March 2017

(I haven't checked the latest Editor's version, but I think it would suffer from at least some of the problems above.)

Automatically numbered and generated ToC/references would be great.

Clarify the handling contributions from guests, non-w3c members, and non-WG members

See also #12 and #18. We need to look at how
a) public input
b) member submissions that also have non-W3C members as author/contributor
c) input to WGs from non-members of that WG

are handled from the point of view of IPR. This issue is being filed in order to keep the question alive, and #12 and #18 are being closed. The team is working on practice in this area, and we're holding until that's worked out, and then will consider what (if any) process changes are needed

7.1.1 Charter reviews on a public communication channel?

The Process says team MUST provide member- and team-confidential channels for charter review comments, and that one of those must be the communications default. As we conduct more conversation in public, should we permit a public list to be used and designated for default communications?

That possibility could be useful where we're chartering based on work that has been incubated in public.

Proposed changes to TAG makeup

A proposed set of changes to the makeup of the TAG, as part of #4

  • Be explicit that the chair(s) does not need to be a member of the TAG
  • Suggest that the Director nominate appointees after the TAG election, rather than before
  • Add one elected member to the TAG

This suggestion will be reviewed by the TAG at its July 2017 face to face meeting.

The appeals process doesn't actually describe how an appeal finishes

Section 7.2 ends by saying "If, within one week of the Team's announcement, 5% or more of the Advisory Committee support the appeal request, the Team must organize an appeal vote asking the Advisory Committee to approve or reject the decision."

What happens next? We get a formal vote to overturn the decision. But is there any requirement on how long the vote is open? What is the threshold (simple majority?)? What exactly is the question? (I.e. is it "Should the Chocolate IG be formed?" or "Should the Director's Decision to form the Chocolate IG be overturned"?). If the AC votes contrary to the Director, is the decision automatically overturned, or is it sent back to the Director to think harder?

We've not been down this road and hope we never will, but even so, this degree of uncertainty might be worrying.

Fast Track Submission to PR

I propose the creation of a "Fast Track Submission" process, in which one or more W3C members could submit a document, like a Member Submission, but including complete documentation of having following an open development process as good or better than W3C Rec Track. This might be done in a CG, or somewhere else. The documentation would be examined and verified by the Director (just like with normal Rec Track transitions, but with more verification), and if it passes, the document would be published as a Proposed Recommendation. It would go through the normal AC review, and if it passes, it would become a normal Recommendation.

The horizontal and wide review requirements would prevent a FTS from coming completely out of the blue. There might be other notification requirements, like the members declaring an intent to submit 90 days in advance, or something.

I can also imagine there might be a fee associated with the submission, or a minimum number of co-submitting members, to avoid this process being overly burdensome. (Maybe this would happen before horizontal review, where some of the costs would be incurred.)

One staff member I mentioned this to said, "this will put me out of a job", to which I replied, "you can get a job consulting for these CGs". But, really, don't think this will reduce the demand for WGs, just allow us to tap another kind of energy in producing Recs.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.