Re: [Audacity-devel] Bugzilla

[Martyn S. <mar...@go...>]

Gale Andrews wrote:
> | From Martyn Shaw <mar...@go...> 
...
>> '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 
>> inconsistently.  
> 
> 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.

Indeed.

> Would people follow rules for colour use if we had
> them?

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.

TTFN
Martyn

> 
> 
> 
> Gale 
> 
> 
>