+1. That looks great, Andrea. Can you please put this on a wiki page? Kind regards, Ben.
On 05/04/16 01:48, Andrea Aime wrote: > Hi, > > with this mail I want to put on the table a basic notion of minimum > community/software responsibility and participation. > > 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. At the same time I believe it is time that we > clearly point out the implications of contributing to an Open Source/open > community project like GeoServer for the sake of clarity and collaboration. > > 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. > > *PSC members* > > >>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 module maintainers* > > > 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. > > *Other contributors providing large changes* > > 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. > > *Any other small contribution * > > 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" > > *Closing words* > > 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. > > > Cheers > > Andrea > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > Geoserver-devel mailing list > Geoserver-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > -- Ben Caradoc-Davies <b...@transient.nz> Director Transient Software Limited <http://transient.nz/> New Zealand ------------------------------------------------------------------------------ _______________________________________________ Geoserver-devel mailing list Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
