Update eligibility criteria

[BenJam]

This pull request updates the eligibility criteria in the following ways:

• we remove the '100 stars' proxy for traction and replace it with actual traction (usage) or a history of recent activity.
• we add a requirement that open source projects are not strongly owned by an individual i.e. that they are set up as shared entities on the platforms that host the source code
• we provide a stronger commitment to accept projects automatically if they meet these requirement

Are these modifications practical?

From a technical point of view it should be possible to detect whether the project

• has an SPDX compliant licnce, and whether it matches our criteria (github, gitlab)
• is owned by a user or an organisation (github, gitlab)
• has a recent (12 months) history of activity (github, gitlab)
• is a fork of another project (github, gitlab)

The dependents and maintainers questions are not answered by github or gitlab but Libraries.io provides both https://libraries.io/rubygems/bibliothecary

From an administration point of view, could we handle the additional traffic and could we provide an adequate degree of AML with this kind of setup? I think so, but I'm more than happy to discuss...

[BenJam]

@alanna I've added an edit of the eligibility criteria here diff view. I wonder whether there's anything regarding the traction requirement that is legally necessary?

I know that being able to automatically accept any project may result in more registered projects with no activity, and may cause problems if we don't take measures to avoid 'domain squatting' etc. but I would like to do this once we have those changes in place on the platform.

[alanna]

There's no legal requirement to only accept projects with traction, but there is a legal requirement to ensure OSC is not laundering money or being used for scams. All money flowing through OSC must be used on genuine open source projects, and OSC holds expenditure responsibility to ensure that's the case. The eligibility requirements should be a tool to support OSC to fulfill that duty. I think you're going to get slammed with large numbers of applications from groups where it will be hard to verify authenticity and you'll need capacity to deal with that in other ways.

You could move the checkpoint from allowing money in, where it is now, to allowing money out, which is really where the compliance rubber hits the road. If the plan is to lower barriers at the outset and raise the bar on reviewing expenses, it could work, but you'll need more ops capacity because the current team reviewing expenses can't handle a huge increase in its current form.

[BenJam]

You could move the checkpoint from allowing money in, where it is now, to allowing money out, which is really where the compliance rubber hits the road

I'm of the option that if there's a project, with an appropriate license, and some valid development/usage (which I need to add), someone willing to contribute and someone requesting to be paid then we should be good.

[BenJam]

Updated the policy and the OP with some more information and discussion.

[natehn]

Wondering whether the minimum number of members for a user group can be lower? 25, perhaps? Or maybe even lower.

I think it would be valuable for us to capture group projects in their earlier stages, no matter whether they have an established user base, dependencies, etc., or not.

[BenJam]

looking at the application template for Foundation I don't think there's any reason we couldn't be consistent at least in gathering data from applicants re. licence etc

[BenJam]

@RichardLitt @poohlaga and I have a draft of this for the docs over at https://app.gitbook.com/o/-LWSZizNMEjL8_DrMNdF/s/-MN_ynR0BjrarSoA9Z-A/~/diff/~/changes/Z4Mvft9N2lqLtEBlxdvK/getting-started/acceptance-criteria

[BenJam]

as a note, looking at this we'd need to ask users about:

• licence
• repository url
• evidence of activity / usage
• personal handle/relationshiop to project
• number of contributors/members
• links to governance/onbording docs
• administartor details (invite process)