Contribution Workflow & Best Practices for Newcomers
Note: This is an unofficial guide written from a community member’s perspective to help newcomers understand the contribution workflow and some best practices. It is not an official project policy or guideline. If you’re unsure about anything, please ask the maintainers/community for the same.
Hey newcomers, welcome to the community! 
We truly appreciate that you want to contribute to the project and help it grow. To make collaboration easier for everyone, here are a few contribution best practices based on some common issues we’ve noticed.
Common Contribution Issues We’ve Noticed:
1. Creating a PR without an issue
Some contributors directly create a PR without first creating an issue for it. This makes it harder for others to understand what problem the PR is solving and whether someone else is already working on it.
2. Multiple issues for the same problem
Sometimes, multiple people discover the same bug and create separate issues for it. This creates duplicate discussions and makes the issue tracker harder to navigate.
3. Creating a PR without being assigned
Some contributors create a PR for an issue that has already been assigned to someone else. This can result in multiple people working on the same task without knowing about each other.
4. Multiple PRs for the same issue
Multiple contributors sometimes create PRs for the same issue without coordinating or dividing the work between them.
This creates unnecessary duplicate work. Since GitHub may automatically indicate that a PR will close an issue, someone looking at the issue may therefore assume that the person who has raised the pull request have already solved the problem, even though it hasn’t actually been solved yet.
Recommended Contribution Workflow:
To avoid these problems, please follow this simple workflow:
1. Find the Right Issue Before Starting Work
There are generally two ways to find an issue to work on:
-
If you have found a new bug or problem: Check whether a similar issue already exists. If it doesn’t, discuss the issue with the community as described in Step 2. If an existing issue already covers the problem you’ve found, don’t create a duplicate. Instead, add any useful information you have to the existing discussion.
-
** If you are searching for an issue in the GitHub Issues section: Especially as a newcomer, it is generally advisable to look for issues labeled
good first issue. These are typically intended to be approachable for contributors who are new to the project and can be a good way to get familiar with the codebase and contribution process.
2. Discuss the issue with the community
If you’ve found a potential bug or problem, discuss it in our Slack channel first whenever possible.
This helps confirm whether the behavior is actually a bug or intentional. It also lets the community know that you’ve found the issue and are interested in working on it, which helps prevent duplicate issues.
3. Create the issue and ask for assignment
If the issue doesn’t already exist and the community confirms it is valid, create the issue and ask to be assigned to it if you’d like to work on it.
This makes it clear to everyone that you’re working on the task.
When creating an issue, please provide clear and detailed reproduction steps so that others can understand and reproduce the problem. Include relevant logs, screenshots, or a screen recording where applicable.
4. Check before starting work
Before working on an issue, check whether someone else has already been assigned to it.
If someone is already working on it, don’t create another PR immediately. Instead, coordinate with them and ask if they need help. You may be able to contribute through testing, documentation, debugging, or another part of the implementation.
5. Create the PR
Once you’re assigned and have completed your work, create the PR and clearly mention/link the issue it addresses.
Explain what you changed and, if applicable, include before-and-after screenshots or a screen recording. This makes it easier for maintainers and contributors to understand your changes and review the PR.
If multiple people want to work on the same issue, coordinate and divide the work instead of addressing it separately.
Note: Please keep each PR focused on the specific issue it addresses. Avoid including changes that go beyond the scope of the issue. If you identify an unrelated issue while working, consider creating a separate issue and PR for it.
6. Prepare Your PR Before Asking for a Review
Once you raise a PR, please make sure you follow these 2 points before you ask for a review from reviewers or maintainers:
-
Wait for all required tests to pass. If a test fails and you believe it is unrelated to your PR, ask in the community if others are facing the same failure instead of ignoring it.
-
Address all bot/AI suggestions. If a suggestion is valid, explain how you will address it and make the required changes. If you disagree, explain why the suggestion is not applicable. Only mark a suggestion as resolved after it has been properly addressed.
If you’re asking for a review of a pull request or discussing an issue with someone in the community, always include the relevant pull request or issue link so reviewers or maintainers can directly navigate to it.
Please don’t repeatedly tag or spam reviewers or maintainers. Give them at least 2–3 days to respond before following up, as they may be busy with other contributions, work, or community responsibilities.
In short: Make your PR review-ready first, then ask for a review and be patient.
The Simple Flow
When in doubt, remember:
Search → Discuss → Create/Join Issue → Get Assigned → Work → Create PR → Address AI Suggestions(If any) → Ask for a Review
The goal isn’t to add unnecessary rules or slow anyone down. These practices simply help us avoid duplicate work, keep GitHub organized, and make it easier for everyone to contribute.
Most importantly, don’t hesitate to communicate with the community. Open-source contribution is a collaborative process, and good coordination is just as important as writing code.
Happy contributing! 
