Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reintroduce the conditions for closure of a group #685

Closed
nigelmegitt opened this issue Dec 7, 2022 · 13 comments
Closed

Reintroduce the conditions for closure of a group #685

nigelmegitt opened this issue Dec 7, 2022 · 13 comments
Labels
Closed: Accepted The issue has been addressed, though not necessarily based on the initial suggestion
Milestone

Comments

@nigelmegitt
Copy link
Contributor

#585 did not only change who could propose closure of a group but also removed the criteria for doing so. That change appeared not to be motivated or discussed, and there was no linked issue. I propose that we revert that latter change, i.e. reintroduce the two conditions under which a closure can be proposed, being:

  • There are insufficient resources to produce chartered deliverables or to maintain the group, according to priorities established within W3C.
  • The group produces chartered deliverables ahead of schedule.

Or at least discuss it more openly.

@fantasai fantasai added the Agenda+ Marks issues that are ready for discussion on the call label Dec 12, 2022
@fantasai
Copy link
Collaborator

Thanks @nigelmegitt for catching that, I agree it should be discussed. Possible suggested wording:

The [=Team=]{, the [=TAG=], or the [=AB=]}¹ <em class=rfc2119>may</em> propose to close a group
prior to the date specified in the charter in any of the following circumstances:

* There are insufficient resources to produce chartered deliverables
  or to maintain the group,
  according to priorities established within W3C.
* A [=Patent Advisory Group=] concluded that the work
  <em class=rfc2119>should</em> be terminated.
* The [=TAG=] or [=AB=] determined that continuing operation of the chartered group or its work
  would be detrimental to W3C or its mission.
* The group produces chartered deliverables ahead of schedule.

Such a proposal to close a group must be accompanied by rationale,
and the proposal must be confirmed by an [=AC Review=] as a [=W3C Decision=].

¹ See #653

@nigelmegitt
Copy link
Contributor Author

Thanks @fantasai . In both the cases of the Patent Advisory Group and the (TAG or AB) determining that the WG should be closed, I would like there to be an explicit prior condition that there has been a significant attempt to resolve whatever problems caused concern and that attempt has failed with all parties satisfied that consensus cannot be reached.

Essentially this is just writing down what we'd expect anyway; the idea is that we are clear that the groups concerned cannot unilaterally commence shutting down a group without proper process beforehand, for example on a whim of "this doesn't feel like it should be in scope of W3C" after the AC has explicitly approved the Charter: we should not be introducing mechanisms for a small subset of people to reopen AC review-based decisions without strong cause.

@palemieux
Copy link

+1 to @nigelmegitt proposal to reintroduce the conditions for closure of a group.

It should be clear that "insufficient resources" mean "insufficient member resources" since Team resources were allocated when the Charter was approved.

@TallTed
Copy link
Member

TallTed commented Dec 13, 2022

Rather than either "insufficient resources" or "insufficient member resources", I would say "insufficient group participant resources" or "insufficient group resources" — as there may well be sufficient member resources except that these members are not participating in the group.

@dwsinger
Copy link
Contributor

I'd rather leave it at "insufficient resources" and have the AC ballot explain why that's now the case. Maybe the group realized it was under-resourced by charter; or the resource needs are not justified by something (participation, progress, …).

@nigelmegitt
Copy link
Contributor Author

The "Content of a Charter" section of the Process requires that the Charter includes (amongst others):

  • The expected time commitment and level of involvement by the Team (e.g., to track developments, write and edit technical reports, develop code, or organize pilot experiments).

We need to guard against the Team deciding to pull Team effort from a WG, so that this expectation is no longer being met, and then declare that there are insufficient resources, and the WG should close.

Hence I support a change of wording to clarify that it's lack of member participation that's being referenced here.

@css-meeting-bot
Copy link
Member

The Revising W3C Process CG just discussed Reintroduce conditions for closure of a group, and agreed to the following:

  • RESOLVED: Clarify to "member resources"
The full IRC log of that discussion <fantasai> Subtopic: Reintroduce conditions for closure of a group
<fantasai> github: https://github.com//issues/685
<fantasai> pal: Before refactoring to remove Director, there were conditions for closing a group
<fantasai> ... and refactoring lost those conditions
<fantasai> ... there's some discussion about what wording to use when re-introducing the wording
<plh> https://www.w3.org/2021/Process-20211102/#GeneralTermination
<fantasai> florian: There were 2 explicit things in old process, which Nigel is correct that rephrasing lost them
<fantasai> ... wrt Patent Advisory Groups, it is so defined already in the Patent Policy
<fantasai> ... the Process didn't say so, so good idea to list it here as well to avoid a "come from" effect
<fantasai> florian: There was another issue, 653, the AB resolved that AB or TAG could trigger an AC Review for closing a group, so can list that explicitly as well
<fantasai> plh: Seems ppl are in favor of introducing wording and improving it
<plh> ack fan
<plh> fantasai: I placed some draft wording in the issue
<plh> .... previous wording had conditions
<plh> .... one clarification to make "insufficient member resources"
<fantasai> s/to make/that was suggested is/
<fantasai> plh: it was fairly restricted before, it was "insufficent resources" or "work is completed"
<fantasai> ... and Patent Policy also had a condition to close
<fantasai> ... so proposing to close to add the Patent Policy
<fantasai> ... and also to add ability of AB or TAG to propose closure?
<fantasai> florian: That one was also resolved by AB, can't track exactly where the resolution is documented...
<fantasai> plh: Nigel was proposing that AB and TAG should not do that without talking first, and of course we should have that expectation
<fantasai> fantasai: I think we can find wording for that
<fantasai> florian: I'd expect AC Review to fail if not
<fantasai> plh: OK, so it seems we're in general agreement, just need a PR
<fantasai> fantasai: Do we want member resources clarification? or are we allowed to close for other resource reasons?
<fantasai> florian: I'd prefer to make it vague, if we lack some kind of resource that makes the work impossible, then we shut it down
<fantasai> ... if it's critical and everyone agrees it's impossible, we can't continue
<fantasai> pal: Suggest reading Nigel's last comment
<fantasai> ... Team resources are allocated at charter creation time, so absence of Team resources shouldn't close
<fantasai> florian: In general agree, but if e.g. we have a massive economic crisis and lose half the staff, then we have a problem
<fantasai> pal: sure, but don't close the group
<fantasai> ... as long as the Members want to continue the work, should be allowed to conitnue
<Dingwei> if so, is it better rephrased as "insufficient interets" or "insufficient participation" ?
<fantasai> plh: If we have that level of crisis, we have bigger problems
<fantasai> ... but for us to close a WG for lack of Team Contact, we've never done that
<fantasai> ... I'd rather leave it vague atm
<fantasai> pal: I'd really rather not
<fantasai> ... I was in situations of threats to closing WGs because Team did not want to allocate resources
<fantasai> ... and ultimately the efforts of W3C are driven by the Members, so work should continue
<plh> q?
<fantasai> florian: I agree with you, but I'm not worried about this case because it's a proposal that goes to the AC who can reject it
<fantasai> ... agree that Team changing its mind about its staffing shouldn't be a reason to close
<fantasai> pal: If WG has nobody working in it, then motion to close will pass, because nobody is working on it
<fantasai> ... that's a self-fullfilling case, if no one is doing work then no one will object to closing
<fantasai> florian: I think our expectations are the same, I was just not seeing a risk in keeping it vague
<fantasai> pal: I agree with Nigel, unless adding the qualifier really removes a case we want to keep, it provide guidance in what cases a group can be closed
<fantasai> plh: I don't feel strongly about it
<fantasai> ... if tomorrow we decide not to provide Team support for a WG, still have a problem
<fantasai> florian: changing allocation resource is a Decision, and you can FO
<plh> fantasai: we should accept the member resources clarification
<plh> .... if something exceptional occurs, there is the AB and the TAG
<plh> ack fan
<fantasai> florian: okay, accepted
<fantasai> RESOLVED: Clarify to "member resources"
<fantasai> florian: I have a silly case, suppose a WG is staffed entirely with IEs, is that "member resources"?
<fantasai> [florian wraps himself in a logical puzzle]
<TallTed> I did suggest "insufficient group participant resources" or "insufficient group resources" in the issue...
<fantasai> plh: ok, I think that's it for this issue for now

@css-meeting-bot css-meeting-bot removed the Agenda+ Marks issues that are ready for discussion on the call label Dec 14, 2022
@nigelmegitt
Copy link
Contributor Author

Re Florian's logical issue about members, I believe IEs are WG members, so as long as we're clear that we're talking about WG members, it should be fine.

@frivoal
Copy link
Collaborator

frivoal commented Dec 14, 2022

@nigelmegitt the minutes didn't capture that extra bit, but during the call I also mentioned that even if we don't count the IEs as members, the absence of IEs would only be a critical problem if there was no other participant in the group, in which case we would also be in a case of insufficient member resources anyway.

@dwsinger
Copy link
Contributor

The "Content of a Charter" section of the Process requires that the Charter includes (amongst others):

  • The expected time commitment and level of involvement by the Team (e.g., to track developments, write and edit technical reports, develop code, or organize pilot experiments).

We need to guard against the Team deciding to pull Team effort from a WG, so that this expectation is no longer being met, and then declare that there are insufficient resources, and the WG should close.

Hence I support a change of wording to clarify that it's lack of member participation that's being referenced here.

We really don't. If the consortium hits hard times and has to cut staff, there may well be groups that can't be properly supported, as a result. Any proposal to close would be subject to AC vote, and at that time, the AC would be at liberty to say "you are cutting the wrong support".

@nigelmegitt
Copy link
Contributor Author

We really don't. If the consortium hits hard times and has to cut staff, there may well be groups that can't be properly supported, as a result. Any proposal to close would be subject to AC vote, and at that time, the AC would be at liberty to say "you are cutting the wrong support".

Two reasons why I believe we do:

  1. The Team could cut staff for other reasons, not just hard times. What I think we need to guard against is the Team choosing to cut the staff and then using that lack of staff as a motivation for closing the Group.
  2. Even if there are hard times that affect the Team, but WG members are able to continue working successfully, the Team should not be allowed to propose closure on the basis of lack of team support.

If we do not guard for this, and it gets all the way to an AC vote, it's gone way too far and those AC representatives of participating members might reasonably be furious, both at the situation and the waste of effort.

@dwsinger
Copy link
Contributor

We really don't. If the consortium hits hard times and has to cut staff, there may well be groups that can't be properly supported, as a result. Any proposal to close would be subject to AC vote, and at that time, the AC would be at liberty to say "you are cutting the wrong support".

Two reasons why I believe we do:

  1. The Team could cut staff for other reasons, not just hard times. What I think we need to guard against is the Team choosing to cut the staff and then using that lack of staff as a motivation for closing the Group.
  2. Even if there are hard times that affect the Team, but WG members are able to continue working successfully, the Team should not be allowed to propose closure on the basis of lack of team support.

If we do not guard for this, and it gets all the way to an AC vote, it's gone way too far and those AC representatives of participating members might reasonably be furious, both at the situation and the waste of effort.

The key word in what you write is propose. We are trying hard to move away from the team decides. The AC is quite at liberty to do those pushbacks you cite when they vote.

frivoal added a commit to frivoal/w3process that referenced this issue Jan 10, 2023
* Restore lost conditions of closure, which limited its application.
* Clarify “insufficient resources” to “insufficient member resources”.

See w3c#685
frivoal added a commit to frivoal/w3process that referenced this issue Jan 10, 2023
* Allow AB or TAG to propose group closure
* Restore lost conditions of closure, which limited its application.
* Clarify “insufficient resources” to “insufficient member resources”.

See w3c#685
frivoal added a commit that referenced this issue Jan 11, 2023
* Allow AB or TAG to propose group closure
* Restore lost conditions of closure, which limited its application.
* Clarify “insufficient resources” to “insufficient member resources”.

See #685
@frivoal frivoal added Closed: Accepted The issue has been addressed, though not necessarily based on the initial suggestion and removed Needs proposed PR labels Jan 11, 2023
@frivoal frivoal added this to the Process 2023 milestone Jan 11, 2023
@frivoal
Copy link
Collaborator

frivoal commented Jan 11, 2023

Closed by #696

@frivoal frivoal closed this as completed Jan 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed: Accepted The issue has been addressed, though not necessarily based on the initial suggestion
Projects
None yet
Development

No branches or pull requests

8 participants