Possible Chartering Issues

Recent message threads on both AC Forum ( Member-0nly) and this mailing list have identified a number of possible issues to consider for Process 2016. These include:

1.      How much "schedule" data should be included in WG Charters?

2.      Charter Creation and Level of Specificity

3.      Using CGs to create enough specificity and content for a WG to be created.

4.      Removing (or standardizing) the boilerplate (so that a review need not consider it).

5.      Rationalizing the treatment of deliverables and the dates at which they are to occur.

6.      Figuring out in practice how to make Charter development and Charter Review a more open, fluid process.

7.       Figuring out how dependencies and liaisons should be noted.



How much "schedule" data should be included in WG Charters?



Charles McCathie Nevile: https://lists.w3.org/Archives/Public/public-w3process/2015Aug/0018.html

Replying to timeless

> My second foray [2] lead me to a Charter that was extended w/o its

> Milestones being updated.



Yeah, that can happen as a consequence of reluctance on the part of chairs to try messing with the charter - see above. On the other hand groups should maintain some live information about their progress.



IMHO that should not be the charter - being able to look at what the group said it would do, and compare it with what it is doing is a pretty basic tool for managing expectations and balancing resource commitments.

Mike Champion: https://lists.w3.org/Archives/Public/public-w3process/2015Aug/0019.html

Agree.  Charters are a bit overloaded; one current proposed one even has a FAQ in it. It would be good to keep the "normative" text that defines the of what the WG can and cannot do  from the "explanatory" text that talks about who, what, and when. The team Director/team should have no leeway to change the normative text, but at least some ability to edit the explanatory text and schedule to reflect current reality.



David Singer: https://lists.w3.org/Archives/Public/public-w3process/2015Aug/0020.html

I actually think we should include less schedule data in the charters, but not relax on having AC approval for the schedule (i.e. a change in schedule means a re-charter).



I don't think it makes sense to predict e.g. when implementations will happen.  I do think the chairs and team should predict how long they expect to take to get from the draft that the WG starts with, to CR.


Charter Creation and Level of Specificity.

Prior to the exchange below, it had been noted that there is nothing in the W3C Process that prevents the text of a charter to be developed in public.

Mark Nottingham: https://lists.w3.org/Archives/Public/public-w3process/2015Sep/0000.html
below are my charter review comments on the Web Payments WG, which I think echo some of what Harry was saying recently.

-8<-
This area of work is very important to the Web, and we support its chartering in general.

I've talked through the issues I had with the charter with Ian and Dom, and made proposals (e.g., <https://github.com/mnot/webpayments-ig>) to make it less verbose and more concrete (although there are still parts, especially in Deliverables, that aren't clear). Hopefully, those changes will make it into the final charter (AIUI the Process doesn't give much visibility into that until after approval).

At a high level, I'm still uncomfortable with this charter, because it isn't based upon a concrete, technical proposal. It also lacks solid information on how it will be implemented; e.g., will it require browser support, or will it be possible to polyfill?

IME successful standards are based upon real implementation and deployment experience with a specific proposal, not confected from whole cloth. Good (even heroic) chairing might give it better odds, but this proposal doesn't name any chair(s), yet.

As such, I'd rather the charter nominate specific technical proposals -- something that the IG can work on and bring back to the AC.

Failing that, I'd expect a more limited charter, where the work was chopped up into manageable bits, so that we can re-charter as the work progresses, contingent upon success in each milestone.

I'm going to leave this as a FO for now, because I think this is a fundamental issue in how we charter work, and I'd like to see a formal response (even if it's overruled, which is fine).
->8---

Doug Scheppers: https://lists.w3.org/Archives/Public/public-w3process/2015Sep/0001.html
[SNIP] I think it would be a good practice (perhaps required) to have a live
revised view of a charter as part of the AC review, and linked to from
the AC poll; this way, as the charter is changed based on feedback,
later AC reviewers can see the changes and work that into their own
review (either in support or opposition).

(Actually, annotations would be great for this, and we have the technology.)

[SNIP]

... the chairs make the WG, and whenever
possible, they should be decided before the charter goes to the AC for
review. It would be interesting to talk about the list of qualities that
a chair selection should have.

For example, Experience chairing in W3C is ideal, but a rare commodity.
Technical strength in the area, but fairness and flexibility. Typically,
calmness and people skills are needed, as is commitment to consensus.
Having a co-chair also be one of the WG's editors is sometimes a red
flag. Availability and organizational commitment are key.

[SNIP]

I think some (not all) of the criticisms here, and on many recent
charters, are more aimed at the general chartering process, and not
specifically at the immediate charter being reviewed.

I agree it's time we looked seriously at how we charter WGs, and how it
can be streamlined and predispose a new WG toward success.

I've been collecting a list of suggestions for general good chartering
practice, many of them from recent charter reviews, and also from
threads on the AC forum. [ A Member-only summary (with apologies to non-Members) of this Member-only thread is at:
  https://lists.w3.org/Archives/Member/w3c-archive/2015Sep/0198.html ]

Summarizing, quickly, the main topics seem to have been:
1.      Using CGs to create enough specificity and content for a WG to be created.
2.      Removing (or standardizing) the boilerplate (so that a review need not consider it).
3.      Rationalizing the treatment of deliverables and the dates at which they are to occur.
4.      Figuring out in practice how to make Charter development and Charter Review a more open, fluid process.
5.      Figuring out how dependencies and liaisons should be noted.

Mike Champion: https://lists.w3.org/Archives/Public/public-w3process/2015Sep/0002.html
I'm struggling to think of an exception to Mark's point that successful standards are based on real experience.  I strongly encourage W3C to charter WGs to standardize what works rather than to take a "if we standardize it they will implement" approach.

Jeff Jaffe: https://lists.w3.org/Archives/Public/public-w3process/2015Sep/0004.html
While I agree that we get the greatest success from real implementation
and deployment experience, I don't feel that "one size fits all", and I
don't think we should hold up all chartering until we have real
implementation.

Especially for web payments. [Because the lack of standards is becoming a significant problem.]

The Modified Jaffe Inverted Scale of Standardization Readiness
Is summarized separately in:
https://lists.w3.org/Archives/Public/public-w3process/2015Sep/0012.html

Steve Zilles