[Adium-devl] Trac changes re milestones, etc.

[Jordan Schelew]

I read through the meeting log from last night and have some  
suggestions/comments on it.

I like the idea of only having items in the milestones that developers  
actually plan to fix or implement, it makes much more sense  
considering Evan was really the only one even close to following them  
anyway.

I believe that this will essentially leave Trac being only useful for  
submission of regressions and long time issues. I see no reason to  
continue to accept feature requests through Trac; we may as well just  
have them only entered by a developer (since they will be the only  
ones to work on them anyway). We obviously get very few people  
supplying patches and we don't need Trac or tickets to allow them (or  
even really to help them to do so). We've really been treating (nearly  
all) enhancements like this from the start anyway by shovelling the  
majority of them into "Good idea for later" (which I think we should  
remove as a Milestone and close existing non-assigned tickets, as that  
would go along with this new plan quite nicely).

Separate from that suggestion, we need to decide what to do with  
defect reports. They're coming in at too high of a rate for Robby and  
I to handle - I had midterms and couldn't do any work on them for the  
last couple weeks and now they've compiled to over 100 tickets. We  
simply don't have the man-power to work with all of them. This is one  
of the reasons why I think it might be a good idea to stop allowing  
general user submission of tickets - it's simply hindering our ability  
to find ones that are real legitimate bugs. Those that have real bug  
reports will often seek us out via email, IRC or the Forums and then  
WE can create the appropriate report with all useful info.

These are just a couple of suggestions that I think go hand-in-hand  
with the discussion last night. We need Trac to highly support every  
developer's bug-fixes and enhancements that they actually want to work  
on, and not simply be a massive database of useless reports and  
suggestions that will never feasibly or realistically be implemented.

Jordan