Re: [Audacity-manual] Tracking changes across pages

[Gale A. <ga...@au...>]

| From James Crook <cr...@in...> 
| Sat, 25 Feb 2012 22:06:38 +0000
| Subject: [Audacity-manual] Tracking changes across pages
> On 24/02/2012 22:55, Ed Musgrove wrote:
> And it's now at least a lobby of 2 as Bruno +1'ed you.

It's at least +4 (including Peter) - I want commit logs to be more useful
for both quality and documentation. 

A good commit message:

 "FIXED Bug 2332 (P4): <hyperlink>Memory leaks in Equalisation 
   effect (now 20 times faster); 
   rewording of EQ buttons (affects Manual)."  

What I AM trying to do is see if we could make a formal system amongst 
those working on the Manual for:  

* adding P1/P2 editornotes as soon as code changes are detected 
   (unless there are few enough changes to fix them at once)  
* make sure the Manual is searched so that nothing that needs to 
   change is missed. 

I think the best way is for some single known person to do that, 
but if someone has a better idea, please state it. 

Without a system, however much the developers improve their commit 
logs, things WILL be missed.  When the Manual people have a system, 
the issue of commit logs should IMO be taken to the -quality list. We
have a much stronger case if we have a system.  

We also I think want to ensure when a substantial feature is added
that the developer adds user-level documentation in the Manual, 
probably in a Talk page. That probably does need an e-mail to this 
list (or a hyperlink in the commit log). 

Personally I feel all Forum Crew or above should be having commit 
logs fed or e-mailed to them. It can only help the quality of response
on the Forum to know what is going on. 

James' ideas for a NULL translation sound as if they may be useful.


Ed wrote:
> Since the manual expects Windows 7 Basic themed images and I was 
> the only editor on Win7 I took on the job. Gale is now on Win7 too and
> can do the job.

Ed, that is not a good use of my time. On the other hand you are better 
than me at ferreting inside code commits, and I thought you enjoyed 
that. 

If you no longer want to help with the Manual please let us know 
then other arrangements can be made. I hope that is not the case. 

I too think automated screenshots may not save as much time as 
anticipated.  


Bill wrote:
> I'd also like to lobby again for manual freeze being a few days after
> code freeze.

I think there is a general problem that developers tend to commit things
right up to just before the freeze. Not only does that give the Manual
workers no time to adjust the Manual, it gives QA no time to test 
changes (some of which may affect the README). 

It depends what the changes were - if a formal three days of Manual/
QA freeze is not needed on a particular occasion then there may be no 
reason to add a delay. If it worked that way, then QA and Manual would
have to lobby RM for more time. If we had a formal "cooling off" period 
after code freeze for QA/Manual catch up, that time could possibly be 
used for some kind of testing. 

This should be raised on -quality, too, I think.  





Gale