So the plan so far: 1. Create a Wiki page on the proposal 2. Create a JIRA for the proposal with a link to the Wiki page 3. Jira should be blocker and be in the Proposal category 4. Wiki page should provide link to its associated JIRA (include Jira?) 4. If the Jira is not discussed within 2 weeks it is accepted because everyone likes it :) 5. Comments should be primarily on Jira for notification purposes 6. Updates to the Wiki page should be mentioned as a Jira comment? 7. Eventually when commenting seems to have stopped/become cyclic a vote can take place
If the process is not followed the proposal will be removed from the code base immediately. Jesse On 12-Dec-06, at 1:11 PM, Andrea Aime wrote: > Jesse Eichar ha scritto: > >>> I agree with you Chris we need some sort of process for making >>> changes to Geotools. Seems to me there keeps being issues where >>> someone sends an email out about some change, nobody is really >>> interested except for that person so everyone just ignores it... >>> Then the change committed and everyone freaks out because they >>> realize that it affect them. I've seen it happen a number of >>> times now. > > Maybe having a GSIP like process with deadlines would be nice. > That is, something like "vote this in two weeks or it'll automatically > be approved". > On the other side, the rule should also be "introduce major new api > without a proposal and you'll get kicked out before even noticing!". > Guess this defends the interest of those wanting changes, and also > those who does not want nilly willy ones. > >>> One thing I've been doing in uDig is making blocker JIRA issues >>> for proposed changes so that they will be either voted down or >>> somehow addressed fairly quickly. It is much better than email >>> in my opinion because it provides a place to look for proposals >>> and you will treat them as proposals rather than just another of >>> my million emails for the day. I like using JIRA as a medium for >>> certain conversations because it is easily organized (easier than >>> email), you can associate issues with releases and categorize >>> issues nicely. Searching through issues is also nicely supported. > > But creating decent documents is not supported. > Sometimes a proposal needs some better formatting because it's > trying to propose something complex (may need pictures too). So I'd > like to have both, jira and wiki page. > Wiki page may disappear all right, maybe we can export the page once > the proposal is accepted/rejected. > The other advantage I see is that wiki is versioned and it's vendor > neutral, we don't have to fight for a file format. > >>> We can create a issue category that is forproposals, and >>> conversations can take place on those items. The one caveat is >>> that the comments are not sent to the list but if you are >>> interested in the report you can "Watch" and then you will get >>> email notification when the issue changes, such as a comment. > > Yeah.... is there any way to configure jira to send comment mails to > the list for a specific category? > > 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
