Provide guidance for projects maintained by a single organization looking to submit to OSSF Sandbox

[mlieberman85]

Current lifecycle requires all projects including sandbox to have maintainers from more than one organization. This can lead to issues where a well intentioned organization that doesn't have a lot of connections within the community looking to contribute a project have no way to do so.

There are a few potential solutions including:

1. Provide guidance on how an organization can court more community involvement
2. Update lifecycle to allow for single organization maintained projects to submit to sandbox but would have some timeline on OSSF community bringing in other maintainers to the project, or something like that.

[steiza]

I think one of the things the OpenSSF excels at is bringing folks together from different orgs to address common challenges. I recognize that we want the sandbox stage to be an easy on-ramp, but I'd rather see us improve (1) and help newcomers engage with the broader community.

[lehors]

I don't think the requirement of 2 maintainers from different organizations is too high a bar.

The reason we have this requirement is to prevent organizations from taking advantage of OpenSSF to advertise their project as being part of OpenSSF even though it may not have any support beyond their own organization.

Organizations interested in bringing a project to OpenSSF have plenty of opportunities to advertise their intentions and should be able to get someone interested enough to sign up as a maintainer to meet the requirement. If they don't then it's probably not a good sign.

[david-a-wheeler]

@lehors - I understand. One drawback is that it may be hard to get that second organization because "they're not in OpenSSF yet", so the members of a second organization might not participate or review until it's done. I fear adding this requirement may create a chicken-and-egg / Catch-22 / deadlock situation.

[lehors]

@lehors - I understand. One drawback is that it may be hard to get that second organization because "they're not in OpenSSF yet", so the members of a second organization might not participate or review until it's done. I fear adding this requirement may create a chicken-and-egg / Catch-22 / deadlock situation.

Just to be clear: We're not adding anything, it's already there. The question is whether we should remove it. :-)

[SecurityCRob]

This has been a hard requirement since the beginning. I do not feel that we should change it. @lehors points out the reasoning why. If someone is interested in donating, they should consider showing up and participating in our groups and growing a community of new contributors from our current ranks or folks that aren't members (yet).

[david-a-wheeler]

@SecurityCRob - fair enough!

If we keep it as a hard requirement, maybe we can write guidance for those projects on growing their contributors outside their organization. E.g.:

Sandbox requires more than one participating organization. We recommend doing the following to gain more maintainers (especially if there's currently only one organization acting as a maintainer):

• Show up and participate in our groups' meetings, especially those relevant to the proposed project. Ask ahead-of-time to modify meeting agendas so you can give a brief overview of the project, its goals, and indicating that you're looking for additional maintainers.
• Announce your proposal in relevant OpenSSF Slack channels and mailing lists.
• Identify and contact specific potential maintainers (even if they aren't currently involved in OpenSSF) and ask them to participate. If they can't due to time constraints, ask them who they might recommend.

[jkjell]

Provide guidance on how an organization can court more community involvement

If the effort is not too time consuming, I think it would be great for the TAC to provide feedback on the below Sandbox requirement. That feedback shouldn't be considered a definitive acceptance but, it could help avoid projects that are blatantly unrelated from pursuing membership or encourage borderline projects to adjust their focus.

Projects must be aligned with the OpenSSF mission and either be a novel approach for existing areas or address an unfulfilled need.

Additionally, creating an issue template for WG repos to allow presentations could be a great forum for new projects to spread awareness. This template from CNCF's TAG Security requires a sponsor for the group to accept the presentation.

[mlieberman85]

I agree with @lehors and @SecurityCRob and most others in saying we shouldn't reduce the requirement. We might want to do more to point folks in the right direction on how they might transform to do the right things to become ready for acceptance into OpenSSF.

For example what @jkjell mentioned.

[sevansdell]

I also believe the sandbox requirement should not be reduced below two maintainers. For the guidance, I believe we can add a sentence that hyperlinks to another page on: navigating the openssf to gain more contributors and understand alignment. The additional context should point to the MVSR, the Secure Software Guiding Principles, and a description that discusses how to navigate the website to understand the different WG, and how to get on those WG agendas to introduce themselves and request interest from more contributors. Perhaps the DevRel team could help with this, as I believe members of that group were working to develop an overview of each WG and how to best figure out how to determine alignment of interests to WGs. We could use also create/add WG roles and responsbilities, one of which is to provide guidance and feedback to orgs requesting sandbox alignment that don't have more than one contributor.

[mlieberman85]

I've been working on some notes. Hope to have a basic doc a little later this week. FWIW, we do have a couple of TIs like https://github.com/ossf/s2c2f that are only maintained by a single org. We should also really look to resolve this.

[mlieberman85]

https://docs.google.com/document/d/1AsAneAtaPjevXxV1zqSWsTm93ALQ4Oy9W8z5wPy_808/edit?usp=sharing

[SecurityCRob]

Mike gave us a really good proposal to review in TAC PR 267, please review and provide feedback.

[lehors]

This was addressed by PR #267