Meeting minutes
[plh reviews the agenda]
Pull Requests
Clarify what can be formally objected to
github: https://
florian: Some background on this
… The issue here is caused by editorial refactorings
… The Process before last year, types of decisions were described all over the place
… we refactored everything about this to be more sensible
<plh>
florian: and now we have a section that describes types of decisions
… mostly text pulled from elsewhere
… Then we have formal objections saying that you can object to decisions
… and it *seems* like the only types of decisions that can be objected to are the ones in that section
… but Team Decisions were defined elsewhere
… so this moves that, and gets it organized, and tweaks the phrasing a bit to be more clear
… to make it clearer that all types of decisions can be objected to
https://
plh: How does it help with the question of chair appointments?
florian: Appointing a chair after chartering is a Team Decision o
… there was a complaint that there's nothing you can do to appeal that decision, but actually you can, because Team Decisions can be objected to
… Now that's a bit blunt, and ideally you want to handle without a formal objection
… but that path is available as appeal
… so that's how this PR deals with this issue
plh: ...
florian: First you should of course talk to the Team, to see if it can be resolved amicably
… but formal objection is possible if that doesn't work out
<plh> Advisory Committee representatives may initiate an Advisory Committee Appeal against a Team decision regarding the extension of a Working Group or Interest Group charter.
<plh> https://
plh: FO is about decisions about to be made, appeal is about retroactive
fantasai: not quite, we refactored the objections process, since they were identical, we folded the concepts together and called FO (more common name)
florian: [missed, something about FOs also being able to apply to past decisions sometimes?]
florian: I think this is a clarification, doesn't introduce anything new
plh: Proposal to merge PR 674, any objections?
RESOLUTION: Merge 674 and close 652
Clarify chair selection timing
github: https://
florian: TAG chair was picked by Director, now picked by Team
… AB chair also evolved as well
florian: In both cases, we were fuzzy about timing of when that happens
… and differences weren't intentional
… AB text was a bit more precise
… so this PR makes it clear when it happens and attempts to use the same timing
florian: Timing is "start of term", which is a bit fuzzy (and intentionally so)
… to set up expectation that you should revisit this question routinely
florian: also, we included provision that if majority of group requests a change of chair, even at other times it needs to be considered
florian: Third point is that if a minority asks, it's a "may" revisit
… e.g. if one chair steps down, and might need to appoint a replacement
… or have a loud minority that believes it is a problematic situation
… in this case aren't *required* to revisit the quesiton, but you may
florian: but you are required, at start of term, and if majority requests it, to revisit quesiton of chair
<Zakim> cwilso, you wanted to ask a question I think I know the answer to, but want to confirm
cwilso: I wanted to make sure I understand the subtleties the same way
… This is the Team or the current chairs may, at any time, run this request
… the Team could say, "we want you to re-choose chairs"
… could be in response to minority of participants, in response to chair stepping down, but doesn't need to be either
… So if I step down as chair, they aren't requried to re-run the process
… but if majority requests, it must be re-run
… so for example if I step down, Tzviya can just keep going
… but if she wants she can re-run
florian: and if majority of group says, no that's not okay, have to re-run
plh: Seems odd to have minority to be an example
… if a majority is fine with it
… why re-run
cwilso: It's not that the majority is against it, it's that the majority didn't request it.
… I get your point, but using that minority as an example says, if someone really vocally really doesn't like me as co-chair as AB, they can say that and the Team or chairs can decide to re-run this process
plh: I imagine the Team to be careful in deciding to do that
florian: Yes, and that's why it's not SHOULD, but MAY
plh: Proposal to merge 675
github: https://
RESOLUTION: Merge 675
Member Consortium vs Member Association
github: https://
florian: [explains issue of confusion]
florian: Bylaws uses Member Association for the same concept
florian: so to avoid such confusion, and to align with Bylaws, proposal is to rename the concept
plh: sgtm
plh: Proposal to merge 677, any objections?
RESOLUTION: Merge 677
Allow sharing appeal requests with the Membership
github: https://
florian: We discovered last time there was an appeal
… the person who filed the appeal sent the info to the Team, who had to forward to AC Forum
… but it was weird because the initiator wasn't able to provide rationale
… this PR is about clarifying, you can post also to AC Forum
plh: makes sense to me
florian: Dom said we might want to go further, not just say you can but make it more of an expectation
https://
florian: If we take his comment, I think that would change MAY to SHOULD?
florian: I'm largely indifferent
<plh> fantasai: the shift is to change the expectation of the default
<plh> ... and make the rpivate exceptional
<plh> florian: most important is to make it's not banned
florian: I think main thing is to clarify that being public isn't banned
plh: I think the Team, we'll have an incentive to them share the appeal
… probably SHOULD is fine
florian: Agree, shouldn't go to MUST in case want to make it private
plh: Yes, I want to strongly encourage this, if want to make it private should have a very good reason for it
fantasai: I think it would be useful to make it clearer how to make it member-visible
… right now the Process is very vague, so it's confusing what to do
<TallTed> +0.5 SHOULD, -1 MUST
plh: I would leave that to /Guide, not in the Process. Probably CC ac-forum
<cwilso> +1 should
fantasai: I think I would want the specific method of submitting in an example box
… because I think it would be likely that someone who wants to use this process would look here rather than /Guide
plh: Unsure about hard-coding AC Forum into the Process
florian: It would be first time referencing AC Forum by name and address
<pal> -1 to harcoding ac-forum or providing an example
florian: but if it's in an example, it would be easy to change if necessary
plh: A bit on a slippery slope, gets into operations
fantasai: We do have some links to /Guide in certain places where it's helpful, this is essentially the same idea but it's so short might as well inline it
plh: Florian, can you come up with a reworded PR?
florian: yes
florian: should we resolve on using SHOULD?
RESOLUTION: Switch to SHOULD
Proposed to Close
github: https://
plh: AB met to discuss some of the issues
… and one of those was whether Team should be allowed to make a recommendation in its Team Report or not
… and AB resolved that the Team MAY do so but is not REQUIRED
plh: I believe there's nothing left for us to do here
florian: Yes, AB minutes are delayed because Ralph is busy (for obvious reasons)
… full text of resolutions should be available soon
<cwilso> +1
florian: since we're operating under delegation from the AB, right thing to do is close the issue
plh: Any objections to closing the issue?
RESOLUTION: Close 629
Issues to Discuss
florian: for issues we close, I think we should wait until AB resolutions and rationale are available before marking status of issue as satisfied/unsatisfied
[some discussion on process]
florian: I'll be preparing a Disposition of Comments either way, so should catch all the things then
Reintroduce conditions for closure of a group
github: https://
pal: Before refactoring to remove Director, there were conditions for closing a group
… and refactoring lost those conditions
… there's some discussion about what wording to use when re-introducing the wording
<plh> https://
florian: There were 2 explicit things in old process, which Nigel is correct that rephrasing lost them
… wrt Patent Advisory Groups, it is so defined already in the Patent Policy
… the Process didn't say so, so good idea to list it here as well to avoid a "come from" effect
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
plh: Seems ppl are in favor of introducing wording and improving it
<plh> fantasai: I placed some draft wording in the issue
<plh> .... previous wording had conditions
<plh> .... one clarification that was suggested is "insufficient member resources"
plh: it was fairly restricted before, it was "insufficent resources" or "work is completed"
… and Patent Policy also had a condition to close
… so proposing to close to add the Patent Policy
… and also to add ability of AB or TAG to propose closure?
florian: That one was also resolved by AB, can't track exactly where the resolution is documented...
plh: Nigel was proposing that AB and TAG should not do that without talking first, and of course we should have that expectation
fantasai: I think we can find wording for that
florian: I'd expect AC Review to fail if not
plh: OK, so it seems we're in general agreement, just need a PR
fantasai: Do we want member resources clarification? or are we allowed to close for other resource reasons?
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
… if it's critical and everyone agrees it's impossible, we can't continue
pal: Suggest reading Nigel's last comment
… Team resources are allocated at charter creation time, so absence of Team resources shouldn't close
florian: In general agree, but if e.g. we have a massive economic crisis and lose half the staff, then we have a problem
pal: sure, but don't close the group
… 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" ?
plh: If we have that level of crisis, we have bigger problems
… but for us to close a WG for lack of Team Contact, we've never done that
… I'd rather leave it vague atm
pal: I'd really rather not
… I was in situations of threats to closing WGs because Team did not want to allocate resources
… and ultimately the efforts of W3C are driven by the Members, so work should continue
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
… agree that Team changing its mind about its staffing shouldn't be a reason to close
pal: If WG has nobody working in it, then motion to close will pass, because nobody is working on it
… that's a self-fullfilling case, if no one is doing work then no one will object to closing
florian: I think our expectations are the same, I was just not seeing a risk in keeping it vague
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
plh: I don't feel strongly about it
… if tomorrow we decide not to provide Team support for a WG, still have a problem
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
florian: okay, accepted
RESOLUTION: Clarify to "member resources"
florian: I have a silly case, suppose a WG is staffed entirely with IEs, is that "member resources"?
[florian wraps himself in a logical puzzle]
<TallTed> I did suggest "insufficient group participant resources" or "insufficient group resources" in the issue...
plh: ok, I think that's it for this issue for now
Allow AB or TAG to propose closing a group
github: https://
florian: Needs a PR, should be the same PR as for 685
What is the CR Review Period
github: https://
florian: Required to address issues that were raised during CR Review Period
florian: question is, what is the CR Review Period?
florian: is it the full period of the CR stage? or is it the period prior to the review deadline in the SOTD?
… in which case you MUST address comment in that period, but MAY address comment afterwards
… which gets awkward if you leave a draft in CR for 3 years
plh: In practice, the Director isn't letting people ignore comments during the CR period
… even for comments in PR, the Director wants the addressed
plh: review period, we prefer people to not send comments right at the time of the transition request, that's very frustrating to WG
… so we want to increase pressure on commenter to send comments sooner than later
florian: We want to incentivize ppl to file early, but late comments should still be looked at
… So the fact that there is an explicit window, maybe useful
… but maybe for this sentence we remove "review" and call it the "CR Period"?
florian: all must be addressed isn't all must be fixed, but formally addressing means responding
… WG can decide appropriate thing to do is nothing
plh: We have 2 sentences about this
… one is about them all being formally addressed if in the review period
<plh> must show that all issues raised during the Candidate Recommendation review period have been formally addressed,
<plh> must identify any substantive issues raised since the close of the Candidate Recommendation review period,
plh: then second one is about must identify any issues that were raised afterwards
… and these issues go to gether
florian: So that means, it does mean this predefined period
… and you're required to address those comments, and you have to at least list, if not address, the ones afterwards
florian: Maybe we just cross-link things and make it clear, but don't change
plh: yes. And we do know in practice, if you have comments that are late that show something is broken, we won't allow the WG to move forward
florian: OK, so suggestion is clarify and move on
ACTION: florian clarify as above
plh: Make a PR, and we'll come back to it
End
plh: next call in 2 weeks...
plh: so we'll cancel because between Christmas and NYE
plh: so next call is January 11th