Feedback on Charter refinement draft text

[caribouW3]

Hi,
I have been trying to apply the text proposed in section "Lifecycle of Chartered Groups" to the current chartering of a WG.
While the first part is relatively common (getting the proposal in shape, sending the advance notice, getting horizontal reviews), I've found some difficulties implementing it.

Specifically:

1. in section "initiating...":

• Charter Facilitator is not well defined. Is it a team member? Currently our guidebook does not mandate that a single team member takes care of it until the end. It is very common that more than 1 team member working on a (re)chartering. Or is it an external person (or several) proposing the new charter (group chair? CG chair? another person? Again there is often several people involved...

• Team rejection is not defined. In general, I think that the team will delay the start of the chartering process (i.e. the advance notice) until there's a reasonably well-constructed proposal. The guidebook does not mention anything that could be referred to as a rejection.

2. In section "Charter Refinement"

• Charter facilitator is still unclear, although he's given the confusing role of a Chair person. What does chairing mean in a process where no group is formed and no meeting happens? I find the term Chair in that context very confusing and not useful. Why not sticking with the term "facilitator" and introduce a new one that's confusing ?

• issues must be "formally addressed". By whom? Who's responsible for evaluating the consensus of the resolutions?

• "the group is made up of all individuals participating in this process" : the "group" here is undefined. what does "participating" means in that context? Anyone who sends a comment? anyone proposing a resolution? the term "group" usually refers to something implemented with a process for joining/leaving. Is it the same intent here? AC and Team (and public?) individuals joining a formal "group" right after the advance notice?

• "chair decision to abandon" seems to imply that the chair has super power to drop the case. That would be rather strange, in particular for a WG rechartering, to give such power to a single person.

• the next NOTE is very hard to parse (disclaimer: I'm not a native speaker) and understand. Also, "misbehavior" is undefined. e.g. Failure to evaluate consensus is not misbehavior... I think.

Finally, I had expected to see the Disposition of Comments sent to the AC prior to the vote, not at the same time, in order to get more opinions on the substantial issues before the vote instead of getting them during the vote. It seemed to me that the problem to solve with all this new wording was to add a milestone to get AC reps involved earlier. If not, why is all that wording in the process document instead of the Guide?

[frivoal]

Thanks for the feedback. Here's an attempt to answer your questions.

As a general note, there's nothing yet (as far as I know, though I could be wrong) in the Guide about this, since this is a new proposed procedure, not yet an official one, so it is unsurprising that you wouldn't at the moment find detailed guidance for how to roll this out. I'd suggesting syncing up with @plehegar on that.

Currently our guidebook does not mandate that a single team member takes care of it until the end. It is very common that more than 1 team member working on a (re)chartering. Or is it an external person (or several) proposing the new charter (group chair? CG chair? another person? Again there is often several people involved...

That is a deliberate change. There can absolutely be several people (from the Team) working on a charter, but there should be an identified person whose responsibility is being in charge of consensual decisions. We want to separate the role of the person or persons advocating (and editing) a charter draft from the one who checks if there's consensus and calls issues resolved. It's not forbidden that this would be the same person, just like a WG chair can also be the editor of the spec, but it's not generally expected to be the same person. (see also later questions about the facilitator and their role).

The (draft) Process is also deliberately silent on who this person is, so that the Team can make a choice.

Team rejection is not defined.

If the Team is considering proposing a charter on its own initiative, it can wait for a long as it wants before initiative charter development, or change its mind and not start after all, with no recorded decision and no formalism as long as the charter review notice has not yet been sent. Same thing if the Team was considering a charter based on an informal suggestion by somebody.
However:

• if there was a formal request from a Member that the Team initiate charter refinement, then the Team must answer formally (and if the answer is no, the requester might Formally Object to that). Reasons for rejecting are up to the Team, but "not incubated enough, wouldn't succeed, so please prepare more" or "fuel composition for combustion engines is way out of scope for W3C, you need to propose this elsewhere" would be reasonable and could be expected to be supported by a Council in case of Formal Objection, while "I don't like you" or "I don't feel like it this year" would not be reasonable, and would be expected to be overruled by a Council.
• if the charter review notice has been sent, then it's up to the group facilitator to decide whether we should give up, which they shouldn't do on a while, otherwise there will likely be formal objections against this arbitrary decision to close. However, if there is no consensus and no reasonable path forward, there may be times where abandoning is the right call.

Charter facilitator is still unclear, although he's given the confusing role of a Chair person. What does chairing mean in a process where no group is formed and no meeting happens? I find the term Chair in that context very confusing and not useful. Why not sticking with the term "facilitator" and introduce a new one that's confusing ?

The goal is not to say that the facilitator also has the role the chair, but to say that facilitator is a kind of chair. We're calling them facilitator in an attempt to avoid confusion with the person who will eventually be chair of the WG. But we're defining them as being a type of chair so that they have the same powers as normally vested into a chair. See also the next question.

Issues must be "formally addressed". By whom? Who's responsible for evaluating the consensus of the resolutions?

It is the facilitator's role is to evaluate consensus and to make sure issues are addressed. That's why we have this role in the first place.

"the group is made up of all individuals participating in this process" : the "group" here is undefined. what does "participating" means in that context? Anyone who sends a comment? anyone proposing a resolution?

Yes, anyone who raises an issues, comments on one, proposes a solution… is participating. It doesn't mean a chair needs a response from everybody (just like a WG chair doesn't need a response from every member of the WG). But if someone has a problem with something, it's not appropriate to just close the issue with "sorry, that's not what we're after", without consulting anyone. For each topic, the resolution should reflect the consensus of those who are participating in the discussion (and if no consensus can be found, the usual rules for managing dissent or voting apply.

"chair decision to abandon" seems to imply that the chair has super power to drop the case. That would be rather strange, in particular for a WG rechartering, to give such power to a single person.

Until now, the Team collectively has had that power. If the Team chose to give up on a charter, then the charter dies, and there's nothing anybody can do about it. Framing it this way makes it into a identifiable decision, which means it can be objected to. I don't expect the facilitator to randomly drop charters (including recharters) that should progress, but if they do drop one, it is now something members can push back against.

the next NOTE is very hard to parse (disclaimer: I'm not a native speaker) and understand. Also, "misbehavior" is undefined. e.g. Failure to evaluate consensus is not misbehavior... I think.

You are referring to this text and the accompanying note:

Any Formal Objection filed during the charter refinement phase—​other than an objection to the choice of Chartering Facilitator or to a decision to abandon the proposal—​is not considered registered until the close of the Advisory Committee Review of the charter, and is registered against that W3C Decision.

Note: This enables all Formal Objections on the same proposed charter to be handled together, while allowing Formal Objections to Chartering Facilitator misbehavior that the Team is failing to address to be processed immediately.

The Note may need rephrasing. What this is trying to do/say is:

• if there are formal objections raised about the content of the charter, about how well points of views were taken into account when determining consensus, and so on, all these formal objections are handled together at the end, so that the Council can look at the whole picture, and also, before we get to that point, to give a chance to further discussions to resolve the objections.
• however, in the following two cases, the formal objections are treated without waiting:
  • the facilitator makes a decision to give up: we can't wait until the AC review, since there won't be one.
  • the choice of facilitator is itself called into question, by participants who don't believe they're capable of, or trying to, do a balanced job of evaluating consensus and addressing issues. Formally objecting to that is very heavy handed, and if there's a problem, informal discussions with the Team are more likely to be productive. But it is generally possible to object to a choice of chair (here or for regular WG/IG) anyway, so if it does happen, it is better to process it sooner rather than later.

Finally, I had expected to see the Disposition of Comments sent to the AC prior to the vote, not at the same time, in order to get more opinions on the substantial issues before the vote instead of getting them during the vote. It seemed to me that the problem to solve with all this new wording was to add a milestone to get AC reps involved earlier. If not, why is all that wording in the process document instead of the Guide?

The charter review notice is what is sent to the AC prior to the vote in order to get opinions and involvement. It is also allowed to bring it up the the AC's attention multiple times, if the facilitator thinks that they're not getting quite enough feedback (this can be seen as part of the requirement to get wide review). A DoC is not a document that solicits feedback, but one that documents how much solicitation has occurred already, and how the feedback was handled. Informing AC Reps for the AC-Review on the amount of feedback received and about the extend to which issues which were raised have found consensual conclusions is useful to let them know how much scrutiny is appropriate.

[caribouW3]

As a general note, there's nothing yet (as far as I know, though I could be wrong) in the Guide about this, since this is a new proposed procedure, not yet an official one, so it is unsurprising that you wouldn't at the moment find detailed guidance for how to roll this out. I'd suggesting syncing up with @plehegar on that.

This issue comes from non-conclusive discussion that I've had with him, implementation details can't be clearly stated if the overall intent of those sections is not clear. What is exactly the problem this is trying to solve? Participation level? amount of late FO? It seems that those could be improved with more efficient communication. FWIW almost all councils so far would not have been avoided by having such a process.

I understand that there is a desire to rely on the existing chair/group definitions, but the analogy makes the wording very confusing. Thank you for clarifying. I still see several gaps with the Facilitator role definition:

1. IIUC the Facilitator can't be the Team member who helps the proposal to get in shape and edits the charter, the team contact, nor it can be a participant (e.g. WG or CG participants). Such a powerful Facilitator has to be obviously neutral [Currently, consensus checking is done by a (reasonably large and diverse) set of Team members.]

"chair decision to abandon" seems to imply that the chair has super power to drop the case. That would be rather strange, in particular for a WG rechartering, to give such power to a single person.

Until now, the Team collectively has had that power. If the Team chose to give up on a charter, then the charter dies, and there's nothing anybody can do about it. Framing it this way makes it into a identifiable decision, which means it can be objected to. I don't expect the facilitator to randomly drop charters (including recharters) that should progress, but if they do drop one, it is now something members can push back against.

Side note: Members can already propose to recharter as a "push back" in an issue raised by the Team to close a WG after the end of its current charter. (It happened last year for the SVG WG). Therefore there seems to be no need for additional process for this case.

2. Formal Objections can happen only after formally recorded resolutions, which happen usually after a vote (or CfC). There are generally no votes/CfC during the charter editing/review period before the AC review, so in fact this new refinement phase introduces a process similar to AC review (or group decision), likely with only a subset of the AC+non-AC participants, with a Disposition of Comments as a result. Is that right?
   In most cases there would still be no vote needed, However, it seems that again the Facilitator, being the one to decide whether to hold a vote, has a lot of decision power. If the Facilitator decides not to have a vote, the FO would then be a request to change the Facilitator.

Then... who's going to judge whether we need to change the Facilitator? Who's deciding who the Facilitator is, BTW?

It seems to me that the Facilitator might just be another level of indirection and unnecessary complexity added to the chartering process.

[css-meeting-bot]

The Revising W3C Process CG just discussed Feedback on Charter refinement draft text, and agreed to the following:

• ACTION: Ensure /Guide is drafted wrt charter refinement phase

The full IRC log of that discussion

<fantasai> Subtopic: Feedback on Charter refinement draft text
<fantasai> github: https://github.com//issues/934
<fantasai> plh: Team is experimenting with the draft Process with some charters
<fantasai> caribou: I started before experimenting with process
<fantasai> ... looked at Process and /Guide
<fantasai> ... got it wrong because I assumed the facilitator was the shepherd, who is a Team person
<fantasai> ... I think shepherd should be Team, and facilitator non-Team
<florian> q+
<fantasai> ... Parallel with chair was confusing, understood only after Florian explained
<fantasai> ... I think I now understand the intent, but the text is not conveying clearly
<fantasai> ... of course if /Guide was rewritten with that in mind, it would be clearer
<fantasai> plh: /Guide is matching the currently active process, not proposed one
<plh> ack florian
<fantasai> florian: Confusion definitely if referencing /Guide -- not talking about same thing
<fantasai> ... another aspect that's tricky to read is, in this case (as in many), we're not trying to define everything
<fantasai> ... some aspects up to Team, but Team hasn't decided yet
<fantasai> ... Process deliberately doesn't say, to allow Team to develop policy
<fantasai> ... if you come to it before Team has policy, there's no guidance so this is confusing
<fantasai> ... maybe we could have that guidance in the Process, but we wanted to allow experimentation
<fantasai> ... e.g. try Team facilitator, non-Team facilitator.
<fantasai> ... From Process POV we needed an identified person with identified responsibilities of identifying consensus etc, and not the same person as the champion of the proposal
<fantasai> ... but who that is is up to Team
<fantasai> ... so that's probably part of confusion
<fantasai> ... Though probably some editorial fixes are possible, maybe we should write the Guide first, and then come back to see what needs clarification in the Process
<fantasai> caribou: I'd been confused by the /Guide
<fantasai> ... never seen reference to "shepherd"
<fantasai> ... just relying on my existing knowledge
<fantasai> ... shepherd in /Guide is clearly person in Team that's driving that charter
<fantasai> ... facilitator coudl be Team... seems role is more than one person from the Team
<fantasai> florian: goal of facilitator and shepherd is different. could be same person, but then they need to wear two hats
<fantasai> ... goal of shepherd is to drive work forward and have vision for what happens to it
<fantasai> ... goal of facilitator is to make sure input is heard and addressed, and reaching consensus of participants -- chairlike role
<plh> q+
<fantasai> ... it could be possible that future chair is both. or could be they're 3 different people.
<fantasai> ... Process just defines the responsibilities, and someone needs to be responsible for each
<fantasai> caribou: Most surprising to me is that [missed]
<fantasai> florian: It's explicit, and can be objected to if they abuse their power.
<fantasai> ... In the past, sometimes somebody -- maybe Team or enthusiastic CG member -- is driving charter forward
<fantasai> ... and then someone else makes a comment, this needs to change
<fantasai> ... the driver says "No, sorry, that's not what we're doing" and summarily closes the issue.
<fantasai> ... that's not supposed to happen
<fantasai> ... facilitator is to ensure this does not happen, that issues get fairly addressed
<fantasai> ... Used the term "facilitator" instead of "chair" to avoid confusion with the Wg chair
<fantasai> caribou: Team member is doing that role.
<fantasai> ... maybe facilitator should be non-Team
<fantasai> ... maybe we need a group of Team
<fantasai> ... we already have something like that, to check that issues were addressed, but it's not transparent -- internal to Team
<fantasai> ... maybe it should be more public
<florian> q+
<plh> ack plh
<fantasai> ... but wasn't clear to me the intent
<fantasai> plh: idea of group is fuzzy in section ??
<plh> https://www.w3.org/policies/process/drafts/#charter-development
<fantasai> ... first there's a note that the charter facilitator is not necessarily a chair of the group
<fantasai> ... so existing group
<fantasai> florian: or identified chair of future group
<fantasai> plh: then it talks about decisions as group decisions
<fantasai> ... you have 2 groups -- group being chartered, and group making the decision
<fantasai> ... those are two different sets of individuals
<fantasai> florian: yes
<fantasai> florian: We have a bunch of people interacting.
<fantasai> ... Someone is trying to make the charter happen -- shepherd
<fantasai> ... Some loosely defined group of people giving input on the charter
<fantasai> ... Someone chairing that loose group of people, ensuring consensus and disposition of comments
<fantasai> ... We have ??, who decides whether the facilitator did a good job and it's ready for AC Review
<fantasai> ... and then we have AC Review
<fantasai> ... If the chair/shepherd/facilitator are all the same person, they're judging themselves a lot
<fantasai> ... but conceptually not the same person
<fantasai> plh: This removes power of Team to submit a charter for AC Review, moves it to this group
<fantasai> florian: yes. If the facilitator is not from Team, the Team doesn't decide when we move to AC Review.
<fantasai> ... facilitator's job, whether Team or not, is to make sure there's consensus -- and if so, ask Team approval to send to AC
<fantasai> ... if there's no consensus, the facilitator can give up or move forward anyway (over objections, which get forwarded to Council)
<fantasai> ... they're supposed to try for consensus, but if impossible, still possible to move to AC Review by chair decision
<fantasai> plh: Problem nowadays is silent majority
<fantasai> ... and opposition is very vocal
<fantasai> ... so if you look at record, you see lots of opposition, but not support
<fantasai> ... so important if we can submit to AC for review, even in absence of consensus
<fantasai> florian: If you follow links, group decision is not always consensus
<fantasai> ... but is decision on behalf of group, trying to reflect will of group
<fantasai> ... chair decision is not, it's the chair's own judgement
<fantasai> plh: unsure about not being able to send to AC Review over objections
<fantasai> caribou: You can, you just get objections
<florian> q- later
<fantasai> caribou: Why was this proposal made? What is the goal of this charter refinement phase? is it to avoid FO at a later phase?
<plh> ack fantasai
<fantasai> -> https://lists.w3.org/Archives/Member/chairs/2024JulSep/0057.html
<plh> fantasai: several goals
<plh> ... reducing the # of FOs
<plh> ... ensure comments get addressed
<fantasai> -> https://github.com/w3c/AB-memberonly/issues/224#issuecomment-2229540346
<plh> ... make the chartering process more understantable and easier to be a part of.
<fantasai> florian: All three points reinforce each other.
<fantasai> ... if ppl don't know how to make comments early, they'll make them late
<plh> florian: last 2 are reinforceing the first point
<fantasai> ... if they expect to be ignored early, they will make them late
<plh> ... make sure people know where and when to file comments
<fantasai> ... want to make sure that people know where to file comments, and ensure they will be handled with typical W3C consensus process
<plh> ack fantasai
<plh> ack florian
<fantasai> florian: It's been awhile since we wrote this text, so suggestion to re-read and see if we can make any editorial improvements
<fantasai> ... also suggestion that somebody should write the corresponding /Guide
<plh> florian: at this point, we should take an other read and see if editorial improvements. maybe a corresponding guide. once we have it, we should revisit
<fantasai> plh: SGTM
<fantasai> ... havent heard back from ChrisL or tidoust, so need to touch base with them
<plh> ack fantasai
<plh> fantasai: initially, the facilitator should be either chair of the wg or a member of the team, different from the shepherd.
<fantasai> plh: [missed]
<fantasai> caribou: I could facilitate either one
<fantasai> florian: One thing hard to discover with these experiments is that people at large aren't familiar with the process
<plh> s/[missed]/maybe too late for css or gpu. will check./
<fantasai> ... there might not be a lot of facilitating because people won't know where to give comments
<fantasai> plh: Should still try
<fantasai> ... currently we totally rely on WG to propose the next charter; in those cases charter facilitator can be chair of existing group
<fantasai> ... some extreme cases where that might not work
<fantasai> ... e.g. DID, we knew we would get objections
<fantasai> caribou: was asking about goal, not about gettng consensus, right?
<fantasai> ... maybe communication-wise can improve
<plh> fantasai: it does help in batching FOs in case of lack of consensus
<plh> ... in lots of time, charter comments that can be easily fixed get filled as FOs
<plh> ... we had cases where the conversation after AC review resolved the FOs without a Council
<plh> ... ie it was a solvable problem but, due to lack of conversation, got resolved after the AC review
<plh> carine: all recent got triggered by issues brought after the AC review started
<plh> florian: maybe there is something missing in our text.
<plh> ... the phase is supposed to be more clearly advertized
<plh> ... we have a strategy pipeline, emails, etc.
<plh> ... but people loose track
<plh> ... if we have a clear phase, we're hoping to get more people to participate in it
<plh> ... making things clearer is supposed to help
<plh> carine: we do this in advance notice but there is no follow-up in advance notice
<plh> florian: there is a little bit of how mature the charter is when the advance notice
<plh> ... is sent
<plh> ... sometimes, it's just an idea
<fantasai> plh: We send horizontal review requests to AB/TAG, but never get comments
<fantasai> florian: I'd like to push back on this. I've made comments.
<fantasai> ... some fuzziness, suggested that AB as a body should do things
<fantasai> ... but notices going to AB, individuals might give feedback; but the body won't take that up
<fantasai> caribou: maybe splitting notices would help
<fantasai> florian: facilitator could also join AB-led member meetings, invite people to join
<fantasai> plh: just sent email to wendy about this
<fantasai> caribou: you should send those not yet in AC Review
<plh> https://www.w3.org/2024/03/charters-in-dev.html
<fantasai> plh: one change I made to charter tracker rather than advertising when issue was created is when last update to issue was made
<fantasai> florian: Anyway, thanks for trying this out
<fantasai> fantasai: Do we have documentation? If an AC logs in, how do they find the charter dashboard?
<fantasai> plh: koalie probably knows
<fantasai> florian: if we can't answer that, we have a problem
<florian> s/answer that/easily answer that
<fantasai> caribou: They weren't interested
<fantasai> florian: Not necessarily this URI, but the set of things to know about
<fantasai> ... there's the dashboard, mailing list, incubation pipeline, etc.
<fantasai> ... a number of things that tell people what's going on
<fantasai> ... but nobody outside Team knows about it
<fantasai> caribou: if you want to drive more people, then you have to have a way to get their attention and motivate them to sepnd more time
<fantasai> florian: we need better organized information rather than more information
<TallTed> an AB member dashboard might be the thing. I don't know if such exists yet.
<fantasai> s/AB/AC/
<plh> https://www.w3.org/2024/03/charters-in-dev.html
<fantasai> fantasai: Need to collect all of this information and put it together into a single page where people can find everything they need to know about charters and charter development
<fantasai> ... and make that findable from the homepage somehow
<fantasai> ... through some reasonably followable navigation
<fantasai> florian: so in your mind this is the central information point
<fantasai> caribou: it seems fantasai wanted more
<fantasai> [more discussion]
<fantasai> fantasai: yes. and index of everything about charters:
<fantasai> ... all the existing charters, past charters, in-progress charters, ideas about charters, process and guidebook rules about charters, open AC reviews on charters, everything
<fantasai> ACTION: Ensure /Guide is drafted wrt charter refinement phase
<fantasai> s/Ensure/plh to ensure/
<RRSAgent> I have made the request to generate https://www.w3.org/2024/11/13-w3process-minutes.html fantasai

[ianbjacobs]

Formal Objections are a big hammer and imply significant resource implications. Rather than introduce new hooks for Formal Objections into the process, there may be other ways to achieve goals, in particular:

• Find a mechanism to ensure all charters receive AC review, including those not supported by the staff.
• Increase transparency about staff decisions.

For example (and without needing to change the W3C Process):

• For any charter sent to the AC for review, the staff (e.g., coordinated by the head of strategy) could provide commentary about the charter.
• Where the staff does not support a charter, the commentary would provide rationale.

That should suffice to achieve both goals.

Overall I think we should endeavor to shrink and simplify the W3C Process. We should evolve and document best practices outside of the Process Document. Many of the other suggestions in the proposed additions to the Process Document do not need to be formally specified. They can be promoted (with good tooling, templates, etc.) as best practices, until they become the obvious way to do things. Let's solidify our culture and simplify our process.

[fantasai]

@ianbjacobs The goal of this is actually to decrease the formal objections, by having an earlier discussion phase that is clearly defined and managed -- and if a charter goes to AC Review with objections, by batching those objections with the results of the AC review at the end of that process. We can't do this batching unless the Process defines it.

I think your suggestions are all good improvements to the (lower-case) chartering process, though.

[css-meeting-bot]

The Revising W3C Process CG just discussed Feedback on Charter Refinement Text.

The full IRC log of that discussion

<fantasai> Topic: Feedback on Charter Refinement Text
<fantasai> github: https://github.com//issues/934
<fantasai> [discussing doing a presentation to the Team]
<fantasai> plh: Probably looking at January now. Can take an action item to schedule it.
<fantasai> ... we usually target Thursday at 9am Eastern for project reviews
<fantasai> florian: Ideally, by the next AB F2F, we can declare that Process CG is done, and launch first informal AC review
<fantasai> ... so if we want to do some explaining to the Team, we could do it after that
<fantasai> ... but if we want to raise issues, sooner is better
<fantasai> fantasai: last Process CG meeting before AB meeting is Jan 8th
<fantasai> ... better to get in before then
<fantasai> plh: could maybe do December 19th?
<fantasai> fantasai, florian, Ian: wfm
<fantasai> plh: Can focus on changes that affect the Team
<fantasai> ... what's new from perspective of Team Contact in the new Process

[css-meeting-bot]

The Revising W3C Process CG just discussed Ian's Feedback.

The full IRC log of that discussion

<fantasai> Subtopic: Ian's Feedback
<fantasai> github: https://github.com//issues/934
<fantasai> Ian: Prepared a deck wrt chartering at TPAC, particularly issue of FOs
<fantasai> ... but I have no recollection of presenting this deck
<fantasai> ... I created a modified version for today
<Ian> https://docs.google.com/presentation/d/1snHd4J0S73cPMc4zRx-158JpncCULWRFp7mifDTlmdI/edit#slide=id.p
<fantasai> Slides: https://docs.google.com/presentation/d/1snHd4J0S73cPMc4zRx-158JpncCULWRFp7mifDTlmdI/edit#slide=id.p
<fantasai> Ian: Some things driving conversation
<fantasai> ... very few times that Team doesn't propose a charter to AC
<fantasai> ... concern around growing number of Formal Objections
<fantasai> ... and increasing Member engagement around chartering
<fantasai> ... seems this was also your goal
<fantasai> florian: yes
<fantasai> Ian: We wrote down high-level goals to solving this
<fantasai> ... want to make sure work is interesting -- people are engaged if it's interesting
<fantasai> ... make it easy to do reviews
<fantasai> ... want not just AC review, but earlier review to improve quality, build community and support for the work
<fantasai> ... and improve consensus and understanding of the charter
<fantasai> ... maybe resolve some FOs, even if not all of them
<fantasai> ... critical to consortium health that Members be engaged
<fantasai> ... demonstrations of engagement help the staff allocate resources
<fantasai> Ian: for each of these, how would we do it?
<fantasai> ... identifying interesting work, we have CGs, listen to Membership, etc.
<fantasai> ... we have many mechanisms to hear what's interesting and what's not
<fantasai> ... Tactics for improving consensus, e.g. cultural values and shared principles (design principles, vision, etc.)
<fantasai> ... improving training and education around CGs
<fantasai> ... no hammer to get ppl to agree, need to do it in soft ways and help them feel part of community and share the values
<fantasai> ... but consensus is not always possile
<fantasai> ... we can do things to improve the odds, but sometimes can't get to consensus
<fantasai> ... so should capture the disagreements
<fantasai> ... charter reviews create opportunity fo rshared understanding
<fantasai> ... and charter reviews should produce proposals for improvements to increase consensus, and documentation of dissent
<fantasai> Ian: I don't want to increase opportunities for FOs
<fantasai> ... instead, want to create incentives to make a decision
<fantasai> ... we want engagement
<fantasai> ... hearing conversations about doing more community management on AC Forum; no need for process, just need to do a better job
<fantasai> ... easier to raise issues early, without calling them FOs
<florian> q+ to respond a couple of points (once Ian is done)
<fantasai> ... Let's keep finding ways to make things easier to do
<fantasai> ... Tooling improvements, centralizing management of charter reviews, etc.
<fantasai> ... Members need to be interested because interesting topics, but also not dissuaded from engagement because hard to do
<fantasai> Ian: Ideas for experimentation
<fantasai> ... There's an initial charter
<fantasai> ... different series of review steps (analogous to REC track)
<fantasai> ... gathering comments on their way to AC Review
<fantasai> ... this would include the staff
<fantasai> ... part of my comment in issue is, let's not add hooks for objections
<fantasai> ... let's say cultural expectation is that all charters go to AC Review, except rare cases where staff determined this is spam
<fantasai> ... we want the staff to have some fallback power to prevent undue noise
<fantasai> ... if ppl don't trust staff to do that, bigger problem
<fantasai> ... assuming staff does what it always does, and prepares to send to AC
<fantasai> ... if bad idea, we can have staff comments, horizontal review info, etc. AC can make the call
<fantasai> ... incentive for the staff to express itself, but AC decides
<fantasai> ... so I would like to suggest that we don't put a magnifying glass on the staff's tasks, but find incentives and use cultural means to get the desired outcome
<plh> q?
<plh> ack florian
<Zakim> florian, you wanted to respond a couple of points (once Ian is done)
<fantasai> florian: That's interesting, because I think we are close on many things; but some you have a different read on what we're proposing
<fantasai> ... your main point of difference is "don't create so many opportunities for FOs"
<fantasai> ... and I don't think we are, so let's talk about it
<fantasai> ... One that's new is ability to FO to Team refusing to propose something at all.
<fantasai> ... I don't expect this to be used.
<fantasai> ... I expect Team to be reasonable.
<fantasai> ... But it's signaling. This is something you have a right to ask.
<fantasai> ... Sometimes people believe "it'll be ignored anyway, so why bother asking"
<fantasai> ... or sometimes they see "Team proposes", and therefore wait, but nothing happens
<fantasai> ... makes it clear that you can ask
<fantasai> Ian: It should be socially appropriate to ask "what's the status of X"
<fantasai> ... usually have reasons why it's not happened yet
<fantasai> ... but hammer in process to FO, not sure it's useful signalling
<fantasai> ... Both of us agree this is likely unnecessary, unlikely to happen often
<fantasai> ... If we can just put our comments and put out the charter, the need for staff to stop spam is almost never
<fantasai> ... We both have a model where we don't think a thing will happen very often, but rely on
<fantasai> ... which approach do we take in leveraging those models?
<fantasai> ... I love asking, but don't like FOs
<plh> q+
<plh> ack fantasai
<florian> fantasai: the reason we put it in there is not because we expect it to be use
<florian> fantasai: you have to be rejected before you can object to the rejection
<florian> fantasai: this forces exposing the reason if there is a rejection
<florian> fantasai: there has been requests from the AC that there be backstops to Team decisions
<fantasai> ... if you want the charter to be submitted faster, FO, is not the option because it's slow; only if something is blocked is it reasonable to use
<fantasai> plh: [missed] I see within the AC a lot of frustration, not always justified, that I didn't get my way so I'm going to FO
<fantasai> ... e.g. object to a charter because an issue in the spec didn't get addressed as they wanted
<Ian> q+
<Ian> ack plh
<fantasai> ... nothing I can do to prevent that from happening, but it does add weight to the whole thing
<fantasai> ... interesting case between AB and Team, Exploration IG
<florian> q+
<fantasai> ... at some point will ask Team to send charter to AC, but there's no chairs
<fantasai> ... can you object to that?
<fantasai> ... even when Team comes up with middle-ground solution, ppl not trusting the Team
<fantasai> ... vs pragmatics of the Team not seen as constructive as it used to be
<plh> ack fantasai
<Zakim> fantasai, you wanted to react to plh
<Ian> fantasai: You can object to the team not sending a charter to the AC for review if you have requested and the team has refused you.
<Ian> fantasai: The other thing you can object to is, in the process of drafting the charter, you can object to some aspect of the charter. The charter still goes to the AC with the objection attached
<florian> fantasai: you can object to the Team not moving a charter only if they reject a request you made, so if you haven't asked, there's nothing to object to
<florian> fantasai: the second point is that while we're discussing a charter, you can file an FO, but it doesn't get processed right then, it gets queued for processing later, at the same time as the AC Review
<Ian> q?
<Ian> queue==florian,ian
<plh> ack florian
<fantasai> florian: Another nuance, you don't get to object to Team not sending to AC, but to not starting the chartering procedure
<fantasai> ... if we are starting that, no blockage
<fantasai> ... if Team said, no not going to work on it, then AC rep could complain about not being allowed to work on the charter
<fantasai> Ian: Why just create opportunities to converse. This opens the door to more FOs
<plh> q+
<fantasai> florian: 2 parts, other part is FOs against content of charter. It does not create opportunity for more Councils.
<fantasai> ... This says that if you raise an FO during charter drafting, then it doesn't get handled now
<fantasai> Ian: Yeah. It's just the Team micromanagement bit that's the source of my reaction
<fantasai> ... I think we can experiment before formally changing the Process
<fantasai> ... e.g. batching including Team comments
<fantasai> ... We should try something 3-4 times before embedding in the Process
<plh> ack ian
<fantasai> florian: We cannot experiment with saying that we don't have to process FOs right now. We have to process them; ignoring them is a Process violation.
<fantasai> Ian: adding an objection to Team not processing something is what I object to
<fantasai> [ some back and forth on what constitutes an FO ]
<fantasai> plh: Wrt FO against Team for not sending a charter to AC, is important
<fantasai> ... there's no way for someone to escalate that
<fantasai> ... that's something we should give permission to AC to escalate
<plh> ack plh
<fantasai> ... give a way to object to that kind of non-decision
<Ian> q+
<fantasai> Ian: Person wants us to put forth a charter, and Team doesn't want to, then require Team to put forth to the AC along with Team comments
<plh> ack ian
<fantasai> florian: That's not better. If a bad charter ends up in front of AC, it will not only end up with FO anyway, it will require involvement of the entire AC
<fantasai> ... that's not better
<fantasai> florian: There's the abuser case, but there's also the naive person case
<fantasai> ... by having right to refuse, when someone asks you can have a conversation explaining why you refuse, e.g. this or that needs fixing
<plh> q+
<fantasai> ... requirement to forward as soon as asked, is impractical
<fantasai> ... and no right to appeal a refusal is politically untenable
<fantasai> ... I think the Team is unlikely to refuse anything that's reasonable
<fantasai> ... and if Team isn't reasonable, then they deserve to get the FO
<fantasai> plh: I heard 2 different things
<fantasai> ... Ian says, we don't need to change Process, we need to change Team practices
<fantasai> ... say instead of refusing charter, just send to AC with commentary
<fantasai> ... Florian discusses problem of unconditionally forwarding the charter
<fantasai> Ian: It helps to enumerate use cases
<fantasai> ... question is whether we think it's infinitesimally likely to have FOs in this approach
<plh> q-
<fantasai> ... 1. Staff is empowered to not put forth charters that are obviously not ready or spammy, and no appeal is likely in that case
<fantasai> ... 2. Reasonable charter, in that case just send to AC, potentially with our own comments, for AC to make decision
<fantasai> ... No need to reject reasonable charters, so we won't
<fantasai> ... If we're all saying staff wouldn't do that...
<fantasai> florian: You know this, and I know this, but bulk of AC doesn't.
<fantasai> ... There's a good chunk of AC doesn't understand how chartering works, doesn't understand they can ask the Team for charters
<fantasai> ... adding a hook in the Process makes it clear that any AC rep has the right to request a charter
<fantasai> ... given how the Process is written, if we point that out and say that you can't object to it, that leads to object that you can FO if rejected
<fantasai> ... saying that this is uniquely unappealable will be weird
<Ian> q+
<plh> ack fantasai
<plh> ack ian
<fantasai> fantasai: Part of purpose of Process is documenting how the process works, so that ppl can understand how to do things
<fantasai> ... and wrt the FO that you're saying we don't need because Team is reasonable, AC wants to know that if Team becomes unreasonable, they have recourse
<fantasai> Ian: We don't need to document everything in Process
<fantasai> ... we have /Guide etc.
<plh> q+
<fantasai> ... I don't think we should add "how to" into the Process
<fantasai> plh: I don't think we're going to reach a conclusion today on this
<fantasai> florian: Thanks for sharing the perspective
<fantasai> Ian: Some concern about over-engineering staff processes
<fantasai> ... concerns that arise in this topic, and gut reaction to it
<fantasai> ... valid topic
<fantasai> florian: Wrt removing procedural things from Process, and in some cases I agree -- e.g. just did this for Member Submissions
<fantasai> ... but this one needs more because it's contentious
<fantasai> plh: Sometimes just Guidebook needs to be revised
<fantasai> ... maybe ProcessCG can be more involved in /Guide
<fantasai> ... but trying to figure out what's our next step from here
<fantasai> florian: I'll note that you two disagree on this FO opportunity, so not AB vs Team here
<fantasai> ... One thing we might attempt is to de-emphasize that part.
<fantasai> ... What's essential is that there are clear boundaries, and ensuring ppl know they have the right to ask
<fantasai> ... if it falls out implicitly that an FO is possible, maybe you'll like this more
<fantasai> [discussion on how to structure next week's presentation]
<fantasai> Ian: Just wanted to express my appreciation for working on the Process
<RRSAgent> I have made the request to generate https://www.w3.org/2024/12/11-w3process-minutes.html fantasai