I’m inspired by the way that the 4paws Rescue Team organizes a bunch of people that don’t really know each other and haven’t really met. It’s mostly through e-mail which is not ideal.

I’m involved in something new, that I haven’t really tried before. I’ve signed up to contribute code and add organization to an open source project. It’s just a small library to handle IP Addresses as objects. Pretty handy for a network automator though.

The original creator did good work. But I suspect his energy level on it isn’t what it used to be and it is at a time like this that I think you need to harness the people who are making code contributions to become maintainers. Bluemonk has started doing just that.

I’ve been putting some thought into how we can design some processes to automate and systematize and generally make the maintenance of the repo take only a few hours a month. Here are the things I think we need to organize a team to handle this project so that it isn’t one man doing it:

• An understanding of what the project is trying to achieve and some amount of philosophical agreement on how do achieve that.
• A group of people who understand the code and are rigorous about quality, but pragmatic in decision making.
• Documentation that helps would-be contributors to source-code to research for themselves how to conform to the quality guidelines.
• A process flow for reviewing PRs and labels to support this flow.
• Automated branch tests for pull requests
• Test coverage reporting for pull requests.
• A github organization so that the repo doesn’t belong to any one of the maintainers. And any of us can manage the Travis CI setup. Bonus: We can also setup groups for mentions to multiple people if we do this.

These are things I intend to put into place for the IPAddress gem to make it easy for a team to spend only a few hours a month on maintenance.

If I can get some time from Bluemonk, I will probably also try to document the release process.

Looking at my list, I realize that it doesn't say much about how to agree on new features or redesigns. Nor does it address how to achieve philsophical agreement. For these, it may make sense to hold a Hangout among the maintainers.