Re: [Audacity-manual] Tracking changes across pages

[James C. <cr...@in...>]

I agree with Ed that it is hard to tell from the commit messages whether 
a change affected the GUI or not.

There is no need to subscribe to commits, since they can be viewed at:
http://code.google.com/p/audacity/updates/list
I think near to release,  a developer should review all of those commit 
messages since last release, as part of getting a feel for what might be 
problem areas.  If developers can't tell from the message whether the 
GUI was affected, then the messages need to be improved in future.

Support is good for something like Ed's proposal (that developers give 
manual a heads up about likely impact on manual).  Obviously developers 
shouldn't say which pages are affected, as it is the manual writers role 
to know where different features are documented.

I'm hesitant to add more instruction creep to the release-process, but 
maybe there is no better way.  We'd also add in checking the 'null'  
translation for changes as part of assessing what work is involved in a 
new release.

At the moment this discussion has only happened on manual.  If no one 
takes it to audacityteam, then in a few days I will put a proposal there 
and copied to here.

I would also like to put on the table automating the process of 
obtaining updated screenshots.  I would like manual team to 'own' the 
process of updating screenshots, and once it is automatic that could 
even trigger awareness that some pages text where the images are used 
needs to change.

--James.




On 25/02/2012 18:20, Gale Andrews wrote:
> | From Peter Sampson<pet...@ya...>
> | Sat, 25 Feb 2012 09:56:46 -0800 (PST)
> | Subject: [Audacity-manual] Tracking changes across pages
>> Gale wrote:
>>> You are all agreeing with Ed, but not suggesting a lot to prevent Manual
>>> bugs being missed again.
>> Well I agree with Ed too.
>>   
>> having someone on Q/A trawl through the technical details of commit logs is a
>> back-to-front way of doing things and far from efficient  - and it would still be far
>> too easy to miss changes.
>>   
>> Any developer *knows* when they have made a modification to the existing GUI
>> (added/removed a check box, re-arranged a dialog box, added a menu item or whatever)
>>   or added completely new functionality.  I believe that as a fundamental part of the dev
>> commit process the developer should be informing the manual team, via this email list,
>> of GUI changes that have been committed when they are committted.  This is not an
>> onerous additional task and I think it is quite reasonable to ask the developers to do this
>> as part of their commit process.
> I for one would not welcome extra e-mails given I already subscribe to
> SVN commits. Just let the developers consider the content of the commit
> logs (as I said at the outset) and let the person who agrees to take charge
> of tracking changes on the Manual make sure he subscribes to commits.
>
> Developers are humans like everyone and may omit to note something
> relevant to the Manual in the log. I think if the process is to e-mail
> changes to this list, they will be much more likely to forget. So someone
> looking inside the commits is a good backup.
>
> If we don't have a due process for tracking changes, then we can hardly
> bang the drum about the devs not noting Manual changes in commits.
> So can we agree a process at our end?
>
> At a minimum, I think the lead Manual person (Bill) and lead Forum
> person (Steve) should be subscribed to SVN commits. I thought Steve
> was?
>
>
>
> Gale