Michal Papis changelog.com/posts

Preserving credit while maintaining open source projects

Working as an open source project maintainer is a big task. I have been doing it for some time for the RVM project thanks to Engine Yard.

Problem

A big part of the maintenance is accepting others code for the project; it is very important to handle it well so the code author wants to get back to us and help again. As much as Ruby community is opensource oriented there are few things that can be improved. It happened a few times to me and other developers that the code was merged into projects without preserving authorship. This is a basic error made by maintainers, so I want to share some thoughts on how I try to avoid that problem when maintaining RVM. This problem mostly happens when the we want to change the commits, but is not limited to it and happens also without changes.

Easy way

When you do not care about number of commits you can merge the commit from Github or using hub and then add new commit on top updating it to proper state mentioning the ticket number in commit:

git commit -m "Formatting ..., update #2195"

For example see https://github.com/wayneeseguin/rvm/pull/2195

Limit number of commits

The most basic method when you want to limit the number of commits is to apply changes from the committer and then commit it using the –author flag. I used this for https://github.com/wayneeseguin/rvm/pull/2238 - getting the proper result with involving author would require too much work as for small commit, so I did the required changes to the code (just changing order of paragraphs) and committed it using:

git commit -m "..., closes #2238" --author "Name <author@email.com>"

It is important that the author matches exactly the original author name and email (from their commits) so it does not confuse others or tools used (like git annotate). Also make sure to mention the pull request (close #2238) so it is automatically closed and your commit is linked with it.

Work with the author

The slowest way is to actually talk to the author and explain to him/her what changes are required to make his/her commit accepted. For example, this happened in https://github.com/wayneeseguin/rvm/pull/2187 where most of the discussions happened on IRC or Skype sometimes in comments. This way the person contributing gets best experience and getting back to coding on your project is much easier for him/her.

MINASWAN

Matz is nice and so we are nice

Most important for maintaining your project is treating other developers with respect. They are human beings. Being impolite just builds a wall and ensures they will not get back to you or your project.

Are there other ways?

Obviously there have to be other ways to handle this. Share your thoughts with us on Twitter.


Discussion

Sign in or Join to comment or subscribe

Player art
  0:00 / 0:00