A couple more sanity checks for after a proposal has been accepted: - Clean up any code examples to follow the proposed API - Provide migration instructions, see wiki for example BEFOR / AFTER format
Jody > Hi all, > as we spoke about in the meeting, the idea is to enforce some process > to better control what's going on in trunk, to make it a viable > place to work against. > > The idea is that if one works against trunk, he should be able to do > so in order to improve things, not about correcting other people > bugs or quick designs throwed in. > > So, the idea is that every API change/addition requires: > * a wiki page with detail about design, principle, whatever > is the driving idea, and about its implementation too > * a jira issue that refers the wiki page, where discussion > about the change is held > * a voting process, where PMC members do vote on the jira > issue, the usual way. > > To avoid delays and lack of interest stopping evolution, > we suggest the following: > * 3 days after the proposal, changes can start on trunk unless there > is already a negative comment which has not been addressed > * 15 days after the proposal, if no negative votes are there blocking > the process, the change is automatically accepted. > > This should give us the right balance between a too slow process, > and one totally uncontrolled. > Please provide feedback or vote :-) > > Cheers > Andrea > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
