Closed ianbjacobs closed 2 years ago
For W3C Members, my mental model was that the AC rep was the one who signed the CLA and approved the participation of an individual in a CG. The steps above only talk about the participant (and possibly lawyers). Would the AC rep be involved?
A Report is either a Specification (can be implemented) or not. This status does not change over time.
Who decides that? Is the idea that, as soon as a Report can be "implemented", it is a Specification? Is it up to CG participants? If so, couldn't CGs be tempted to create non-Specifications to start with (because it's easier to setup), which would probably create a sort of a mess once they realize that legal should have been involved? In other words, I wonder whether introducing another layer of licensing commitments to simplify participation wouldn't actually make things more complex down the road.
Hi @tidoust,
I agree with your mental model. I had neglected to mention that in the write-up.At a high level, the commitment is made by the party we expect to make the commitment, which might be the AC Rep or the individual. I have just added some bits but more thought is necessary.
Regarding "Who decides the Report is a spec?" That is left to the group. I think they know when they are creating something for implementation versus, e.g., a set of requirements or use cases.
You wrote: "If so, couldn't CGs be tempted to create non-Specifications to start with (because it's easier to setup),..." In this model CGs are all easy until we need more commitments. So I don't think it's easier to set up type A or type B.
re Report-as-Spec, I think an important part of the guidance we can give CG would then be that a CG Report that was not managed as a spec (i.e. for which IPR commitments were not collected) is unlikely to be taken up on the W3C Rec track, or will face significant hurdles doing so.
I worry about the complexities this mode would add, unless we can distinguish much better among the types.
Currently, there's a basic consistency among CG outputs, that they all have contributor commitments. Someone looking to join or to use a CG product knows its terms without looking further, and knows it was designed for Rec-track compatibility. If CGs have subtypes, there's at least one more step to figure out, and potential later-evident incompatibility.
I'd be interested to hear where the CLA has or is expected to pose a problem in practice.
- Upon first contribution (via GitHub pull request) to a Report, the system prompts the user (or their AC Rep) to make a commitment. ...
- The participant also agrees that the commitment applies to future contributions for this repo.
I can imagine a contribution being made outside of a Github repo, e.g. in an email, in IRC, in Slack, or even in a verbal conversation. If we think the commitments are important, a fence around Github is not enough.
since we use CGs for more than Rec-track targetting deliverables, it creates friction for these groups; for instance, requiring patent licensing commitments before people be able to join the PWE/IDCG, or the Process CG seems counterproductive with the goals of making these groups as welcoming as possible when they don't actually need any of that licensing.
More generally speaking, there are many many more people interested in joining any group (spec producing or not) than there are people IPR-contributing to spec work - by shifting the commitment to the time it's actually needed, we would lower the bar to community building.
I can imagine a contribution being made outside of a Github repo, e.g. in an email, in IRC, in Slack, or even in a verbal conversation. If we think the commitments are important, a fence around Github is not enough.
The IPR repo manager lets one document other contributors beyond the pull request author (using the +@name
convention
I can imagine a contribution being made outside of a Github repo, e.g. in an email, in IRC, in Slack, or even in a verbal conversation. If we think the commitments are important, a fence around Github is not enough.
The IPR repo manager lets one document other contributors beyond the pull request author (using the
+@name
convention
Which depends on human intervention at each contribution, including a human who knows about the convention. That seems like a less robust fence than the current tooling offers.
I get the desire to be more welcoming and lower friction. I hope we can find a way to do that. I'm just highlighting the holes in this proposal. :-)
Which depends on human intervention at each contribution, including a human who knows about the convention. That seems like a less robust fence than the current tooling offers.
You're assuming that the contribution made over email, IRC, Slack or a verbal conversation would be clearly & explicitly covered by an IPR commitment - a non trivial assumption. I don't disagree that the IPR fence is only as good as the contributors make it, but at least with the github bot, it's relatively in the face of the contributor.
since we use CGs for more than Rec-track targetting deliverables,
What name might we give this distinct type of group?
I think I would weigh the cost of introducing yet-another-group-type much higher than the cost of streamlining the existing workflow around the group type we have.
(note that we we also have WGs that don't produce Rec-track documents)
You're assuming that the contribution made over email, IRC, Slack or a verbal conversation would be clearly & explicitly covered by an IPR commitment - a non trivial assumption. ....
I am. Perhaps that comes from the IETF - which makes it quite clear that "contributions" come in many forms, including verbally. (Admittedly, they have a different set of IPR rules, though I'm not sure that matter for this purpose.)
When we launched the CG program we created a mailing list for contributions (with "-contrib" in the name) and linked it from each group's home page. I believe we've stopped that practice because people weren't using them. We mention these lists in our FAQ [1], but not in our patent and copyright summary [2].
I don't think we should forbid contributions through other mechanisms than GitHub, but I think we should make it really easy to manage them through GitHub and encourage people to use that mechanism.
[1] https://www.w3.org/community/about/faq/#i-am-a-participant-how-do-i-make-a-contribution [2] https://www.w3.org/community/about/process/summary/
I don't think we should forbid contributions through other mechanisms than GitHub, but I think we should make it really easy to manage them through GitHub and encourage people to use that mechanism.
Agreed. (And yes, lets stop creating -contrib lists and close any that are empty).
Presentation on this topic: https://docs.google.com/presentation/d/1wa13icDSu5H9czJl5yLXLKEpiPtPNKiC7pjzyNNosDc/edit
When we launched the CG program we created a mailing list for contributions (with "-contrib" in the name) and linked it from each group's home page. I believe we've stopped that practice because people weren't using them.
I think it would be useful to delete any -contrib
lists which do not contain any contributions (ie ignore test messages and the like).
Not sure if this is on-topic but it is related.
I frequently see people who were enthusiastic abou a CG and didn't join it. I ask them why "Oh I joined already, ages ago".
People frequently confuse the "expressing support for creation of a CG" with "joining". Sadly this often means some of the most enthusiastic think they already joined.
Suggested fix - auto-subscribe all those expressing support, when the CG is created. Send an email on list creation. Those few whose position is "create this list, I'm not interested though" can unsubscribe if they wish.
Hi @svgeesus,
Regarding "auto-join":
if we maintain an ipr-commitment-on-join model, then this would not likely work for a large number of participants
Hmm, yes I see.
If we retain an ipr-commitment-on-join model, my second choice would be an automatic email sent to all supporters, thanking them and giving a "join" link (which might need to be forwarded to their AC Rep)
@svgeesus,
We already do the auto mail to all supporters on launch with the join link. Here's an example: https://lists.w3.org/Archives/Public/public-council/2021Feb/0000.html
We say in the template of that mail: "Please note that supporting a group is different from joining a group. Supporters must also enroll if they wish to participate."
Hi all,
Through a conversation with Jeff Jaffe, here are two additional considerations for this proposal:
1) When people sign the CLA upon joining a group, their communications (e.g., via email) that end up in a Specification could reasonably be considered Contributions. If we move the commitment to later (and only through pull requests), there is less of an argument that such communications were already covered as Contributions when they were made. (This may have been a point that @samuelweiler was making, but I was not sure so I am restating it here.)
2) When someone has a Contribution in hand to make and needs to go find lawyers to make the commitment, they may not want to bother and instead might ask others already in the group to do pull requests with their content.
Ian
We have addressed the mechanics of "someone makes a commit with someone else's contribution" in the contributing.md files -- tag the actual contributor in the pull request.
This proposal tees up the policy question whether we want commitments before informal idea-contributions, at the risk of losing the would-be discussants, or want to secure later explicit commitments from among a potentially larger pool.
This proposal did not gain traction, so closing it.
Hi all,
Based on previous ideas and discussion with @dontcallmedom, this is a proposal to make it easier for people to participate in CGs.
Assumptions:
Participant commitments:
Benefits:
More comprehensive contribution story:
More potential improvements: