Meeting minutes
Pull Requests to Review
Clarify what a registry is made of
github: w3c/
florian: Follow-up from a previous PR
… Nigel had pointed out that there's some confusion about what a registry *is*
… had various "associations" but doesn't say what it consists of
… referencing specifications aren't *part* of the registry
… you still have a registry without such specs, it's just useless
plh: Any other comments/questions on this PR?
RESOLUTION: Merge #818
ACTION: Florian, check with Nigel if the issue can now be closed.
Improve consistency of document status names that use the word "Draft"
github: Improve consistency of document status names that use the word "Draft"
-> Improve consistency of document status names that use the word "Draft"
florian: We have a bunch of statuses that include the word "Draft"
… older ones end in "Draft"
… two new ones have "Draft" at the beginning
… but then prepend "W3C" and it's no longer at beginning or end, which de-emphasizes it
… I think the only reasonable options are do nothing, or put at the end
… because longstanding statuses like "Working Draft" have it at the end
… Putting at the end makes sure the word "Draft" is noticeable
… unsure if we have consensus
TallTed: Putting Draft at the end means Draft is the most important word in the label
… putting at the beginning makes it an adjective that modifies noun that follows
… what you want to find is the thing, whether draft or not, but not looking for all drafts
<plh> https://
<TallTed> those names leave off implied elements
plh: Do you expect to change pubrules?
fantasai: Yes, that's the point
florian: worst is "Group Draft Note", where the word "draft" is in the middle and de-emphasized
… we already have a confusion with status of documents published by W3C, people think they are standard/official even when not
… important to emphasize Draft
… if we decided from scratch maybe we'd put Draft at the front, but we can't rename everything at this point
<TallTed> several Rec Track (for instance) leave out "Recommendation", e.g., "Draft Recommendation", "Discontinued Draft Recommendation"
<plh> fantasai: +1 to this pull request
<plh> ... we need to be consistent
<TallTed> "Working Draft" is the most odd-one-out, as it's a compound noun
cwilso: Naming preference, but have to agree with Ted, if you put Draft at the beginning it's harder to skip
cwilso: Everything we work with is drafts, makes it clearer this is a status
… but not worth losing sleep over
<Zakim> fantasai, you wanted to respond to cwilso
<plh> fantasai: you'll get "W3C Draft ...."
<plh> ... so you won't get the effect that you're looking for
florian: Renaming in Process doc is not hard. Renaming in publications is a lot of churn
plh: Because the PR only renames Draft note and Draft Registries, we have very few of those, so won't create a lot of pain in our groups
<TallTed> The inviolable "W3C" prefix is certainly troublesome.
plh: We started with "Working Draft"
… then added "Candidate Recommendation Draft"
… "Snapshot Candidate Recommendation" would sound weird
<TallTed> "Snapshot Draft W3C Candidate Recommendation"
plh: Then we added Draft Note and Draft Registry without thinking much about consistenci
… I'm OK with the PR, can check with Webmaster about deployment
florian: Overall, I'd be OK with a variety of things, but -1 on rename everything. Not worth the churn.
<cwilso> "W3C Note Draft" sounds official and endorsed. "Draft W3C Note" much less so.
plh: Same. It's a lot of work.
TallTed: I won't lie down on the road on it. In some ways it seems like a lot of thing being churned, so better opportunity than many
<plh> fantasai: we'll introduce a lot of confusion in the community if we do a general renaming.
TallTed: these two renames seem worth doing to bring in line with the rest
cwilso: I'm not going to lie down on the road on this one. The more I think about it, W3C note Draft sounds official and endorsed, wherease Draft W3C note much less so
… I would prefer to leave as outlier and not be consistent, but that's my vote but not an objection
florian: I think there's maybe 2 strong -1 against changing everything
… so deciding between changing or not doing anything
plh: Difference between note and draft note is up to WG, really
… for Draft Registry, major difference compared to Registry because opposite ends of registry track
… but for Note, not much different
plh: I'm 0 on this, don't feel strongly about the change
… can flip a coin or ask for more feedback
… I think in the end people will not care much
fantasai: I think we can resolve on 2 options, and not others
florian: We'll resolve on those two and then wait a cycle or two to get feedback
plh: Issue was brought by Shawn, from staff; and Nigel also weighed in
PROPOSED: For Issue 779, we will *either* make no change *or* adopt PR #819 to put "Draft" at the end for Note and Registry tracks.
RESOLUTION: For Issue 779, we will *either* make no change *or* adopt PR #819 to put "Draft" at the end for Note and Registry tracks.
Confidentiality Levels and Redactions
github: w3c/
florian: I don't think the wording in the PR is quite right
… but I also can't figure out what Josh is *trying* to solve
joshco: Nigel asked the questions that came up to me
… unclear to me what is expected to happen
… are people actually doing this, is it actually happening?
plh: Nigel was asking, what is the issue associated with the PR
… where you trying to address an actual issue?
joshco: It was while I was reviewing the text, I didn't understand what it was expecting
florian: [quotes text]
… you expanded in order to explain it
… but it's wrong, not supposed to use redaction for confidential information to make it public, supposed to not make it public
… Team has procedures for changing confidentiality levels
… The sentence is more general, it's making reasonable effort to maintain confidentiality
… How is context-dependent
… so I think your clarifications aren't correct. Whether we need other clarifications, I don't know
joshco: The audience of this is not the people who are deciding the confidentiality level
… this is about readers of the document should respect the confidentality level of the document
florian: That would be a clarification to the first point
… respecting appropriate level of confidentiality
… second point is about applying proper care
… is that reasonable?
joshco: Yeah
florian: OK I'll try to come up with a PR
Issues to Discuss
Charter review process
plh: What's the status? Any follow-up from the AB?
florian: I feel that the AB didn't so much have a negative to reaction to the specifics of the proposal, but a reacted to "more rules? that feels like a lot! we have so much process already do we need all this"
<cwilso> +1
florian: which makes me think I was bad at presenting it, because it doesn't actually introduce a lot of rules?
… so I think we need to make sure the proposal is expressed in a brief way
… I don't think it's a lot
… but it requires better phrasing, and I haven't done that yet
… Maybe once it's phrased in a way that is simpler people will like it, maybe not
cwilso: Agree with Florian's assessment
… also negative reaction to adding more process, but also agree it wasn't actually very much more process
… just making sure that it's clarified how things plug in
… I think we should keep this on the plate, I think it's a good idea
… need to figure out how to make it more acceptable
plh: With my Team hat, I came out of this session as "we have a communication problem"
… that should be my first priority
… not that we don't need changes to Process
… but communication issue is more urgent
… best next step would be PR against Process, to make it clear that it's not complicated
florian: Agree. Need to make a first draft which will be too long, and then simplify. :)
<cwilso> +1
[some discussion about problems that we run into during chartering; Florian and plh both agree this would reduce such problems ]
Process 2024
plh: AC meeting April 8-9
… ideally we present our proposed major changes to the AC at this time
… but we don't really have any such changes atm, just minor fixes
… I believe the ongoing discussion around resolving FOs and issue 580 will take several months
… I don't expect us to have anything concrete before TPAC
florian: Agree, and given experience with AB, we need to be able to explain very crisply.
… If we're not ready to do that, it's not going to be a useful discussion.
plh: We have to decide when to ship Process 2024
… do we prepare a Process for the summer?
… and iterate over the rest?
florian: My preference would be to extend by ~ 6 month so we present at TPAC rather than AC
… and ratify after TPAC
… Might end up early 2025
… last few years we had big changes that were needed, and needed to release earlier
… I think better to reduce number of cycles
plh: I'm ok with that. Good chance we can make good progress on this one issue, TimBL's participation in Council
florian: Also a few adjustments to Council based on current Councils
plh: 580 is longer term, I'd be surprised if we're ready by TPAC
fantasai: We might be able to get it ready by TPAC, if Florian and I can draft up in April and we can refine through spring/summer
plh: Change wrt abstaining on TAG/AB decisions is maybe urgent?
florian: It's a good rule, but not urgent. Only affects votes, not decisions by consensus.
… and so far we've only had decisions by consensus in the Councils
plh: Council dismissal votes being public?
florian: Haven't had a chance yet
plh: OK, so let's defer decision to ship new Process until TPAC
New Issues
The minimum time commitment for participation in the elected bodies is
github: w3c/
plh: My problem with such expectations is enforcing them.
… e.g. we used to have Good Standing rules, and the groups didn't enforce them anyway so we removed them
… so unless groups are willing to enforce, unnecessary to put rules
florian: Intent wasn't to have rules, but to have "authoritative guidance" about reasonable expectations
plh: Key word is "Guidance", that's not a change for Process
… need to figure out where to put guidance
cwilso: I don't think Process need to lay out something informance
… but we need guidance that gets taken seriously
… and that needs to be sent along with the Team's call for nominations
… it should lay out expectations for people who sign up
plh: Would be helpful if TAG would provide a job description
florian: including the workload
plh: Helpful for candidates to evaluate whether they want to run or not
cwilso: that's what Tess was saying: the TAG charter used to do that, described the job of TAG
… so now that we don't have TAG charter, we need to put that somewhere else
… though agree it wouldn't go in the Process
cwilso: Maybe move this issue to AB since not Process
nigel: Talking about expectations and job descriptions, dancing around fact that these positions are self-funded
… there's diversity implications there as well
plh: no objection to move to AB
florian: in favor
… AB documents in a wiki page, and might not be official enough; maybe /Guide is better
… but can hash that out in AB
<cwilso> I don't disagree with Nigel, and note https://
fantasai: so proposed resolution to move to AB?
florian: define somewhere, but not Process
plh: and AB can talk to TAG about job description
RESOLUTION: Move #820 to AB
Chair should be required in charter
github: w3c/
plh: I'm open to to this additional requirement
… for Team Contacts, I would have a different position, but for chairs makes sense to me
nigel: I mentioned on the issue, I think what's important is we have alignment on who gets to choose and what we require
… if it's not an AC option because Team has authority, then doesn't make sense to put it in
cwilso: Sure, but you can formally object to any Team Decision--including chair choice
… so you can FO a chair, and easiest to do this all at once
… it is still a Team choice, but it would be easiest--and I would have the highest confidence that has chairs listed for a new group
… it would be best to align that
plh: +1 to cwilso
… if we have an FO against a particular individual that gets tricky
… haven't had that case so far
… recent charter with lots of feedback on proposed chairs
plh: Team should also update /Guide wrt picking chairs
nigel: I think at this stage, I think we should remove chairs from charter reviews
… deciding whether work should go ahead
… separate explicit communication from Team wrt chairs
… then really clear what the decision is
… so separate, but parallel
plh: At time, and I think we won't have time to solve today
florian: We also have had problem that we put someone as chair in the charter, but they didn't become the chair because their company didn't join the group
plh: ok I'll add to agenda for next call
… see you all next time
Meeting closed.