- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 21 May 2024 01:15:04 -0400
- To: public-w3process@w3.org
Summary of Resolutions: * The Process CG resolves to adopt PR 851, and seeks approval from the AB https://github.com/w3c/w3process/pull/851/files https://pr-preview.s3.amazonaws.com/frivoal/w3process/pull/851.html#group-lifecyle * Merge PR 862 https://github.com/w3c/w3process/pull/862 * Merge 860 https://github.com/w3c/w3process/pull/860 Full minutes: https://www.w3.org/2024/05/08-w3process-minutes And also pasted below for search... ======================================================================= W3C – DRAFT – (MEETING TITLE) 08 May 2024 Agenda. IRC log. Attendees Present cpn, cwilso, fantasai, florian, plh, seth Regrets - Chair - Scribe cpn, fantasai Contents Pull Requests Issue 580 #862 #860 Issues #861 #852 #823 Summary of resolutions Meeting minutes Pull Requests Issue 580 <plh> Github: w3c/w3process#851 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://www.w3.org/2024/03/charters-in-dev.html <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/w3process#862 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/w3process#860 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/w3process#861 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://fantasai.inkedblade.net/weblog/2011/inside-csswg/process +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/w3process#852 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/w3process#823 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 Summary of resolutions The Process CG resolves to adopt PR 851 Merge 862 Merge 860 Minutes manually created (not a transcript), formatted by scribe.perl version 221 (Fri Jul 21 14:01:30 2023 UTC). Diagnostics Succeeded: s/take action/take action, e.g. in chartering case/ Succeeded: s/If they feel/Here, if the Team doesn't make an edit and people feel/ Succeeded: s/strange/strange when we're talking about a group of 20 in total/ Succeeded: s/Fantasia/Fantasai/ Succeeded: s/tocwilson/to cwilso/ Maybe present: [several, Fantasi, Ted All speakers: [several, cpn, cwilso, fantasai, Fantasi, Florian, PLH, Ted Active on IRC: cpn, cwilso, fantasai, florian, plh, TallTed
Received on Tuesday, 21 May 2024 05:15:21 UTC