Talk:Top Usability Issues

From Audacity Wiki
Revision as of 11:31, 22 January 2010 by Galeandrews (talk | contribs) (Better mission statement for this page??)
Jump to: navigation, search

Gale 21Jan10: Not very sure from the intro about the aims of this.

  • GA "Top" issues only? This seems to contradict the intro, which appears to suggest these are mainly documentation issues. I don't see the stated issues as documentation issues per se. The documentation can't be much clearer about save and export. If it isn't clear, isn't the place for that the Audacity-Manual list (which has my backing FWIW ), or (usually better) a Talk page on the Manual Wiki?
    • JC This is not about improving the manual. It's about improving Audacity - hence its location here. The 'SIGNIFICANT' is related to 'Top'.
  • GA Why are we discussing "save and export" here when there is a Proposal Menu Reorganisation page? I'd see this "Usability" page as a possible place to flesh out issues pending placing as a bug or a Proposal. Most usability Proposals should I think be in the tracker either as their own issue, or as various issues which are attached to a Proposal. So maybe this is a kind of "competitor" or "complement" as per your view to the -quality list? Maybe it has a broader focus than -quality (so not necessarily a place to discuss an issue like "Snap-To" raised by one of us). But maybe equally it could be a tool to replace the -quality list if that does not work out? I think if we're going to keep adding more and more QA tools we need to be much clearer about what they are all for.
    • JC The proposals should indeed be discussed on relevant proposal pages. E-mail tends to be water under the bridge. Yes, items that start here may become bugs on the Release Checklist, and they may become proposals.
      • Gale: I'm aware it's about the software, so why restrict it to (or mention) issues that are documented (except in so far as anything significant should be documented)? Removing the export/save confusion won't make Audacity easier to document because it's documented properly now as the software is, but the problem is in the software. A complex solution like an advanced navigation box may in itself be harder to document. Documentation seems a red herring. Here is something like I think it should be:
This page is for listing of usability matters with the software that impact on many users. Typically, these will be "issues" rather than "bugs", with no explicit item yet on Release Checklist. Or they could be existing disparate bugs where a holistic approach to fixing them could be beneficial.


Warning icon To use, start a new heading with a summary in an Advice template, state the issue and why it should be addressed. After action has been agreed, move the discussion to a Category:Proposal page and/or Release Checklist as appropriate, then condense the old discussion here with links to Proposal or Checklist.

Then the usual disclaimer that users have to report bugs in the usual way.