Brent: Meeting under CoC. Be nice.
Brent: The AB has been looking at
potentially radical ways to adjust the process and WGs for a
while. Our meeting in April continued that movement. Ian has
been working on a document that will be shared with the AB
tomorrow.
... it will be shared soon with this group
... ideally at the next CG call
<brent> subtopic: https://github.com/w3c/process/pull/937
<brent> Github: https://github.com/w3c/process/pull/937
Florian: Is this under discussion in the AB?
Tess: We're not actively discussing it.
Hober: This change seems like it should be under the AB's auspices, then to ask the Process CG to implement it.
Brent: There was information that we expected the team to provide.
Florian: The Team has said they
can't share that information.
... I think the AB should take this up (because not a change to
bylaws, but rather a change to Process).
... we also need an operational way to talk to Member Reps if
they remain distinct.
Brent: Assuming we have time on the AB's agenda to talk through issues, I will make sure we talk about this issue.
(Some discussion about delegation of rights.)
<brent> subtopic: https://github.com/w3c/process/pull/1129
<brent> Github: https://github.com/w3c/process/pull/1129
Florian: We've been talking in
the PSIG about non-participant contributions.
... currently the expectation is based on "who creates the PR"
instead of "who comes up with the idea"
... PSIG has not yet made a decision
... they raised 2 sub-problems
... if it's a class 3 change, we need to add the person to
grant a license.
... if it's a new feature, not only must we ask but we must
secure the license.
... the point that was made is that this is a must without an
"or else"
... if we want a license but don't have one we may need some
flexibility (e.g., reject outright or kick off a PAG)
... another question relates to tooling -- if a submitter is a
participant in a WG, we don't ask them if somebody else made up
the idea.
... We could add language that when you contribute you will
indicate that you are the author of the work or, if not, who
is.
PLH: We don't block on pull requests from individuals who are employees of Members who are in the group
<tidoust> Ian: Is the question about essential claims?
<tidoust> ... If I'm contributing something and someone else had the idea, I do have a disclosure obligation.
<tidoust> Florian: Only if you're aware of a patent.
<tidoust> ... For group members, patent policy makes them license patents in the end.
<tidoust> ... For others, we ask them to agree with the patent policy when they submit a change request, nothing happens if the change request is made by a group participant on behalf of the non-participant.
<tidoust> ... The disclosure obligation is only when you're aware of the existence of a patent, not about hypothetical cases where there might be a patent.
<tidoust> Ian: There are also non-members who have essential claims on things we do.
<plh> How Pull Requests Get Handled
<tidoust> ... The reciprocal grant usually helps there.
<tidoust> ... What you're saying here is that this would be enough for this case.
<tidoust> Florian: I think it's not a fatal risk, but a bit of a weakness that could be fixed easily.
<tidoust> ... At least we'd get the opportunity to know that somebody else helped author.
<tidoust> Ian: The PR could just say: disclosure obligation when you contribute something. Elsewhere, we could look into guidelines.
<tidoust> Florian: Going further probably requires a PSIG discussion or an AB discussion.
<tidoust> Brent: So next step is getting feedback from PSIG.
(Ian adds a comment https://github.com/w3c/process/pull/1129#issuecomment-4671276228)
<brent> https://github.com/w3c/process/issues?q=is%3Aissue%20state%3Aopen%20sort%3Aupdated-desc
<brent> subtopic: https://github.com/w3c/process/issues/817
<brent> Github: https://github.com/w3c/process/issues/817
<tidoust> Brent: Is this something we need to keep looking at?
Florian: There are affiliation
constraints on the TAG and AB but they are different, and it's
not obvious why.
... for the TAG there is a grace period "until the end of the
term" but for the AB it's only "30 days"
... people have different views on more lenient (TAG) or less
(AB)
Tess: Arbitrary differences in process are a source of confusion.
Tess: I like unambiguous text.
Florian: I am suggesting we keep "next election" as deadline, and if not resolved, we choose randomly.
Tess: I am ok with a backstop (but wish it weren't necessary)
<tidoust> Ian: What's the longest amount of time that might go by?
<tidoust> Tess: A year.
Tess: Given disparity, making the
timeline more liberal for the AB doesn't affect them
materially, but shortening the time for the TAG might annoy
them (since not here)
... Maybe 90 days would be a reasonable compromise between the
approaches.
[Francois leaves]
<scribe> ACTION: Florian to create a pull request to harmonize TAG/AB handling of affiliation changes, borrowing specifics from AB and leaning lenient.
<brent> subtopic: https://github.com/w3c/process/issues/810
<brent> Github: https://github.com/w3c/process/issues/810
(We review the history of how TAG appointments originallyworked)
Tess: In the name of simplification, we could revert to the previous approach (Team appointed)
Florian: I think the AB was brought into this situation as a backstop (e.g., tie-breaker). But the way that was implemented does not work to address that.
Tess: I agree that a design
principle here is resilience to misbehaving.
... it takes a long time for the team to appoint seats, and
we're adding complexity to that already difficult process.
PLH: When we first tried this
approach, there were attempts to veto individuals (based on
affiliation)
... the staff got the communication wrong.
... the timing of the election makes conversations difficult
before the first TAG FTF meeting after an election
... I would be +1 to remove the AB out of the loop or make them
the escalation path in the case the Team and TAG can find a
solution.
... We also need a higher bar for vetos.
Florian: I am ok with the AB out
of the loop / AB as escalation path.
... or maybe it shouldn't be the AB? (E.g., AC appeal)
Tess: In general, my principle is
"how are members in the drivers seat" but in this case, I would
prefer that the team simply be able to make appointments
unchecked.
... We made adjustments to the appointment process to do a
better job at achieving diversity of views.
... I think we could delay appointments so there is time to
detect what gaps needs to be filled.
... in the very rare case where the team would appoint someone
wildly inappropriate, we have bigger problems.
plh: I like Tess' approach, but I
would amend it so that the TAG can appeal (e.g., to the
AB)
... If we keep the vote with the TAG, it does put the team in
an awkward position, because we see votes.
... we may not be able to justify decisions because we can't
share some information.
Florian: This feels like an AB discussion to me.
Brent: Yes, the broader conversation. I think this particular conversation.....
hober: I think it's fair to ask the AB to discuss. Regarding a backstop to a bad appointments, FOs are possible for any decision.
<plh> Ian: is the scope of who can formally object is the TAG?
Tess: We could make the decision AC appealable.
<plh> plh: that sets the bar for appeal to be really high
Florian: Rationale for objections about a person may not be easily shared with a large membership.
<scribe> ACTION: Tess to raise the topic of revising the team appointment to the TAG process
PLH: Please also talk to the TAG after the discussion!
<brent> subtopic: https://github.com/w3c/process/issues/804
<brent> Github: https://github.com/w3c/process/issues/804
Florian: Do we want rules?
https://www.w3.org/community/about/process/compare/
Tess: We have different kinds of
groups with different characteristics.
... with the exception of CGs, the team isn't involved in
evaluating ideas. It seems to already the case that "which kind
of group" is part of the decision.
... I'm disinclined to add rules where we've not seen a
problem.
Ian: I would strongly prefer to have flexibility to make a decision based on context.
Florian: I propose to close the issue.
[No objections]
Tess: I suggest the closing comment include a link to the comparison of group types
<plh> "A W3C Recommendation is a specification or set of guidelines or requirements that, after extensive consensus-building, has received the endorsement of W3C and its Members."
24 June