Meeting minutes
Pull Requests
Issue 580
<plh> Github: w3c/
Florian: We discussed last time, it's quite a large change
… It's about initiation of chartering. Current process is lightweight, says the team does it
… Want to frame the team practices better. When team has a charter ready, team sends a message identifying the chair of chartering phase, details of how to contribute
… Details around handling of FOs during this process. We collapse these together, to discuss in full
… Can formally request the team starts this process
… A couple of requests for tweaks from last time
… One was requested clarification, a bit tangential. When rechartering, if modifications are substantial, use the same process
… If modifications are minor, team can do this without AC review
… If team feels AC review is beneficial, they can still do that. This clarification is in
… Other is about advance notice, when team is starting to think about something and wants feedback
… We used "review notice" as the term for start of chartering phase, so there was a request to clarify that there's both formal charter review with AC, and also earlier to ask feedback
… Ted made a few editorial suggestions, one remains needing clarification
PLH: The team isn't required to send advance notice, it's a "may"
Florian: If team had to send notices, they'd be a few days apart, not helpful
… If there's long time between, it makes sense
<fantasai> +1 to deferring to /Guide
Florian: Additional detail could go in the Guide, don't know if we want to be stricter in the Process
PLH: When to trigger an AC review. The team considers group extensions beyond 6 months as substantive, requiring AC review
… That policy is in the guide. Don't see a need to change the practice
Fantasi: It's reasonable practice, also fine not to have as requirement in the Process
<Zakim> plh, you wanted to mention 6 months max extension
cwilso: Thanks for all the work on this. I reviewed it, I think it's good. I appreciate the "charter review must include" bit, more effective than current process
… Do we want to try it out before putting into the Process?
PLH: We haven't decided when to ship the next version of the Process, decide around TPAC
… I tried to get Team comments on this, no comments, so so far so good
… Still want to get feedback from Coralie
… Happy to experiment, we're already changing practice. But if not documented in the Process it needs to be in Guide, for the staff
Florian: We could experiment with it. One thing that would be needed in the process is any FO raised in the chartering phase waits for that to end, so FOs get processed together
… Process has requirements on how fast to process, so we'd lose that
… Another part is the explicit right to demand team to start a charter and object
… It's not formally a Team decision, so not clear you can formally object, before in the process
… But still can try it, and think we should
PLH: I can take an action item to add it to the Guide, so we can experiment
Florian: Alternatively, I could make a branch of the process with the text before merging it?
PLH: Either way is fine
… This seems like the biggest process change for 2024. We have enough time to experiment before TPAC
cwilso: I'd hope we don't have too many FOs during that early draft stage
… If you're going to try the Process, it's important to note to the AC so it's different, so the usual suspects pay more attention to the review notices
… I sometimes don't look before the advance notice comes out, as not clear what to do. This is an improvement
fantasai: Decisions made about the charter before AC review aren't FOs so that mechanism doesn't work if it's not in the process
… i think it should be rolled into the process, and delay that if necessary. it shouldn't take long
<Zakim> plh, you wanted to mention https://
<plh> Charter dev
PLH: To improve comms with AC, ensure they're up to date, I asked Carine to create a view of the strategy repo, showing charter pipeline
… We're figuring out where to put it, making a few tweaks
… Any objections to merging this to the main branch?
Florian: Ted just joined. Do you agree with my responses?
Ted: I can file a follow up issue
PLH: Objections to merging 851?
(none)
fantasi: This issue needs to go to the AB
<fantasai> PROPOSED: The Process CG resolves to adopt PR 851
RESOLUTION: The Process CG resolves to adopt PR 851
#862
<plh> github: w3c/
Florian: It's a small change, further work will be needed
… People have said maintaining Recs is complicated and hard to understand
… This tries to make it easier to understand
… Four classes of change are possible. The Process discusses how to discuss changing a Rec for each class
… For substantive changes and new features, it talks about folding in a candidate addition, but doesn't talk about how they're done
… They're editorial notes, so follow that process. So this change reminds people how to do that
PLH: PR seems fine. It also fixes a bug in the process
… Chairs still struggle with this. I can organise a TPAC breakout
… We haven't solved it from a tooling point of view
Florian: That's why I started with the editorial bit
RESOLUTION: Merge 862
#860
<plh> Github: w3c/
Florian: Last time we had a proposal for closing an issue for updating Notes when a WG doesn't exist
… PLH noted inconsistency with maintaining Rec track docs
… This PR tries to harmonise
… It collapses all the team ability to update documents into one place
… The team can do markup changes and limited editorial changes
… There's some ambiguity, in a WG if anyone disagrees it's editorial, then it's not
… For the team there's no WG to debate if editorial, so it says you can do class 2 changes, but be conservative
… Beyond class 2, they're team edits. Similar to candidate amendments, there's an annotation in the spec, then wait for a WG to fold it in
PLH: I like it. We do try to be conservative, due to patent policy considerations
… Another comment I heard is the team has a lot of power, not fair. No, we rely on the good judgement of the team, won't make corrections unless the group is OK
Florian: We don't want to have to create a WG to fix typos, change affiliations, so the team needs some ability
… If there's abuse, raise an FO
PLH: Do we say those are team decisions
… May want to make that explicit
Florian: Important to identify, in cases where team doesn't take action, e.g. in chartering case
Fantasai: Here, if the Team doesn't make an edit and people feel strongly, they can set up a WG at that point
PROPOSED: Merge 860
RESOLUTION: Merge 860
Issues
#861
<plh> Github: w3c/
Florian: I'm looking how to simplify the process
… The Proposed Rec phase is useful, we do checks, poll the AC
… Less useful may be the publication of the PR itself. We could do all those things on the CR
… Before, we had last call CR, as a transitional phase. We removed it 10 years ago?
… Other types of report, Registries, Statements, etc don't have a PR phase
… I have a draft PR, it would reduce amount of text without the meaningfully changing things
… Let me know if it's a bad idea. Otherwise I'll propose a PR
<fantasai> +1 from me https://
+1 from me
<cwilso> +1
<TallTed> +1 to see the PR
Florian: OK, will make the PR. It also will help simplify the diagrams
cwilso: The state isn't useful, but the transition point is. There are gates on PR, but really they're on advancing to Rec
Florian: Yes, all those need to stay
PLH: The publication is a public signal. But there's already public confusion about the different document types we have in general
Florian: If we want to communicate, we could write a blog post
PLH: If people don't care, we can remove it, but if they do we'd need to look deeper
Fantasai: This simplifies the process, but it's a major change to how the Process feels. We should propose it to the AB then the AC before including in the draft Process
Florian: Makes sense. Drafting the PR will help people judge, but happy to wait for feedback before landing it
#852
<plh> github: w3c/
Florian: When setting up a Council, if team has a recommendation for disposing the issue, and everyone agrees, we skip the Council
… Two things: We could do something slightly less drastic. Also, getting feedback from everything is hard
… So this is before we discuss, if anyone disagrees or isn't sure, we should talk about it
… It's important to have a lot of people behind the proposal for it to be legitimate
… So if any single voice says no, it needs to stay. If a few don't answer at all but 90% of the council says yes and 10% don't respond, is that good enough and still legitimate?
… Should I draft a PR?
PLH: I think it's a bit too early
… In the case of TimBL, he doesn't want to abstain indefinitely just yet
… Was this discussed in the AB and TAG?
Florian: Not in a formal meeting
PLH: I think you should consult them. But they may not be best to judge the current situation
cwilso: In general it seemed like a good idea. Raise in the AB
cpn: I think the legitimacy point is a good one here. I would want to keep a high threshold.
… with such a large group, ~20 people
… at that level 10% would be OK, but below that would raise legitimacy
florian: higher threshold than 80%?
[several: 90% seems safer]
cpn: percentages are strange when we're talking about a group of 20 in total
florian: Could go with a number, e.g. if 1-2 people don't respond it still passes
#823
Fantasai: Higher is better, also need to allow a certain amount of time
<plh> github: w3c/
Florian: Nigel said maybe the info shouldn't be in the charter. The decision that changes a chair isn't the same as the decision to change the charter
… Changing the charter requires AC review, changing chair doesn't
Fantasai: Not sure I agree with that, now we've clarified what team can change and what requires AC review
… This is where people expect to find the information, it's where the AC expects to find it
+1
cwilso: It would create two separate places to have FOs, don't want to do that
<plh> (+1 to cwilso)
cwilso: I'd rather it be in the initial review
Florian: We already list chairs in other places, e.g., WG pages. They may not be in sync
cpn: how big a problem is maintaining these in sync?
PLH: Not a big problem, but can take a while to resolve who the chairs will be in some cases
… But when the team nominates chairs and there's some delay, the information may not be reflected
+1 to the requirement
Florian: I'll write a PR to add chairs to charters