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
