Improve Open Source Best Practices

[isabelle-dr]

Context & Issue

As we are getting more interest from contributors to this validator, improving some of our open source practices becomes a priority.
Currently, interested contributors don't have a straightforward way of knowing what to contribute, or what the process is. We would like to improve our current process so everyone has a great experience contributing to this project!

Definition of done

When all the user needs are met:

• As an interested contributor, I can see the contribution process for the type of contribution I'm interested in doing
• As an interested contributor, I can see what types of collaboration I could do with this project
• As an interested contributor, I can share my interest to contribute to a new feature and I can see if others are interested in contributing as well
• As an interested contributor, I can see MobilityData's roadmap for the Canonical GTFS Schedule Validator

How will this work?

After looking at successful open source projects and receiving feedback from our current contributors, we identified the following actions:

• An improved contribution guideline that contains:
  • the different types of contributions we need (ex helping with a code review if different from adding a new rule)
  • what should be included in one PR (smaller precise PRs are recommended as opposed to big PRs containing several new functionalities)
  • a code review process where community members can participate
  • a link to the slack channel for contributors that are looking to discuss their feature ideas & find others interested
  • a process for contributors interested to contribute on bigger features, with a PRD template
• a link to the roadmap on the repo
• a more complete issue template (inspiration)
• public sprint planning events and meeting notes that contributors can join
• an automatic message when someone opens an issue or PR for the first time using the Welcome GitHub app (inspiration)
• a list of collaborators and their role in the repo (inspiration)

To do

Must

• Research on existing OS communities
• Draft a first Contribution Guideline and get feedback from the community
• Draft final Contribution Guideline document and add to the GH repo
• run triage of all GH issues open

Could

• (optional) Interview with existing OS community
• add "needs triage" automatically when a new issue is opened
• a message for contributors that are at their 10th / 50th / 100th PR

Materials

• New contribution Guideline (work in progress)
• [Kubernetes governance], (https://github.com/kubernetes/community/blob/master/governance.md)
• Jupyterlab governance
• SkLearn governance

resources

• https://conventionalcomments.org/

[barbeau]

FYI, repos I've worked on have used Google's blunderbuss tool to automatically assign issues to users:
https://github.com/googleapis/repo-automation-bots/tree/main/packages/blunderbuss

You configure like a normal GitHub bot - here's an example config file:
https://github.com/googlemaps/android-maps-utils/blob/main/.github/blunderbuss.yml

We've used it to randomly assign incoming issues to one of the maintainers, but you can also configure it to assign based on the label on the issue.