Making it easier to join CGs with lazy commitment model; copyright only commitments

[ianbjacobs]

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:

• The notion of "CG participant" is useful (for future commitments, automatic list subscriptions, activity metrics, etc.). Note: more work is probably necessary below on how this works in the case of W3C Members joining groups.
• CG Reports are managed on GitHub and participant contributions happen through GitHub pull requests.
• A Report is either a Specification (can be implemented) or not. This status does not change over time.
• Contributions to Reports that are Specifications are governed by the CLA. Contributions to Reports that are not Specifications are governed by the latest version of CC-BY; thus the commitment is lighter.
• We have adequate tooling (e.g., so GitHub knows which people are group participants, which participants have made agreements, which Reports are Specifications, etc.).

Participant commitments:

• The only commitment upon joining is an individual commitment to the W3C code of conduct. In the case of W3C Members, AC reps are notified when an employee joins a CG (rather than require the AC Rep to join the group and nominate the individual). It is important to note there are no IPR commitments prior to contribution, so analogous to signing up to a mailing list.
• Upon first contribution (via GitHub pull request) to a Report, the system prompts the user (or their AC Rep) to make a commitment.
  • If the Report is a Specification, the participant agrees to the CLA. We continue our current practice of seeking organizational commitments to the CLA.
  • Otherwise the participant agrees as an individual to whatever is the latest version of CC-BY. I suggest this because this is a more well-known license than the W3C CLA.
• The participant also agrees that the commitment applies to future contributions for this repo.
  • Note: An alternative, but I'm not suggesting it, is a per-pull request commitment with a checkbox "I also commit for future pull requests".
• Note: We can further reduce friction by only requiring the commitment for substantive contributions (whether substantive in a copyright sense or in a patent policy sense).

Benefits:

• Lightweight (lawyer-free) join process.
• No patent or copyright commitments required for discussion-only groups.
• Lighter commitment for Reports that are not Specifications.
• Per repo commitments. Thus, the CLA commitment could be focused on where someone's contributions actually happen. This might be useful for the WICG and other groups with multiple repos.

More comprehensive contribution story:

• If a WG and CG share a repo, then we could have this sort of behavior for any pull request:
  • If from a WG participant, allow merge without manual intervention.
  • If from a CG participant that has previously committed, allow merge without manual intervention.
  • If from a CG participants that has not previously committed, prompt user for commitment (or AC Rep for W3C Members)
• Furthermore, for any repo (CG-only or WG/CG-shared):
  • If from a non-participant, prompt for the same commitment that a CG participant would make AND give the option of joining the CG at the same time (e.g., via a checkbox). Note: For someone who just wants us to correct a typo, I don't want to force them to have to join the group.
  • If a person wants to join the CG but does not yet have a W3C account, prompt them to create it (and associate it with their GitHub identity during the creation).

More potential improvements:

• In some cases, a participant cannot make a CLA commitment, only their lawyer can. We should allow lawyers to make CLA commitments on behalf of participants. Or, if we are satisfied with assertions by participants, we could at least provide the second participant with information about whom in their organization to contact regarding the approval to contribute.
• Once we have an organization-level CLA commitment to for all future contributions from an organization to a repo, we can avoid the commitment prompt for any participant with an account associated with that organization. This is likely "safe" for Members provided we maintain the AC rep as a gateway. This may be less safe for non-Member organizations.

[tidoust]

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.

[ianbjacobs]

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.

[dontcallmedom]

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.

[wseltzer]

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.

[samuelweiler]

• 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.

[dontcallmedom]

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.

[dontcallmedom]

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

[samuelweiler]

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. :-)

[dontcallmedom]

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.

[wseltzer]

since we use CGs for more than Rec-track targetting deliverables,

What name might we give this distinct type of group?

[dontcallmedom]

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)

[samuelweiler]

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.)

[ianbjacobs]

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/

[svgeesus]

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).

[ianbjacobs]

Presentation on this topic: https://docs.google.com/presentation/d/1wa13icDSu5H9czJl5yLXLKEpiPtPNKiC7pjzyNNosDc/edit

[svgeesus]

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).

[svgeesus]

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.

[ianbjacobs]

Hi @svgeesus,

Regarding "auto-join":

• This is an interesting optimization on top of the lazy commitment model, especially if the only commitment on join is an individual one. I could see providing an option "If the group is created, I wish to join it automatically." And that could even be "true" by default.
• However, if we maintain an ipr-commitment-on-join model, then this would not likely work for a large number of participants (e.g., employees of Members and non-Members). Ian

[svgeesus]

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)

[ianbjacobs]

@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."

[ianbjacobs]

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

[wseltzer]

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.

[ianbjacobs]

This proposal did not gain traction, so closing it.