Vampire code merging

Recently I was thinking about the different version control workflows that various projects use to manage contributions to their source code.

1. Open source style

This is the traditional style most open source project maintainers use.

  1. Contributor creates pull request
  2. Maintainer reviews pull request
  3. Maintainer approves or rejects pull request
  4. If approved, maintainer merges the changes into the project

This workflow places the full control of what changes make it into the project on the side of the maintainer. Slight variations of this workflow can be used to encourage ownership of these changes and may help foster additional contributions to the project in the future. For example, a workflow that I’ve come to call “the vampire merge style”.

2. Vampire merge style

I’ll admit that this name sounds a bit scary. However, this is a project maintainer technique that can be beneficial when it comes to building the open source community that backs a project.

The main idea behind this style is that the contributor is the “owner” of the changes that they are making. Because of this, it is up to the contributor to make the final decision to merge their code changes into the project. Here is an example of this workflow:

  1. Contributor creates a pull request
  2. Maintainer reviews pull request
  3. Maintainer approves or rejects changes
  4. If approved, the maintainer grants the contributor permission to merge code changes into the project
  5. If approved, and if the contributor thinks the changes are ready, then the contributor merges them in

The reason I call this “vampire style” is because your code can’t enter the repository until it is invited. The main difference between the vampire style and the typical open source style is the difference of code-ownership. This style promotes adding new people to a project and this encourages the involvement that is crucial in the open source ecosystem.