Facilitator not explicitly chair

[frivoal]

This is a suggestion by @ianbjacobs to work around the lack of a clearly defined group.

---

I think the explicit reference in the opening sentence to decisions (plural) being made based on that consensus is helpful.

This does lack clarity about what happens when there isn't consensus, though we may be able to combine it with #997 to deal with that case…

I am less certain about removing the the different types of decisions a that can conclude the phase. This is certainly simpler, but there distinction in the original text were deliberate.

Still, offering this PR for discussion.

---

Preview | Diff

[ianbjacobs]

Here is my thinking on reusing the term "Chair":

• In previous discussions, the case was made to reuse the Process-defined concept of "formally addressing an issue." That made sense to me in that context because my approach was close enough, and there is value in reuse when fit for purpose.
• In this case, I do not think the concepts of "group" and "Chair" as used throughout the process document today are fit for purpose for this situation. The roles of the Chair in the process document are for chartered groups or for meetings. There's very little in any case about the roles of a Chair in the process document, and the process document directs people to the Guide for a more complete definition. In the Guide, there are many aspects of Chairing that are irrelevant to this situation, hence my comment that the term as used commonly today does not lend itself readily for reuse here.
• I also think it is unnecessary to add the concepts here in order to make the point that "someone is in charge" and establish roles and responsibilities.

Here is my thinking regarding conclusion of the charter refinement phase:

• Ultimately the Team makes a decision based on input. Therefore, I found mention of three types of decisions (group, team, chair) to be confusing. It is both simpler and more accurate to say "The Team makes a decision" but it is important to indicate that the decision is based on community input (as we've discussed).
• I suggest deleting "subject to Team verification that the expectations of charter refinement are fulfilled." That is overly prescriptive. Due to its role supporting the W3C mission, it's important that the Team be able to decide not to start refinement even if expectations are fulfilled and that they be able to start refinement even if expectations are not fulfilled (in order to enable the Consortium to make progress). As we've discussed, in these cases the Process Doc will require the Team to provide rationale to the Membership, and define the escalation path for Members if they don't agree with the decision and rationale.

[tantek]

Seems reasonable to allow this flexibility.