We expect contributors to abide by our underlying Code of Conduct. All discussions about this project must be respectful and harassment-free.
Remember that communication is the lifeblood of any Open Source project. We are all working on this together, and we are all benefiting from this software.
It's very easy to misunderstand one another in asynchronous, text-based conversations. When in doubt, assume everyone has the best intentions.
If you feel anyone has violated our Code of Conduct, you should anonymously contact the team with our abuse report form.
All issues labeled ready for dev and bug are up for grabs. Please note that issues with the Forem team label are internal tasks that will be completed by a Forem core team member.
PRs without an associated issue may still be merged, but the core team will focus on changes that solve existing issues. We strongly encourage creating an issue before working on a PR!
When in doubt, ask a core team member by mentioning us on the issue.
Documentation is almost always a great place to start contributing to a new project. Forem is an Open Source, community-driven project. Therefore, providing and maintaining quality documentation is one of our most important jobs. You can find more information in our docs guide!
Refactoring, which involves improving the code without modifying behavior, is a great place to help out! Generally speaking, you can rely on existing tests to ensure that your refactor doesn't introduce any unexpected behavior. If an area isn't well tested, you might be asked to include a regression test with your refactoring PR. Refactors can touch many files, so we encourage breaking big changes into small PRs.
Fixing bugs is a super fast way to improve the experience for our users! When you're fixing bugs, we appreciate communication in a GitHub issue. If an issue exists, please claim that issue and link it in your PR, otherwise creating an issue is the best first step! Be sure to surround bug fixes with ample tests; bugs are magnets for other bugs. Write tests around bugs!
Features tend to be subjective and might spur some debate. The Forem core team uses an internal RFC ("request for comments") process to assess and prioritize new features. This process is intended to provide a consistent and standardized path for new changes to enter the Forem ecosystem. If you'd like to propose a new feature, please visit forem.dev to start a discussion around a new feature (or chime in on a pre-existing discussion!).
There may be some open issues in our repository that we think evolve into impactful features. For such issues, we use the potential RFC label in order to highlight the potential feature to the Forem core team members so that someone from the team can champion that feature.
You can learn more about our internal RFC process and how we use forem.dev here
git checkout -b USERNAME/some-new-feature-1234git commit -m 'Add some feature'git push -u origin USERNAME/some-new-feature-1234Nobody's perfect. Something doesn't work? Something could be better? Check to see if the issue already exists, and if it does, leave a comment to get our attention! If the issue doesn't already exist, feel free to create a new one. A core team member will triage incoming issues.
Please note: core team members may update the title of an issue to reflect the discussion.
Some areas of the project could use updated tests, and new features should always include test coverage. Please give our testing guide a read!
We use Code Climate to find code smells. If a pull request contains code smells, we might recommend a refactor before merging. We like readable code, and encourage DRY when it's reasonable!
More importantly, we avoid wrong abstractions. Code quality tools are not perfect, so don't obsess over your Code Climate score.
If the change you're proposing touches a user interface, include accessibility in your approach. This includes things like color contrast, keyboard accessibility, screen reader labels, and other common requirements. For more information, check out the Forem Accessibility docs page.
Inclusion and respect are core tenets of our Code of Conduct. We expect thoughtful language all the way down to the code. Some technical metaphors are alienating or triggering. We ask that contributors go the extra mile to submit code which is inclusive in nature.
If you unintentionally use language deemed harmful, there is no shame. We will work together to find a better alternative. Being thoughtful about language also encourages more thoughtful code!
References/Closes/Fixes/Resolves #123, where 123 is the issue number. More info here.Please note: a core team member may close your PR if it has gone stale or if we don't plan to merge the code.
All community pull requests are reviewed by our core team.
After you submit your pull request, one of the members of the core team will review your code.
Please avoid force pushing unless you need to rebase with the main branch.
If feedback is provided, any changes should be contained in new commits. Please don't force push or worry about squashing your commits.
Force pushing (despite being useful) has some drawbacks. GitHub doesn't always keep the review history, which results in lost context for the reviewers.
We squash every PR before merging, so there is no need to force push!
We are all humans trying to work together to improve the community. Always be kind and appreciate the need for tradeoffs. ❤️