I do frequent rounds to Github to contribute to small projects or libraries I find useful. Generally my contributions come from issues I have had with the project, and identified a fix. Last year I made my first attempt to write my own jQuery library. Not meaning to make anything big, this was just something I would like to use for myself and thought about hosting it on github to feed my self-worth. It played pretty decently, and I noticed a few people using it as well. But something didn’t feel quite right.
Recently, I made another attempt. This time I wanted to keep things organized. I had realized that there is a difference between an Open Source project, and a well maintained Open Source project. As a developer, I would hate to rely on a project that is being least cared about the original author; unless I’m using it for a garage project. So what is it that makes a project well maintained?
I started working on Jello a few weeks ago. And here are the few things I made sure I followed. I might be stating the obvious here, in which case you are free to fly over to some more interesting stuff on the internet.
Here is a quick checklist:
- **Add every feature you wish to implement as an enhancement in the issue list.
** This helps you and your audience keep track of your progress, and you don’t miss out on crucials. Remember, people looking at your half-baked project can easily take a look at reported enhancements to know where your project is heading.
- Create project milestones, and add issues to milestones.
Milestones can be scheduled. This gives your audience a clear idea about what to expect, and when. Once milestones are closed, these can be easily referred to create change logs. 3. **Close or Fix issues with commits.** This leaves less ambiguity in your commits. Your audience now knows what just got fixed and how. 4. **Assign yourself on any open issues you are planning to address.** This develops a sense of responsibility among contributors. Unallocated issues are bound to remain on the backburner, esp. when there is a volume of issues coming up. This also prevents any parallel planning during development. 5. **Isolate the master branch from your development branch.** Agree or not, there can be a lot of half baked commits, reverts that you would not want on your master. It would just confuse your audience. A dev branch will make it easy for contributors. They can remain care free with their commits. 6. **Mark releases.** Your audience might prefer to have the luxury of choosing an older build, as opposed to the latest one. Marking releases makes your development more reliable. 7. **Go through some pain to write a contributor guideline.
** A good project will demand more than one contributors, and to make the on-boarding easy make sure you put a readme for your prospective contributors. Contributors should be instructed to describe their commits in details for pull requests to be merged.
I will be trying to update this checklist as I proceed. Feel free to get back to be on twitter @omtalk, with any feedback, suggestions or rants.