Why bother having a process for proposing changes to your open source project? Why not just let people do what they’re doing and merge the features when they’re ready? Well, you can certainly do that if you’re the only person on the project. Or maybe if it’s just you and a few friends.
But if the project is large, you might need to coordinate how some of the changes land. Or, at the very least, let people know a change is coming so they can adjust if it affects the parts they work on. A visible change process is also helpful to the community. It allows them to give feedback that can improve your idea. And if nothing else, it lets people know what’s coming so that they can get excited, and maybe get you a little bit of coverage on Opensource.com or the like. Basically, it’s “here’s what I’m going to do” instead of “here’s what I did,” and it might save you some headaches as you scramble to QA right before your release.
So let’s say I’ve convinced you that having a change process is a good idea. How do you build one?
Decide who needs to review changes
One of the first things you need to consider when putting together a change process for your community is: “who needs to review changes?” This isn’t necessarily approving the changes; we’ll come to that shortly. But are there people who should take a look early in the process?
Read more at OpenSource.com
