[postgis-devel] Tickets

[Kevin Neufeld]

I too think it's a good idea.  It follows the typical scrum agile software development methodology where one has a 
backlog of tasks that are picked through to make up the current sprint, or in our case, the current release.
-- Kevin

Chris Hodgson wrote:
> Paul I nearly suggested a "future" milestone when you originally 
> complained about this problem, but then I thought that it was the fact 
> that the tickets were "open" that bothered you. I think that a 'FUTURE' 
> milestone is a good idea, and perhaps should be the default for feature 
> requests/improvements.
> 
> I think other projects (I know mapserver does) propose the list of 
> things to include in the next release, rather than using trac 
> exclusively to plan the roadmap. But really, if you have a "future" 
> milestone, I can't see why trac can't be used to define the roadmap.
> 
> Chris
> 
> Paul Ramsey wrote:
>> On Wed, Nov 11, 2009 at 2:57 PM, Mateusz Loskot <mateusz at loskot.net> 
>> wrote:
>>  
>>> For WKT Raster, I've recently started submitting tasks from our roadmap
>>> as tickets on Trac, as preparation for development works, because:
>>> - tickets can be assigned, then it's clear who does what
>>> - tickets draw a timeline of development, past and future
>>> - tickets archive discussion on particular topic on single page,
>>>  it's easier to keep it focused, so clear to reader and maintainer
>>> - tickets directly link to events in source tree
>>> Does the sanity thing mean we should stop using Trac for the purposes
>>> described above?
>>>     
>>
>> No, because you are creating tickets that are going to be assigned,
>> completed and closed. These are "wouldn't it be nice if..." tickets.
>>
>> I think having a FUTURE milestone might help. I want to be able to
>> take a numbered milestone and *close* all the tickets and then
>> release. Instead I have to re-negotiate the same set of tickets that
>> are of low priority each and every time and push them forward and
>> forward and forward. I'd rather have people argue for putting
>> particular tickets *into* a milestone than have to argue about moving
>> tickets *out*.
>>
>> P.
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>   
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel