Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Establish inclusive contribution guidelines for OpenSSF projects #8

Open
marcelamelara opened this issue Oct 22, 2024 · 1 comment
Open

Comments

@marcelamelara
Copy link

marcelamelara commented Oct 22, 2024

From: ossf/tac#330

Many OpenSSF Technical Initiatives (TIs) have been reporting much lower participation than usual lately. While there are many external factors that are affecting participation at the moment, there's a general sense that there are several barriers to a sustained level of participation in TIs:

  • The barrier to entry: There are a lot of TIs, meetings and resources to choose from, which is great! But it also makes prioritization more daunting for newcomers especially, and sustained participation difficult because it's challenging to keep up with everything that's going on.
  • Time/resource constraints: As priorities shift, many long-time and new participants don't always have the capacity to engage heavily. This also places a heavier burden on the smaller number of contributors who are able to prioritize a particular TI. So there need to be more options to engage and contribute in smaller ways, and more clarity around how/which small-scoped contributions might actually help TIs.
  • Consumption or adoption of TI outputs: Many TIs aren't designed or scoped to allow for more incremental adoption, which would enable consumers of OpenSSF/adjacent technologies and frameworks to make steady progress towards implementing OSS security practices.

I propose as part of the DEI WG 2025 roadmap that we, jointly with other WGs and the TAC, establish a set Inclusive Contribution Guidelines, which will document best practices for TIs to address these issues. These would eventually become part of the general project lifecycle process requirements.

These best practices may include:

  • Documenting process for accepting contributions outside of meetings/async and differently-scoped tasks
  • Using a consistent way to advertise areas where community contributions are needed, including "Good First Issues"

Please chime in with other ideas.

@marcelamelara
Copy link
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant