Pull Request Process ​

Pull Requests (PRs) are a fantastic way to contribute back to the project. It's one of the fastest ways to see a bug fix or new feature you care about land in the platform.

Reviewing and maintaining community submitted code is a very time consuming process. To ensure the core team can give every PR the tender love and care it deserves, and not let valuable PRs go stale, we require that:

Every pull request must be in answer to an existing open Issue.

We use GitHub Issues as a living to-do list of tasks to work on next. Each PR resolving a related issue ensures that it aligns with the core team's planning and long-term goals. Please leave a comment on the issue related to your PR so you can be marked as the assignee. This ensures no one else will accidentally work on the same issue at the same time.

Choosing What to Implement ​

We welcome PRs for any Issue. Issues labeled "Community" have been identified as good improvements or fixes for community members, as they're often a little more scoped in what they affect. This in turn makes it easier to implement the change and review the work. Issues labeled "Good First Issue" are typically easier to resolve for those who haven't contributed to the codebase before, and are therefore a great starting point.

Implementing an Accepted Feature Request ​

If you're looking to implement a feature request that hasn't been converted to an issue yet, please contact the core team through a comment on the feature request before starting work. There's probably a good reason it isn't ready-to-be-implemented yet (unknown timelines, conflicts with other projects, blockers, etc). By collaborating early, we ensure your PR can be merged as efficiently as possible!