Pull Requests
This section defines the guidelines related to Pull Requests (aka "PRs").
To ensure a fast review and a higher probably of merge, please follow these guidelines when contributing PRs.
Welcome to the team
The development team is a group of people, like you, who contribute to making Linux Mint and/or Linux Mint driven projects better.
Being part of the team isn't an official status, it's a subjective feeling shared among developers.
The more you talk to the other developers, the more you contribute ideas, fixes and new features, the more you and the others will feel like you are central to that team.
If this is your first PR, then welcome to the team :)
Discuss your ideas
If you're not sure your idea will be accepted, get in touch with the other developers on IRC at #linuxmint-dev (irc.spotchat.org) and discuss it before spending time working on it.
Whether a PR is accepted or not has nothing to do with how much time and efforts you put into it. It's better to talk about your design and ideas before focusing on their implementation.
Describe your changes
Give your PRs a title and a description which makes it easy for anyone to understand what it changes, why, and if your design isn't straight-forward, how.
Don't hesitate to explain anything that isn't obvious.
A well described PR is easier to review, to accept, and to merge.
Only do one thing
Your PR should only do one thing, and nothing else.
If you want to do more things, then create more PRs.
Say you're interested in adding a new feature but also in fixing a bug and refactoring some of the code. That's 3 things, not 1.
First, it's 3 times harder to review than 3 separate PRs.
Second, if any of these 3 things is problematic, it will prevent the other 2 from getting merged.
A PR which implements too many things makes it harder for the team to review it. It might take longer to merge and it can even be refused.
Keep it small
Keep your PR small and simple both in terms of changes and scope.
This is especially true if you haven't talked about your idea and/or design before working on it.
Start with a simple idea and a simple implementation. You can always improve it later if it's accepted and merged.
If your PR is going to be big, make sure the rest of the team is aware of it so everything can fit in terms of release cycles, and ongoing work-in-progress affecting the same files.