Project Governance

This page currently serves as a discussion around MisterHouse project governance. As the project leaders, who are undefined at this point, reach rough consensus on the governance model and roles; this page should become the documented record of how the project is managed, the responsibilities of defined contributor roles, and the current owners of those roles. As such this page will be in flux early, should stabilize over time, but will always be subject to revision as the project leaders change their governance approach and their roles.

##Recent History The MisterHouse project leadership languished a bit for the past couple of years. There has been some activity from individual developers but with the absence of Bruce Winters the project lost its one person Benevolent Dictator and Release Manager. Recently a new leader, Lieven Hollevoet, has emerged as a project shepherd pulling several much needed altruistic developers and contributors out of the mail list shadows. Lieven successfully moved the development to GitHub opening up a whole new world for contributions. With the sudden renewal of willing contributors for development, documentation, and user support along with an abundance of vocal leaders; the MisterHouse project is now in need of a replacement governance policy. Project decision making for over half of the project lifetime has resembled a Meritocratic Governance Model. The project had taken on this characteristic even before the departure of Bruce and is likely a good model going forward.

A great introduction into open source governance models can be found here: Governance Models

##Governance Model Choice The project is currently being run using a Meritocratic Governance Model or something closely related. This is not by intent but rather a result of the cooperative nature of the contributors and current GitHub repository owner.

Anyone with an interest in the project can join the community, contribute to the project design and participate in the decision making process. ...

Anyone can become a committer; there are no special requirements, other than to have shown a willingness and ability to participate in the project as a team player. Typically, a potential committer will need to show that they have an understanding of the project, its objectives and its strategy. They will also have provided valuable contributions to the project over a period of time

If anyone has a better definition for the MisterHouse project or wants to define a unique governance model then let's discuss it.

##Contributor Roles One of the primary goals for this page is to define primary contributor roles. This should help volunteers identify with the work they perform and hopefully drive a sense of ownership in the process. The MisterHouse project needs committed volunteers that will help define how MisterHouse is developed and distributed to users. The intent of these definitions is to ultimately bring consistency in how the project operates; one of the hallmarks of a successful open source project.

HELP WANTED Each of these roles is open and in need of volunteers. In addition the definitions themselves are in need of customizing to the will of the MisterHouse project leaders. Please discuss and update these roles to fit our vision for the MisterHouse project. Finally if there are volunteers for some parts of these roles but none willing to take on the entire role, then by all means divide up the definition to a subset that is acceptable.

Each of these roles has a definition in the Meritocratic Governance Model. We could adopt the OSS Watch definitions as is or redefine these roles.

###Architect ###Developer ###Documentation Contributor ###Release Manager There are lots of things that could be included or excluded from this role but at a minimum the role entails:

• Participating in discussions about release timing, features for release candidates, stability before a release, etc.
• Managing the "stable" branch for each release
• Managing a release status page showing the current releases and next planned release
• Generating various formats and posting documentation to various locations
• Generating various formats and posting release archives to various locations

Most of the process for the tasks here have already been documented on the Release process of a new stable release page. Developers are available to work with the release manager to define how each step is accomplished and and provide written processes. This role is mostly a project management role with some time to execute predetermined git, ssh, and scp commands (i.e. basic Linux shell). This role does not require development skills.

###Evangelist ###User

##Current List of Assigned Contributors