In 2004 when the sipXecs source code was first released to SIPfoundry, the developers agreed to divide the source code into 9 distinct projects. We then decided that if these projects were going to be successful, then someone was going to have to be the point-person for each project to make sure they were well kept. We came up with the role "Project Maintainer". It was exciting to be declared a "Project Maintainer".
Since 2004 folks have come and gone and now many of the 34 distinct projects don't really have a clear "Project Maintainer". So the question has come up: Should projects try to find a new "Project Maintainer"?
Before we answer that question, it's worth taking a looking back. Some projects prospered having a "Project Maintainer" others did not. I could go into detail about each project but I don't think that it's actually necessary and here's why. I discovered something truly amazing being a part of the sipXconfig project that I never experienced before. The more unit test coverage a module got the more contributors that module saw, The more contributors a module saw the better the APIs got. The better the APIs got the more reusable the module was. The more reuse the module got the more bugs were discovered and fixed. These things can be considered the definition of success by most measurements.
I also discovered that code without unit test coverage had contributions were often stalled or rejected because "Project Maintainers" were always in fear of holding the bag on contributions that introduced bugs while not advancing their employer's goals. Contributions were unjustified risks as we all strive to be lazy programmers.
I am of the opinion that sipXecs's governance needs to advance, but I'm not sure I'm of the opinion we should repeat the decisions we made back in 2004 by declaring "Project Maintainers" in light of what I learned about unit testing since then. Without these unit tests in place, "Project Maintainers" will inevitable find themselves in a position where they're putting their employer at risk taking contributions that are not unit tested.
The unit test coverage on the codebase varies between each project. It all depends on the precedence that was set by the "Project Maintainer". We're therefore is a position where projects without a "Project Maintainer" will suffer.
I'm making an unofficial proposal (because I haven't completely thought it through yet) that we should consider finding "Unit Test Sheppards" for each project. A "Unit Test Sheppard" has established a productive unit test environment for a project so contributions can begin to flow. Projects can skip right past needing a "Project Maintainer" and jump right to "Community Owned". It's like going from mid-evil times straight to a democracy and skipping feudalism. Somehow the job title "Unit Test Sheppard" is less attractive though. Visions of shoveling sheep manure come to mind. Yet is remains an attractive solution to our problem. Once a project is seeing improvements, bringing back the concept of a "Project Maintainer" might make sense, but more as a role of visionary or leader instead of self satisfying dictator. That visionary will probably be self-evident by the newly prosperous project community.
BTW: Russ Herrold had a response here
ReplyDeletehttp://orcorc.blogspot.com/2010/09/unit-test-shepards.html
He points out some of the details about proper unit test management which would come into play once a project has established a unit test environment. Some of our projects don't have that yet. Some projects have unit test rigging in the makefiles and a handful of tests which is a start.
Russ also points out "capture by the employer" problem. For me, the solution is not with the employer asking for the wrong things nor with the developer having to make the wrong decision on employer v.s. community. Instead, developer needs to create a healthy environment to empower others in the community to contribute there code and mitigate the risk back to their employer thru unit tests.
Setting a global mandate would mean there is a PM already established that can enforce this and we don't really have that yet.