Talk:Release checklist not aiming for 1.4

=Heads Up =


 * We're likely to be moving to google code hosting.
 * We're also likely to be applying to participate in GHoP.

In the past GHoP has used the Google code issue tracker to manage tasks that students are doing. We are handling our issues in many ways more efficiently than a conventional issue tracker can. However we do lose out in some respects.

The page The Ideal Bugtracker describes what I would like to move to in due course. Once issues are in any system that uses tables we will need short clear titles for each issue. We will also need to better separate defects from feature requests. For example.


 * Timer Record needs to remember the last scheduled duration
 * Fix: Adjusting the meter update frequency seems to make no difference whatever, whether it is 100, 30 or 1.

The first is a feature request. The second is a bug. These would perhaps become:


 * Remember last duration in Timer Record: Timer Record needs to remember the last scheduled duration.
 * Meter update frequency has no effect: Adjusting the meter update frequency seems to make no difference whatever, whether it is 100, 30 or 1.

So this is just a heads up that we need to be thinking about this.

=Help=

This eventually moves to more appropriate pages


 * André as part of GSoC work is extracting an html help zip file, using a client side approach.
 * (After discussion) For release most people will download an Audacity installer that includes help and that installs the help too (windows/linux/mac). We probably will also provide Audacity without help for windows platform, for people who want to save bandwidth.
 * Gale 03 May 09: Agreed, except as always I don't believe there will be any installer for Linux, just the source tarball. Linux people who don't use a package provided by their distribution will compile the tarball and then download the help zip if they want help (unless we include the help folder in the tarball purely as a convenience).

Why Two Pages
We need to make a 'cut' between what we plan for the next stable release and what we don't. Where that cut is will change a bit over time. We do not want to get into a state where we never release because we keep moving new items onto the working list. We are fortunate in now being able to move items onto the main list because we have two GSoC students working on bugfixing.


 * Release checklist not aiming for 1.4 is a page of items we don't want to forget about, but that we accept we probably will not do for 1.4
 * Release Checklist is our current working list. It has to include everything we are committed to.  It has to include everything that we would release note if we did not fix.  It may also include some items which have some or have had some developer interest but that are not actually going to get done for 1.4

Could we have better naming for these pages? Perhaps. I haven't a clue what though.


 * Gale 28 Apr 09: That's not how Release Checklist is now. There are lots of P3 to P5 items on there no-one (had) any intention of fixing for release, but some of which may be done with the benefit of GSoC and other collaborative projects. Until we move items from "not aiming" into it as proposed, it does not really have "developer interest" bugs either. Once we move them, "Not Aiming" is largely a list of developer-interest "improvements" with few bugs there at all. If the split between the two pages is between "aiming" for release and "not aiming", we should move all the P4/P5 stuff into "not aiming". That carries a serious risk they will be forgotten, so all bugs IMO should be on one page, call it what you will. Something like getting built-in help (or is that abandoned now?) fits in as a P2. The Release cut-off (no P1 for Beta, no P1 or P2 for stable) is perfectly clear. "Watching Brief" which you allude to is another concern. Until we get a dedicated band of user testers whose focus is on such a page, consigning intermittent/misunderstood items there will get them ignored, a very important reason I think why "failed recoveries" and "orphaned/missing" project re-opening have not had the attention they need. Explicitly calling these P3 as a "generic" bug on Checklist until some reproducible scenario can be found makes sure they are release noted, so again (maybe) raising user awareness of them and willingness to make reports.


 * James: I don't know what to do about naming, but I do know I want those bugs to be P'd and R'd and to move to the main checklist page. Watching brief should be release noted, but in its own section.  We'd have a note above it explaining to users that we will be eternally grateful for steps that enable us to reproduce these bugs. A help zip is on the release checklist.  Let's talk about built-in help on audacity-devel.  I agree with you about failed recoveries and orphaned blockfiles.  Anything else we can do to improve process there?


 * Gale 29 Apr 09: I've corrected my P1/P2 typo above, you beat me to it :=). We agree about moving bugs reported on "not aiming" (and currently marked as such) to the Checklist. Whether we agree about moving any other bugs still in there, I'm not sure. We have to keep the Checklist scannable, but I'm completely convinced based on the last 18 months or so that all bugs including "not understoods" must be on one list. I think you are saying that by wanting those bugs moved from "not aiming", most of which probably aren't P2 or even P3. You  "might" want to call "not understoods" "P3 WATCH" or something, and have a separate page to log reports about them, but the generic issue itself must be on the main list. If "help for1.4" is a Stable release block, it is a P2. Then all we have to decide just what the purpose of "not aiming" really is.
 * James: Because of work done by Leland and what the GSoC students will do we will be able to have all bugs on one page. Which is what we want.  Heisenbugs/Watching-Brief bugs may be ones we can do nothing about until we have some reports.  They are bugs where we put the headline item only e.g. "Recovery sometimes corrupts all data, not yet reproducible by us." on the checklist and give details and discussion - which may get very extensive - on another page.


 * Gale: Maybe if we ever load all the bugs there really are we will be pushed for space again, but I think we are really both saying much the same at the moment.


 * About inbuilt help, Checklist has "Installer to be modified to also install Html help". The Release Tools GSoC Idea has "Audacity stable releases have help and translations accompanying them". Both those seem to imply built-in help, or are at best ambiguous. Richard discussed the pros and cons of inbuilt wxHTML browser/PDF/web browser with zip in Team. About zip he said "Zip format can confuse users, no global search mechanism, hard to print whole manual". I think in many ways it is the weakest of the three options. I can support zip as "better than nothing" but I think that means Checklist has to be modified.
 * James: I think having a zip (that can be unzipped) and an installer is a P2. Having an index of some kind is a P3 and having pdf or built-in help is P4 or P5.  Having context sensitive help (available in English only and only if the manual was downloaded) in the preferences panel would also be very nice to have.  At this stage I wouldn't want to hold 1.4 up for it though.  Having translations of the manual is completely optional.


 * Gale: Can we agree/be clear about what "install HTML help" in the Checklist actually means? It is a button Windows users can click to put all the HTML files in a folder (for opening in a web browser), and just saves the unzipping confusion, is that right?
 * The audacity installer would be modified to check if you have the help zip in the same directory as the installer. If it is, then it will suggest where to install the help, will do the unzipping and make sure that audacity knows where to find help.  That's what we should aim for anyway.
 * And Help > Index... continues to just give users an option to view the Manual online, or obtain the zip?
 * Help->Index will already use a local help file, if there is one where it expects to find it. If there is a local index page it currently by default opens in the built-in browser.  Maybe that should change to opening the local help index in the user's full browser by default if local help is available?  Whether built-in or external browser, if there is already local help, we generally don't want to be sending the user to the internet to read online help!
 * Gale 30Apr 09: What happens if there is not already a help zip in the same directory as the installer (could happen purely if user chose different directories for them)? I like Vaughan's idea of having separate installers (one including help, recommended version) and one without. The one including help extracts a ready to use Help folder into the user directory where Help > Index.. will see index.htm. There is no user choice to change that, so no user confusion. In any case, for those who have local help already as one of the current pseudo solutions offered on Manual Wiki, don't we need a check for that, or simply overwrite the Help folder? As for where the correctly positioned index.htm should open, I guess this depends what functionality the built-in browser has. Realistically it looks like it won't improve much, so maybe web browser is better, though certainly less intuitive. Built-in browser needs back button to work and have some right-click "copy text" functionality IMO before it can be considered for default, and other issues as well. Also the web browser will give you a page search. Loss of document search will I think be heavily remarked upon by users upgrading from 1.2, but I agree it can't be a P2. I still think a PDF is the cheapest temporary solution for that, if conversion from HTML can be got to work. It also lets users print the whole manual and has an index mechanism).
 * Having an installer with audacity and another with audacity and manual also works fine. Built in browser would need too much work to a become full browser.  Having pdf is a nice to have.  Do you know of a good converter?
 * Gale: I know of HTMLdoc but I don't know if lack of stylesheet support in that is a problem. But note that PDF export is another thing that is already supposed to work with Dominic's script but doesn't. Could André help with that or does the assumed lower priority preclude that? Note also that the script does not seem to support tagged PDF needed for screen-reader purposes. The suggestion was that two PDFs would be produced, one automatically using the script (without tagging), and another manually "when required"  from the script-produced RTF. Seems inelegant to say the least.
 * André's primary remit is bugfixing. His project proposal requires him to have zipped html help by mid term.  A tactical decision to work client side was made.  PDF wasn't part of it at all.  Andre will be fixing some bugs lower priority than pdf I am sure.  He is not required to work strictly from highest priority down.  He can pick what he is interested in and has the skills for.  I would personally sooner see his html help work after other bugfixing extend into context help on the preferences screens so that we can then use shorter text strings there if there is time for it.  You may think pdf for blind more important.  Andre may be more interested in auto-volume features....  We are just lobbyists here.  Martyn has a bit more say since he will do the mid term and final review.
 * Gale 03 May 09: I too think contextual help is more important, but if/when we investigate PDF provision I think we should see if creating a single (tagged) PDF is possible. PDF is a way of providing a document search, and a whole document print. If search of the help files is instituted in some way, maybe that drops PDF a rating. Also the "Welcome Screen" is pretty out-of-date now, probably sufficiently so that it is actually a P2, assuming we retain it.
 * Gale 28 Apr 09:
 * You said "having an index of some kind is a P3" - is this an Index in the manual or something else?.
 * Could be. However if we're doing a detailed index we need to use tools rather than do it by hand.
 * You said "having ... built-in help is P4 or P5". Do you see that as meaning "having the built-in browser good enough to be default choice for opening index.htm"? And/or having document search in the built-in browser?
 * I intended 'built in browser good enough', at least for the first page.
 * My personal "P2" is having the installer include and simply put help in the right place without user intervention, as 1.2 did. What browser opens it does not matter so much to me.
 * OK. Let's go with that then.
 * Gale: OK that clarifies that P2. The other related P2 (zipped help for those who got the Audacity installer without help, or who got the Audacity executable as a zip) is making progress. My only other question is, I assume the "installer puts help in the right place" P2 includes the Mac .dmg as well? The .htb file was included in 1.2 for Mac (though it is missing from 1.2.5 by mistake). The .dmg Universal Binary is already huge so I don't see any need to make one with help and one without.

Future of Feature Requests
Feature Requests are only relevant to development plans on these two pages when they have 'won' a developer interested in actually developing them. There are some great ideas on the feature requests page, and some have been worked out into Use Cases that are ready to go, except that no developer has latched onto them. Users cannot decide for the developers what the developers are interested in doing, they can only try to persuade, mainly through votes, well articulated design discussion, or else become developers themselves.

There is therefore no plan to merge arbitrary feature requests into this pair of pages. However in discussing The Ideal Bugtracker the idea of having a wiki with tables where it is easier to manage both bugs and feature requests, and other work items too is being discussed. Such a wiki would make it easy to receive a bug report from a user, redirect it to a feature request page if that is what it was, merge it with related bugs, split it into component requests, mark it as needing release noting or moving to watching brief. Many bug reports are also likely to be lack of knowledge on the part of the user, so integration with an Autofaq would be good too.


 * Gale 28 Apr 09: Thanks for that clarification, much clearer than it was. Input into Feature Requests (and bugs) comes from many different sources like mailing lists, Forum, feedback@ and other e-mails, so a more efficient, integrated way for us to handle them will help. That said, the distinction between a feature suggestion discussed on devel-list with some support, then parked on "not aiming", and a suggestion (maybe even the same one) on the "user" FR page is not all that clear. Neither are being actively pursued, it is possibly just assumed the former have more chance, especially if benefit against time involved is strong.


 * James I think that's correct. I think the former do have more chance because of developer interest.  The ideal tool would allow us to signal that in some way, and also signal both FR and bugfixes with good ROI.

Discussion

 * Gale 22 Apr 09: James, although I glanced at The Ideal Bugtracker I found it a bit difficult to see the wood for the trees. Perhaps needs some bullet points for short- and long-term suggestions?
 * What should be in the table headings? The current idea is that the bug title is immediately usable for a release note. I doubt the title of some of the bugs could be shortened and still be useful in that context. Shortening to five or six words would mean I think mean adding steps to reproduce in most cases. That may not be very suitable for a table column?
 * Were you envisaging writing a script to scrape Release Note information (both for existing bugs and those cleared)?
 * User-level access to the tracker remains questionable I think. Vetting bugs submitted to feedback@ seems a better idea on the whole. There is no deterrent effect from users having to register, so we get the reports, but no "non-issue" garbage to remove. We (currently, I) certainly need far more time to load bugs. There are dozens of (largely) P3 and below I have stored details about that are not on the list. Same goes with Feature Requests submitted in various ways other than directly on the Wiki.
 * As for this current page, it has mutated from being solely a place for (deemed) lower priority bugs to also being a place for "developer-generated" feature requests. That is solely so we don't lose them and due to inertia in deciding some better plan for storing them. Maybe they should go on the main Feature Requests page, or be split off into a separate Feature Requests page, and attract user votes? I agree the FR voting system is primitive, but is it a priority to improve it?
 * I think you're right - as we become more assiduous in bug tracking, and more involved in projects that have to track participants' activities, the current Wiki system will get strained.
 * Fundamental question is should the bug-tracker even include Feature Requests (FR's), however generated? Are bugs and FR's sufficiently intertwined to justify that? Are our future collaborative projects largely going to be a mix of bug fix and new developments? Some GHoP projects seem to be largely improvements rather then bug fixing. Do we want instead a separate tracking page for activity on implementing FR's?
 * Second, I think bugs on this current page should go on the Checklist and we abandon the "not-aiming" distinction (much of the current Checklist is "not aiming"). Whether P3 and P4/5 bugs should have a separate page is another question.
 * With many more items to track, I can envisage a drift towards having separate pages for details of most or even all items, to keep the master page digestible. That seems to suggest Wiki as not necessarily the best approach (at least without some kind of automation).


 * James Very useful points. Thanks!
 * I can give short wording for bugs, which is the right thing for someone familiar with the list for scanning. Text for release notes is different.  I think a release notes page would be best structured around topics...  so for example if we have 5 known and not very serious bugs with labels they appear in one topic.
 * No script was planned. Eventually a modified wiki would do it.
 * I too can see a problem with unrestricted access. New users tend to give text like 'problem with Audacity', which is not very helpful.  Issues from inexperienced reporters need to be cleaned up before getting into the main list(s).  So I think we have lists of 'untriaged' (2 star and lower reporters).  Most interesting lists are 'triaged' (reports written or cleaned up by 3 star and higher reporters).
 * We want to find ways to reduce the workload in creating/reporting bugs and feature requests. It's also related to guiding people to existing reports of issues. Not so easy.
 * Our feature request page kinda-works. Improving it is certainly lower priority than getting help into a good shape.
 * I hadn't seen that 'feature requests actively supported by developers' or some such title was an important category. Good point.  It's similar to bugs.  A bug with a developer initial beside it is different to one that has 'not been looked at'.  Voting is interesting, but we are a do-ocracy.  Who is running with an issue is in many ways more important.
 * Bugs and FRs are related, and users often can't tell the difference. If we are writing extensions to wiki to improve things for one, then we also should aim to improve the other at the same time.
 * A-bug-per-page is not useful until you have scatter-gather functionality. It is useful then.


 * Gale 27 Apr 09: Do you want me then to rate the "bugs" here and move them to main Checklist, or would you like to? I think they serve no purpose here and will just be forgotten. I could rate them and then propose on -devel that we move them? There probably are some more "bugs" in "not aiming" but I have not looked closely.
 * JC: Please rate with P's (and R's) and then state on -devel that we WILL move them, but "please to check/confirm the ratings...".
 * How do you feel about renaming Checklist to "Release Issues Checklist" and this page to "Release Improvements Checklist"? (or drop "Release" as superfluous). And sometime maybe even "rate" the "improvements"?  That means the "Issues" page can still accommodate things that aren't bugs (like "no help", which is really a P2 issue).
 * JC: Not keen on that change.
 * Gale 27 Apr 09: Do you have another suggestion? I don't think the name of either page now describes what the pages are (or may become). I think being clear about the purpose of "Not aiming" instead of it being a parking place would be useful.
 * You may think this is too compartmentalised, and does not suggest what happens to user Feature Requests, but I do like the "classic" definition of a bug as "something that isn't working as the developers intended". They are also things that can potentially block a release, which "improvements" and "Requests" can't (at least until they are being actively worked on for a release and so must be finished).
 * I like the distinction between 'bug' and an 'enhancement request' too. For me a bug is something where all developers agree what the behaviour should be.  There is almost no scope for argument about whether X is broken or fixed.  An enhancement request can get into lengthy arguments about what the behaviour should be.
 * Gale 27 Apr 09: Though deciding what behaviour should fix a bug is sometimes open to opinion. Think cut lines, fitting generated tones, selecting samples...
 * Finally because users can confuse bugs and requests, I can't imagine anything more intimidating for them than a Wiki page that had requests as well as "issues" (I have seen a few conventional "issue trackers" lately which seem to expect the user to actually decide themselves whether they have a bug or a request). It just seems to me to raise the chances of them placing either in the wrong category, unless they are somehow locked out of the issues part of the tracker.
 * Right - but these two checklist pages are for US, not for the users. Does this comment actually belong on 'The Ideal Bugtracker'? 
 * Gale 27 Apr 09: Probably, and we can move it, but we are directly considering the content of Release Checklist, I think. I was getting the impression you wanted Feature Requests (including user-generated) to be ultimately on one list. Was I wrong? If I was right, then users need access, unless they have their own scratch page to mess with, and a condensed workable version of the Request is duplicated on "our" list.