Gale Andrews wrote:
> | From Martyn Shaw <martynshaw99@...>
>> 'Release Checklist' (for me) is an impossibly long page which is not
>> well ordered, eg 'Watching' come before 'Priority'. Colour is
>> (apparently) used to say what is a priority as well, but used
> The only instance of colour being used to prioritise should be
> the blue to denote a more important "priority aim-to". Have you an
> example of an inconsistency in using colour to prioritise?
Select-all-when-none wherever a selection area is valid is not enabled
for Edit > Cut and Edit > Copy.
Ensure other edit menu items (not just cut and copy) are consistently
enabled and work consistently. See here .
(Both 'Believed fixed' but still blue)
> The length is due of course to all the issues and their concomitant
> detail (rather than a summary thereof) being on one page, rather
> than having to go to different pages for the detail of each as you
> would on Bugzilla.
>> There are many colours/bold/not, I don't know what
>> they mean. Things appear multiple times (eg 'speaker and mic
>> backgrounds' / 'Speaker and Mic icons') in different sections. I
>> think it needs an overhaul.
> The main problem is because many people have contributed to the
> page over time and have used different formatting to add comments
> to the initial report.
> Would people follow rules for colour use if we had
Maybe, but we shouldn't be using just colour to indicate anything -
what about colour-blind people? I'm for ordering by priority, but as
you know I'm a wiki newbie.
> The Speaker and Mic/background issue appears twice as it is a
> watching brief issue as well as an issue with a particular priority.
> I can see cases where an item would be both a "Watching Brief"
> in terms of a list of things for testers to check, and in a particular
> priority category. In this case, as we don't know where to go with
> it, probably it should now be only "Watching Brief"?
It only appears to be an issue on older Windows versions, which
probably means older hardware, like my laptop (and I suspect it is
hardware related, rather than the OS). I don't expect recent software
to work very well on my laptop. Not a "Priority Aim to", I feel.
>> I think the Wiki version is OK, as long as the rules are clear and the
>> person looking after it is on top of it. Otherwise it all gets a bit
>> random / hard to follow / unlikely to get followed.
> I think by default James was looking after it as far as any one person
> does, and now I seem to have that role. To make separate pages
> for each "bug" and one page summarising all bugs a la Bugzilla
> would be a huge task from where we are now, and the summary
> page would not be short. To shorten the existing page, I suppose we
> could hive off:
> 4 Watching Brief
> 5 Priority Aim to
> 6 Aim to
> to their own pages, or (still a lot of work) make separate comments
> pages just for those bugs which have lengthy comments. I suppose
> hiving off 4, 5 and 6 might be the best short term thing to do, though
> I think if you use the page a lot, it becomes a lot easier to use (if
> you see what I mean)......
I don't want to make a lot of work for you, especially as there are so
few people doing any work on this. Contributions from developers seem
to have reduced to almost nothing. If re-ordering isn't too much
effort I think it would be useful.
I have to issue an assignment to my second-year degree students
shortly. I plan to give them an installer of the current HEAD to play
with, to compare and contrast to Audition 1.5. I was thinking of
getting them to update/write a new page for the manual
http://www.audacityteam.org/manual/ (but not commit it). Is there
anything you think I should particularly ask them to concentrate on?
You never know, we may get a useful contribution.