FeatureRequestDirections

Ok, some notes on how I envision this working for Audacity. First, there's online help if you click on any question mark on the script, and if you click the Help link you can read all of the help. The help's not very good, and is intended to tell you what's what, but not necessarily how to use it. That's why I'm writing this. :)

If you make a feature non-votable, that means it becomes a category. You can't vote on the specific feature, but the idea is that you add features underneath it, and that's how you categorize all of the features.

The wiki page had several top-level categories already, and users would edit those categories periodically and move stuff around. You can still do that with this script. I went ahead and created all the top-level categories that were there originally.

So, the idea is that you first check which category your pet feature belongs in, and then see if there are sub-categories. Now, be careful about making a feature non-votable that has already been voted on, because then you essentially cancel all of those votes. But they can be restored. :) IN any case, if you see an existing feature that seems more like a category, you should go ahead and create a new feature to act as category, and then move the existing feature under it, to preserve the voting history it has.  THen add your new feature in the category, and put something in the description to differentiate it from the existing feature.

Descriptions don't take html. Plaintext only. Also, editing doesn't cost any votes, so if you see that someone tried to put html in a description, you can go ahead and edit it to remove the html to it'll be easier reading.

Every feature requested allows you to associate a link with it, so don't try too hard to fill up the description with everything you possibly can. Instead, make a page in the wiki for it. If you want an RFC or something, make a page in the wiki for it. Provide in the feature description enough information that someone can vote on it, but if you want to discuss implementation details, make a page in the wiki for it. Then just copy the URL for that page from your browser to the link box in the feature request edit form, so that people will know where to go to read more information about it.

Ultimately, the idea is to mimic everything that the wiki page had already, but add the robustness you'd expect from a dedicated script for the job. So if you find that the wiki page provides a usability feature to the system that's lacking, say so!

Now I'll describe the problem I was trying to solve in the first place:

One night, while discussing something on the audacity-devel list with another guy, we both essentially simultaneously decided to go request our own pet features (they were somewhat competitive, but not completely), so we both headed over to do so. So at approximately the same time, I figure we each clicked the "edit this page" link on the feature request page in the wiki. After that, one of us submitted our edits before the other. Now, I don't know if this wiki actually prevents simultaneous users from editing a page or not, but I could see a situation where the wiki page wouldn't scale for the purpose it was trying to fill. What was needed to prevent simultaneous users from blocking each other or overwriting each other was a script dedicated to the task that basically took all the eggs out of one basket and spread them around.

That's it from me. Make sure if you have any bad comments on the script that you edit this page and add them. If you have good comments, I'd still love to hear them, but good comments don't usually indicate problems that need to be fixed. :) Sorry if I made this page hopelessly long...