-
Notifications
You must be signed in to change notification settings - Fork 0
Development Pull Requests Policy
This policy is intended to make collaborative development for Tau Labs as efficient as possible. To achieve this, we try to keep the time from request to resolution as well as the number of open requests as small as possible. This benefits authors, reviewers and users as well. Authors will be encouraged to contribute more and will be able to scope their work easier, reviewers will be less looking at the same code and users will get new features and bug fixes quicker.
When you submit code by creating a pull-request it is your obligation to prove that your code is good to merge. You as the author have to find someone willing to invest time into reviewing your work and finally being partly liable for it by judging about its quality and even eternalizing that fact by actually executing the merge. As author you have no right to demand anything from anyone and it is in your own sense to do whatever possible to ease the review from the reviews point of view.
- Pull request should be focused on one specific feature / bug fix / problem. The smaller the scope, the better. The less scope mixing, the better. Try to make commits as atomic as possible to ease merging as well as review. Consider splitting up big features into multiple requests.
- Keep in mind while writing and commenting your code that someone will have to review it. The better job you do at making clear what you are doing, the faster you will get through review.
- Never mix formatting fixes with semantic changes within a single commit.
- Write a proper summary and include potential pitfalls for the reviewer to ease his job.
- Bugfixes (one bug per request)
- New features (one feature per request)
- Request for comments (if explicitly stated)
- I don't like color xyz, so i changed it to abc
- I don't like name of variable abc so i changed it to def
- Changes without proper logical reason
After submitting a pull-request, one or more core developers will go through your code and write comments. The quicker you answer those comments and change mistakes or clarify things, the sooner your code will be merged. You can always add commits to a running pull request. Just push them to the branch which is going to be merged.
When the review is done, the reviewer will write a summary of his findings and vote for merge or close, sometimes adding conditions to that (e.g. something has to be fixed, before merge). When there is consensus between author and reviewer that code will not be merged in the current state and has to be redone, the request will be closed. When there is a simple majority of core developer vote to merge or close, the request will be merged or closed accordingly.
If a pull request has been reviewed and is stuck because issues need to be addressed or the author not resolving issues, the request will be closed. It can be reopened again later. This keeps the list of pending requests open to actionable items.
Generally it it sensible to not merge your own pull request.