Re: [Audacity-devel] Patch Tracker WAS Re: Beta_Feedback

[Gale A. <ga...@au...>]

| From "Ed Musgrove" <edg...@wa...> 
| Sun, 1 Nov 2009 21:52:53 -0800
| Subject: [Audacity-devel] Patch Tracker WAS Re:  Beta_Feedback
> > -----Original Message-----
> > From: Gale Andrews [mailto:ga...@au...]
> > Sent: Sunday, November 01, 2009 9:00 PM
> > To: aud...@li...
> > Subject: Re: [Audacity-devel] Patch Tracker WAS Re: Beta_Feedback
> > 
> > 
> > | From "Ed Musgrove" <edg...@wa...> Sun, 1 Nov 2009
> > | 16:04:03 -0800
> > | Subject: [Audacity-devel] Patch Tracker WAS Re:  Beta_Feedback
> > > > -----Original Message-----
> > > > From: Martyn Shaw [mailto:mar...@go...]
> > > > Sent: Sunday, November 01, 2009 3:12 PM
> > > > Subject: Re: [Audacity-devel] Patch Tracker WAS Re: Beta_Feedback Ed
> > > > Musgrove wrote:
> > > > > To get from
> > > > > http://wiki.audacityteam.org/index.php?title=Feature_Requests
> > > > > to a "formal enhancement" requires intervention by an Audacity PTB.
> > > > >
> > > > > As for storing non-committed patches, I do not think it a good idea.
> > > >
> > > > They should be kept somewhere, in case we want to look at them.
> > > >
> > > [   Ed--   ]
> > > The folks developing wxWidgets are using a patch tracker, here is an
> > > example:
> > > http://trac.wxwidgets.org/ticket/11372#comment:3
> > >
> > > Which is based on an open-source project, Trac:
> > > http://trac.wxwidgets.org/about
> > 
> > That isn't explicitly a patch tracker. It's a bug tracker, like Bugzilla,
> which we're
> > considering now as a replacement for Checklist. You can attach a patch to
> a
> > bug, as in that ticket 11372, or not.
> > 
> [   Ed--   ] 
> Maybe we should have two Bugzilla projects--one for bugs and one for
> features. 

Personally I think we are overplaying "features".  We've already got
lots of "developer-supported" ones to choose from, and lots of ideas
for new capabilities which could be part of GSoC (GSoC could also 
cover bug-fixing or stabilising what we have now).    

That's not to deny that sometimes, a small patch can provide a good 
usability enhancement. 



> > ... I think the easiest thing may be just to have a Wiki page for "enhancement
> > patches" and link to the thread where someone posted to -devel with an
> > attached patch.  That doesn't create extra e-mail. I don't mind doing
> > the work.
> > 
> > If the patch is for a bug, then it would be attached to the bug in the
> > bug tracker, or linked to as we've done in the past in the Checklist.
> > 
> > While it's possible to use the Forum, I still think it needs one page to
> > store the patches, so people know exactly where to go and look for
> > patches that haven't been dealt with.
> > 
> > I suspect the Wiki is the more obvious place for storage of the links or
> > patches, just like "Feature Requests" are thrashed out on the Forum and
> > then eventually added to the Wiki Feature Requests page by Peter and
> > myself. So if any users do drop patches on the Forum rather than posting
> > to -devel, the patches could then be moved to the Wiki "enhancement
> > patches" page.
> > 
> [   Ed--   ] 
> Sound good. My biggest problem with the wiki is that it does not make for
> easy dialog.

We don't find that too difficult. Each message on the Forum is a bullet
point on the Wiki.

 
> There are innumerable categories on the wiki "Feature Request" page. Maybe
> it should be broken down into sub-pages with the main page being only an
> index with links (i.e. just the "contents" on the main page). 

Quite possibly. I've already got a plan to split it down to four or five
categories, one per page, but it's no priority for me to do it at the
moment. 

 
> There is no easy way of telling who voted for what
> nor is there an obvious way to add a vote. I suppose I could "Edit" 
> the page (which I just did as a test--made the first item 059 votes instead 
> of 59--changed it back too). 

That's how you "vote", yes:
http://wiki.audacityteam.org/index.php?title=Editing_Feature_Requests#Voting


> Who is to say how many votes are real? 

If anyone cheats by adding multiple votes, I change it back.  It works 
fairly well, though we could investigate a better voting system longer 
term.  We had an experimental one, but it was (or became) broken. 


> There is no real effort to maintain a status--"Would like to implement",
> "Will implement", "Unlikely to implement"--etc.;

De facto, anything not already adopted as a "developer-supported"  
enhancement is "currently unlikely". 


> some of the items on the page are working in 1.3.10--some of them have 
> notes to that effect, others do not.

True, but again, priorities. If you would like to volunteer to move 
things already in 1.3 versions from Feature Requests to:
http://wiki.audacityteam.org/index.php?title=Completed_Features

feel free. But it may make more sense to do all that after 2.0, both
because of "priorities", and because a lot of items in "Completed
Features" will then need moving from "In latest Beta" to "In latest 
Stable" anyway.




Gale