As the GeoServer project has gained more and more traction, the community of people behind it has grown beyond the initial hardcore GeoServer developers, which is great.

Undoubtedly, there exists a tension between “I need to get this done quickly for project/client A” and the bureaucracy of the project. Clearly we don’t want the latter to get in the way of potential contributions, however, contributing to an Open Source project goes beyond the pure contribution and requires to share the workload needed to keep the project going. The "dump code and run" attitude should not get traction unless we want to drown in unclosed bug reports and disgruntled user community (both will likely harm the project in the long run).

I'm going to propose some baseline principles and code of conducts for contributors, leaving the individuals to follow them as they fit and (once accepted) the community to enforce them as we go. The idea is to raise awareness about community involvement while promoting informed contributions, the goal being, once again, to raise the quality level of the project and fairness among the involved parties. In my mind this is sort of an extension of Ian's "Earning your support instead of paying it" presentation (for those that haven't seen it yet, http://www.ianturton.com/talks/foss4ge.html#/ ), but geared towards developers.

With this in mind, here's what I'd like to propose a minimum set of points to spur discussion on the subject (and eventually lead to a proposal). There are different expectations based on the role of the individual in the community.

From our documentation:

• "The PSC is made up of individuals who are intended to represent the various communities which have a stake in GeoServer. "
• "Turnover is allowed and expected to accommodate people only able to become active on the project in intervals"

One thing that is probably not written but that has also been a stake through the years, is that the core modules are maintained by the PSC itself.

With this in mind, minimum responsibilities:

• Participation to votes and proposal discussion, active participation to discussions on geoserver-devel, within the limits of individual abilities and areas of expertise (e.g., we don't expect a user representative to be knee deep in the code, or force someone knowledgeable about tile caches to share an opinion on map reprojection performance)
• As a maintainer of the core modules, active participation to the user list (no minimum activity required, just being subscribed and aware that some help to the users is expected, at least regarding core modules)
• As a maintainer of the core modules, check and review pull requests (no minimum activity required)
• As a maintainer of the core modules, some support in the bug tracker to verify tickets validity and fix bugs as time allows (again, no minimum activity required, just acceptance of the principle, e.g., a PSC member cannot ignore the ticket tracker)
• As a maintainer of the core modules, keep an eye on the build servers and help figure out non obvious failures
• As a maintainer of the core modules, provide some help with releases (does not mean one has to ever be release manager, someone is a management position can delegate to others in his/her organization, a user representative can provide some help with testing artifacts, or write release blog posts, and so on)

Extension modules have an explicit maintainer tasked with caring about the module (this is a minimum requirement to push the module to extension status).

With this in mind, minimum responsibilities:

• Active participation to discussions/proposals on geoserver-devel within the limits of what can affect the maintained module (proposals touching the module as a direct or side effect, questions about the module)
• As a maintainer of the extension modules, check and review pull requests involving the maintained module
• As a maintainer of the extension module, active participation to the user list, within the limits of the maintained modules
• As a maintainer of the extension module, some support in the bug tracker to vet tickets validity and fix bugs as time allows, within the limits of the maintained module
• As a maintainer of the extension module, keep an eye on the build servers and help figure out build issues happening in the module maintained

No minimum participation requirements again, although if the current maintainer shows prolonged lack of activity, the PSC should consider looking for another maintainer or demoting the module down to community level.

Contributors going through proposals or otherwise making significant changes to the codebase should be responsible for their own work, in particular:

• Active participation to discussions/proposals on geoserver-devel within the limits of the areas contributed to
• Active participation to the user list at least within the limits of the potential consequences/effects of their changes Keep an eye in the bug tracker to vet tickets validity and fix bugs as time allows, for anything that might be a side effect of their contribution

No minimum participation requirements again. It is also ok not to accept the above responsibilities at all, provided there is some sponsor in the community that accepts being the responsible party for those changes. Large/risky changes with no responsible party willing to meet the points above should be rejected, this is crucial for the future of the project.

Every other contributor to the project, even for small changes, is warmly invited to take part in the community and keep an eye on the user list and bug tracker There is however no minimum requirement, not even at the principle level, it's a simple "we'll love you if you do, but we don't demand it"

With the above in place I hope companies and professionals interested in participating to the community will understand what actually being involved means, and setup their expectations accordingly.