search

w3c / process

W3C Process Document
https://www.w3.org/policies/process/drafts/
180 stars 120 forks source link

Have the normal, default, decision policy for charters in the process #425

Open dwsinger opened 4 years ago

dwsinger commented 4 years ago

Yes, this would make the process longer, but make the vast majority of charters shorter. All charters have a 'decision policy' section which (to my eye) has been copy-paste in most charters I see. It seems it makes sense to define that as a baseline, and have charters only call out when they are unusual. Such a section could also define what you're allowed to over-ride.

Here's a copy-paste from a charter. Can anyone tell which one?

This group will seek to make decisions through consensus and due process, per the W3C Process Document (section 3.3). Typically, an editor or other participant makes an initial proposal, which is then refined in discussion with members of the group and other reviewers, and consensus emerges with little formal voting being required.

However, if a decision is necessary for timely progress, but consensus is not achieved after careful consideration of the range of views presented, the Chairs may call for a group vote, and record a decision along with any objections.

To afford asynchronous decisions and organizational deliberation, any resolution (including publication decisions) taken in a face-to-face meeting or teleconference will be considered provisional until 10 working days after the publication of the resolution in draft minutes sent, which will be published within 5 working days of the meeting to the working group's mailing list with a 'call for consensus' in the subject line. If no objections are raised on the mailing list by the end of the response period, the resolution will be considered to have consensus as a resolution of the Working Group.

All decisions made by the group should be considered resolved unless and until new information becomes available, or unless reopened at the discretion of the Chairs or the Director.

This charter is written in accordance with the W3C Process Document (Section 3.4, Votes), and includes no voting procedures beyond what the Process Document requires.

fantasai commented 4 years ago

I can tell that it's definitely not the CSSWG charter. CSSWG F2F/telecon resolutions are not considered provisional--though participants are free to re-open the issue if they have something new for the group to consider. (Also since F2F minutes are not always processed within 5 days there's no way I'd approve a charter encoding that expectation.)

plehegar commented 4 years ago

I note that the proposed draft doesn't follow the wording of the charter template. I didn't check all 34 charters but I suspect few do follow this proposed decision policy. The webperf group does at least.

dwsinger commented 4 years ago

ah, it seems that I accidentally made a meta-point. I think that I, and many, don't easily notice when the Charter does have something unusual or unique; these sections so often look like boilerplate, it's easy to overlook when they are not.

dwsinger commented 2 years ago

Maybe have two or three? But yes, making charters shorter and making it easier to detect when they have non-default would be nice.

plehegar commented 2 years ago

I suspect that the wording of the charter template is the most common one, with some variation because we do tend to revise the charter template on an ongoing basic. Then, we have charters, like CSS, AGWG that are drastic variation. One alternative approach would to indicate in a charter if the decision policy is a major variation from the default one.

dwsinger commented 2 years ago

Yes, I have two goals here:

I don't mind where the standard texts go, but it would be ideal if there was a change-controlled set of them, so a charter could say:

as the entire text of a section, and only sometimes say

plehegar commented 2 years ago

Charter template contains the default policy.

dwsinger commented 2 years ago

It would be a lot easier on AC Reps if they could read "This charter uses the default decision policy, with a consensus period of 13.3333 days" or "This charter's decision policy is based on the default, except that…" or simply has an explicitly worded decision policy. I'd be fine even if we had "default A" and "default B".

The problem is that when reading a charter and it looks like the boilerplate, AC reps can easily miss slight tweaks. Ideally charters contain text that is specific and unique to the group in question, and it's important and worthwhile reading it all.

plehegar commented 2 years ago

So, we already have a default testing policy, linked from charters. As mentioned in it, it says "No substantive changes may be made to this document without a W3C Advisory Committee review of the Group Charters it is linked from.".

Instead of making the Process bigger (insert proper emoji here), how about follow the same pattern for the decision policy?

plehegar commented 2 years ago

Adding @svgeesus in this thread since he has been maintaining the charter template in the recent past.

LJWatson commented 2 years ago

I like the idea of having a default decision policy, and think @plehegar's suggestion in https://github.com/w3c/w3process/issues/425#issuecomment-1184550167 is a good approach.

dwsinger commented 2 years ago

surely, we could have one or more reference decisions policies somewhere; they don't need to be in the Process directly.

plehegar commented 2 years ago

alr then, I'll coordinate with @svgeesus to change the charter template.

svgeesus commented 2 years ago

I like the idea of having an external, default decision policy, based on the charter template decision policy.

The sole variation in the template is to pick a duration between 7 to 10 days.

Can we simply pick 7 days and put that in the policy? Or are some groups deeply attached to 10 (or longer?)

LJWatson commented 2 years ago

We have the "7 to 10 days" text in the decision policy for WebApps but to the best of my recollection, most CFC are done on the basis of 7 days. Ditto for the HTML WG.

nigelmegitt commented 2 years ago

TTWG Decision Policy has been 10 working days for many years. This period was chosen, I seem to remember, to allow for any folk taking a 2 week vacation to at least have a chance of seeing and responding on their return, which probably catches the commonest "worst case", that may occur during a summer vacation for example.

svgeesus commented 2 years ago

@LJWatson @nigelmegitt thanks for the comments.

Having done a deep dive on the charters I am no longer considering a default "7 days" but instead a default "5 to 10 working days" which covers the majority of WGs and IGs. A couple have up to 15 working days. So most groups would be able to link to a default decision policy; some would link to it but note a different period; and several working groups (CSS, GPU & WebPerf) have slightly different to very different decision policies.

svgeesus commented 2 years ago

Comparison of charter template decision process with existing charters

Most (21 groups) copy the one week to 10 working days unchanged from the charter template. Another 5 use 5 to 10 working which is effectively the same (5 working days plus two weekend days)

Working Groups

Links are to the decision policy section of the most recent charter.

Interest Groups

svgeesus commented 2 years ago

Decision policies which are a) different from default and b) consistently used by one or several groups over multiple charters deserve to be named so they can be referenced as-is and charter review is thereby simplified for the reasons @dwsinger mentioned.

svgeesus commented 2 years ago

@dwsinger

Here's a copy-paste from a charter. Can anyone tell which one?

No, I can't tell if it is the GPU for the Web WG or the Web Performance WG. But it is one of those two.

dwsinger commented 2 years ago

Let's not overreach here. My goal here was simple: to make charters shorter and easier to read, and in particular that AC not contain lots of text that they get in the habit of skipping because they'd seen it before. The vast majority of words in a charter should be worth reading, because they are specific to that charter. I am concerned that charters may (and occasionally have) made minor changes to the template and AC Reps probably won't notice if the text is inline, but will if the charter says "we adopt the default decision policy with the following changes…"

Please can we stay at that level? Starting to impose decision policies and periods would be a separate question.

svgeesus commented 2 years ago

How is this as a first draft. It has the default and the CSS ones. If this seems to be the right direction I will add the "after minutes are posted" one used by GPU and WebPerf.

https://www.w3.org/2022/07/decision-policies.html

svgeesus commented 2 years ago

It would be a lot easier on AC Reps if they could read "This charter uses the default decision policy, with a consensus period of 13.3333 days"

That is exactly my understanding. I don't see any overreach or imposition.

chaals commented 2 years ago

If this seems to be the right direction I will add the "after minutes are posted" one used by GPU and WebPerf.

It's the right direction. Rather than "after the decision is recorded", where possible I prefer to use "from when the agenda is posted" - although it only applies to agenda-based decisions and not stuff that came up in a meeting, preparing an agenda is something I think we should encourage.

(In my day job we use a github milestone for the agenda, so people can see and negotiate the items, and we aim to have at least the next three milestones visible to allow transparency and planning. The formal agenda is then posted when the deadline for the milestone has passed).

svgeesus commented 2 years ago

Rather than "after the decision is recorded", where possible I prefer to use "from when the agenda is posted"

An interesting option, especially if the agenda is constructed in the way you suggest, but very different from "when the decision is recorded in the posted minutes" which two groups are using.

Speaking with my spec editor hat on, I would find it quite a drag on productivity and timely review if I couldn't edit the ED right after a meeting but had to wait 15 days. CSS WG frequently sees spec edits made within a couple of hours of decision taken at a meeting, and implementer review in the following 24 hours. But different groups have different styles.

nigelmegitt commented 2 years ago

Speaking with my spec editor hat on, I would find it quite a drag on productivity and timely review if I couldn't edit the ED right after a meeting but had to wait 15 days.

Happy to discuss this in more detail, but this issue probably isn't the right forum - hit the triangle for more, suggest a better place if you want to chat further

- we had v interesting discussions about this kind of thing in TTWG in the past, and ended up with a mechanism that allows Editors to proceed at their speed, but allows the WG members to review within the decision review period.

We are currently trying out with a couple of specs a working model in which a Pull Request is a CfC, and merging it after the review period automatically triggers a WD publication, so what the public sees as the WD tracks the WG's consensus in as timely a manner as we can manage. The concept of an ED is therefore much less useful, though will undoubtedly become relevant again at CR and beyond.

A key thing was not to bias in favour of Editors making a bunch of changes more quickly than WG Members could sensibly follow, but also not to require a huge time-suck at major publication moments while every interested WG member had to go and read all the changes at once, unless they want to.

frivoal commented 2 years ago

I like the idea of easily being able to tell apart charters that use common verbiage from those that used a slight variation of common verbiage. I like a lot less the de-facto implication that there's one normal way to do things, as that implies that groups who want to do something else aren't normal, and might have to justify their difference or face objections to it. Especially given that some preeminent and productive groups (like CSS) would be considered abnormal.

In particular, while the decision policy included in the template is generally reasonable, it owes a good part of its popularity to being in the template. The template is maintained in the open, but isn't under any particular community governance, and hasn't seen anywhere near the level of scrutiny that the process has received. I suspect that if the template had been based on the CSS decision policy rather than on the web-apps decision policy, we'd be seeing a different distribution in charters. I do think that the current "default" would still be popular, but possibly not quite as widespread as it currently is.

Based on this, I think that maintaining something like what Chris has set up at https://www.w3.org/2022/07/decision-policies.html (possibly with a couple more entries documenting other existing distinct policies), and replacing the current text of the template with "[pick a policy from https://www.w3.org/2022/07/decision-policies.html or write your own. If your policy is a slight variation from one of those documented in that document, say so.]" is probably a good idea. And as for the typical CFC-based policy, I'd list it first as Chris has done (owing to its popularity), but I don't think I'd call it the default one, which is a value judgement that I don't think is necessary.

svgeesus commented 2 years ago

I like a lot less the de-facto implication that there's one normal way to do things, as that implies that groups who want to do something else aren't normal, and might have to justify their difference or face objections to it.

I think that perception would be shaped by whatever the charter template gives as the options.

The current template certainly gives the idea there is one normal way (which hasn't prevented groups modifying this slightly to substantially, and (remembering that the survey I did above was of current charters) passing AC Review.

Especially given that some preeminent and productive groups (like CSS) would be considered abnormal.

On the contrary, the formulation that CSS has used since 2016 would be one of the standard options, which other groups could also choose to adopt.

I suspect that if the template had been based on the CSS decision policy rather than on the web-apps decision policy, we'd be seeing a different distribution in charters.

Agreed.

maintaining something like what Chris has set up at https://www.w3.org/2022/07/decision-policies.html (possibly with a couple more entries documenting other existing distinct policies), and replacing the current text of the template with "[pick a policy from https://www.w3.org/2022/07/decision-policies.html or write your own. If your policy is a slight variation from one of those documented in that document, say so.]" is probably a good idea.

That was basically my plan, yes.

I wanted to get at least one more option into that document and a few more eyes on it, before altering the template along the lines you suggest.

dwsinger commented 2 years ago

My mistake for using the word 'the' in the title of this issue; I am totally fine with having a small set of baseline/adoptable, policies, it doesn't have to be only one.

plehegar commented 1 year ago

from https://www.w3.org/2023/01/11-w3process-minutes.html -> deferred

frivoal commented 3 months ago

@svgeesus had a good proposal here. As we're discussing charters, I think it's time we revisited this

svgeesus commented 3 months ago

I should check that the default one still matches the current charter template, and update from the template if not. Ogh and remove "Director" :)

@frivoal what is the deadline for updating this?

frivoal commented 3 months ago

@svgeesus I'd say your draft is enough to explain the concept. If we adopt it in principle, then we can worry about landing specific text before a specific deadline. Until then, keeping it updated is nice, but doesn't seem blocking.