Welcome! We're glad you want to contribute to our project! 💖
If anything doesn't make sense, or doesn't work when you run it, please open a bug report and let us know!
- Ways to Contribute
- Join our Community
- Finding an Issue
- Setting Up a Dev Environment
- Asking for Help
- Pull Request Lifecycle
- Code of Conduct
Since this is a very small project with only a handful of files there are just a few kinds of contributions we anticipate:
- Bug fixes (spelling corrections, broken link fixes, accessibility improvements, etc.)
- New content (a new template, or an addition to an existing template or guide)
- Content revision (changing existing text in a template or guide)
Anyone interested in this project or the OSPO is welcome to join our Slack Workspace and/or come to any of our coworking sessions These are casual, drop-in-if-feel-like it sessions where you can:
- Get help with a PR for this repo
- Ask questions relating to OSS in general, your campus OSPO, or the OSPO network
- Get help finding a project to work on, or getting more contributors for your own project
- Or just have a dedicated time to work on your projects or to tackle those important-but-often-postponed admin tasks
You never need an invite to join us. In fact, we want you to join us, even if you don’t have anything you feel like you want to contribute. Just being there is enough! You don’t have to turn on your video. The first time you come, just introducing yourself is perfectly fine. Over time, we hope that you feel comfortable voicing your opinions, giving feedback on others’ ideas, and even sharing your own ideas, and experiences.
If you see an issue that you'd like to work on, please post a comment saying that you want to work on it. Something like "I want to work on this" is fine. Please do wait to be assigned the issue before working on it to make sure we're on the same page!
Follow these steps to fork and clone the repo.
The best way to reach us with a question when contributing is to ask on:
- The original Github issue
- Our Slack community
- Our coworking sessions
Submit your pull request when you have a working implementation that addresses the issue or feature request. Your code should be tested and ready for review, even if you're open to suggestions for improvements.
- Use Draft PRs when your work isn't ready for review
- Convert to Ready for Review when your implementation is complete and tested
Create a branch from the latest main branch. Use descriptive branch names like add-template-name or fix-broken-link.
We prefer small, focused pull requests that address a single issue or implement one feature. Large PRs are harder to review and more likely to conflict with other changes. If your feature is large, consider breaking it into multiple PRs.
[TODO: edit/remove this section as makes sense for your project ]
- Remove "Draft" status when ready for review
- Ensure all CI checks are passing
- Include a clear description of what the PR does and why
- Link to relevant issues using "Fixes #123" or "Addresses #456"
Initial Review Timeline: Expect an initial response within 5-7 business days. Complex PRs may take longer.
Follow-up Reviews: After addressing feedback, expect follow-up responses within 3-5 business days.
- After pushing changes, add a comment like "Ready for re-review" or "@mention" specific reviewers
- If your PR hasn't been reviewed after the expected timeline, feel free to politely bump with a comment
- For urgent fixes, mention the urgency in your comment
If your PR appears stalled:
- First, check if all feedback has been addressed
- After 1 week of no activity, add a polite comment requesting status
- If still no response after another week, reach out to us (see: Asking for help)
If you can no longer continue work on your PR:
- Comment on the PR explaining the situation
- Maintainers may either:
- Take over the PR and push additional commits to complete it
- Close the PR and create a new issue for others to pick up
- Close the PR if the change is no longer needed
- Small follow-up changes should be addressed in the same PR when possible
- Larger follow-ups or new issues discovered during review should be handled in separate issues/PRs
- Use "TODO" comments sparingly and create follow-up issues for any deferred work
After merge, your changes will be available immediately in the main branch.
Questions about the PR process? Feel free to ask in the issue comments, discussions, or reach out to the maintainers directly.
Please read and abide by our Code of Conduct