The open source projects I work on follow a philosophy I describe as “talk first, code later.” I think this is a good way to develop software in general, and I want to take a moment to talk about the benefits of this approach.
Avoid hurting feelings
Start by discussing the most important reason you want to make a change is to avoid hurting feelings. I often see a contributor submit a PR behind closed doors, only to find his hard work rejected. There can be a bunch of reasons for this: THE PR is too big, the PR doesn’t follow the local style, the PR fixes a problem that isn’t important to the project or has recently been indirectly fixed, etc.
The root cause of these problems is a lack of communication. The goal of the “Talk first, code later” philosophy is not to hold you back or frustrate you, but to make sure a feature lands correctly the first time without incursion into massive maintenance debt. Either the author of the change, or the censor, when a change pops up and suggests, “OKAY, I’m done, all you have to do is merge it, right?” “Talking first saves them from carrying the emotional burden of hurting their feelings.
How should the discussion proceed?
Every new feature or bug fix should be discussed with the project maintainer before work begins. It’s ok to experiment privately, but don’t send changes without discussing them first.
For simple changes, the definition of “discussion” can be just a design sketch in a GitHub topic. If your PR fixes a bug, you should link to the bug it fixes. If not, you should propose a bug and wait for the maintainer to confirm before sending PR. This may seem a bit backward — who doesn’t want a bug fixed — but given that the bug could be a misunderstanding of how the software works or a symptom of a larger problem, it needs further investigation.
For more complex changes, especially feature requests, I recommend distributing and agreeing on a design document before sending the code. It doesn’t have to be a complete document, sending a topic and a sketch may suffice, but the key is to agree on the words before you write them in code.
Under no circumstances should you continue to send your code until the maintainer agrees that your approach is satisfactory to them. Pull request is everyday life, not just in time for the holidays.
Code review, not design by committee
Code review is not the place to argue about design. There are two reasons for this. First, most code review tools are not good for long comment sessions, GitHub’s PR interface is terrible at this, and Gerrit is better, but few teams of administrators maintain Gerrit instances. More importantly, there was disagreement during the code review phase, indicating that there was no agreement on how to implement the change.
Discuss the code you want to write, and then write the code you discuss. Please don’t do the opposite.
Via: dave.cheney.net/2019/02/18/…
By Dave Cheney (lujun9972
This article is originally compiled by LCTT and released in Linux China