Quantcast

Tracking wording changes that don't need coding changes

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Tracking wording changes that don't need coding changes

Gale
Administrator
Currently we track these only on
http://wiki.audacityteam.org/wiki/Wording

which I thought was agreed.

James seems (I think) to want secondary tracking with
http://bugzilla.audacityteam.org/show_bug.cgi?id=1427

opening and closing as required (but with no separate bug for
the wording issue). Even this seems duplicated effort to me.
I'm already tracking the Wiki Wording page. Should that not
be one of the pages RM needs to track?

Another alternative which I think would work is to stop using
the Wording page. Use 1427 instead, opening and closing as
needed at the rating of the most important issue, but state
the issue to be addressed in the "Steps to Reproduce" box.
Clear that box out when the issue is fixed. This works (to my
mind) in summary bug
http://bugzilla.audacityteam.org/show_bug.cgi?id=665 .



Gale

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

Peter Sampson-2
.I read James' comments as "use the Wiki>Wording page" and
"don't bothere with the Bug #1427

Maybe I'm wrong but that's what I thought he was saying.

Peter.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

James Crook
Me too, that is how I read my email.

I did put an alert about 1427 on the wiki page, but am fine with Gale's removal of it and Peter using off-list email to prod me instead.  Peter is too. 

--James.




On 3/1/2017 7:50 PM, Peter Sampson wrote:
.I read James' comments as "use the Wiki>Wording page" and
"don't bothere with the Bug #1427

Maybe I'm wrong but that's what I thought he was saying.

Peter.



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot


_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

Gale
Administrator
In reply to this post by Peter Sampson-2
Peter, I am referring to James's request for bug 1427 to be open
when needed:
http://wiki.audacityteam.org/w/index.php?title=Wording&curid=2114&diff=31138&oldid=31136


Gale


On 1 March 2017 at 19:50, Peter Sampson <[hidden email]> wrote:

> .I read James' comments as "use the Wiki>Wording page" and
> "don't bothere with the Bug #1427
>
> Maybe I'm wrong but that's what I thought he was saying.
>
> Peter.
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

Gale
Administrator
In reply to this post by James Crook
Well then if we want to only use Wiki, Peter if he feels it necessary
has to prod RM when we're frozen, and at other times prompt me
( I had agreed to track that Wiki page as the quid-pro-quo for not
tracking on Bugzilla).

Wiki page should indicate priority shoudn't it?  The metadata
export issue was probably a non-release noted P3 whereas
a horrible typo that leads to embarrassment or confusion could
be P1. Something like that "could" be a risk if not Bugzilla tracked,
Peter was on holiday, I was asleep and so on.


Gale


On 1 March 2017 at 20:05, James Crook <[hidden email]> wrote:

> Me too, that is how I read my email.
>
> I did put an alert about 1427 on the wiki page, but am fine with Gale's
> removal of it and Peter using off-list email to prod me instead.  Peter is
> too.
>
> --James.
>
>
>
>
>
> On 3/1/2017 7:50 PM, Peter Sampson wrote:
>
> .I read James' comments as "use the Wiki>Wording page" and
> "don't bothere with the Bug #1427
>
> Maybe I'm wrong but that's what I thought he was saying.
>
> Peter.
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality
>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

James Crook

Gale wrote:
> Other than a typo, consensus can't be assumed until a few days have passed.

Then Peter, please be clear whether the wording has or hasn't been
agreed, when you ask for an update from the wording page to be made into
our code.  I may go ahead anyway if I think the wording change is
reasonable and unlikely to be contentious.


On 3/1/2017 8:20 PM, Gale Andrews wrote:
> Well then if we want to only use Wiki, Peter if he feels it necessary
> has to prod RM when we're frozen, and at other times prompt me
> ( I had agreed to track that Wiki page as the quid-pro-quo for not
> tracking on Bugzilla).
Yes, that seems so.

> Wiki page should indicate priority shoudn't it?  The metadata
> export issue was probably a non-release noted P3 whereas
> a horrible typo that leads to embarrassment or confusion could
> be P1. Something like that "could" be a risk if not Bugzilla tracked,
> Peter was on holiday, I was asleep and so on.
Your and Peter's choice.
As QM you could make a new P1 or reopen 1427 at P1, despite not doing so
for ordinary wording issues, if you see the need to bugzillarize a
particularly lethal wording issue.


>
>
> Gale
>
>
> On 1 March 2017 at 20:05, James Crook <[hidden email]> wrote:
>> Me too, that is how I read my email.
>>
>> I did put an alert about 1427 on the wiki page, but am fine with Gale's
>> removal of it and Peter using off-list email to prod me instead.  Peter is
>> too.
>>
>> --James.
>>
>>
>>
>>
>>
>> On 3/1/2017 7:50 PM, Peter Sampson wrote:
>>
>> .I read James' comments as "use the Wiki>Wording page" and
>> "don't bothere with the Bug #1427
>>
>> Maybe I'm wrong but that's what I thought he was saying.
>>
>> Peter.
>>
>>
>>


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

Peter Sampson-2

A) If we are going to be continuing to use Wiki>Wording then can we please
have some clarity in terms of consensus as to:
a) Who is the constituency for that consensus?
b) What is the quorum to consider consensus achieved ?

Or is there some other protocol we should be considering/using?


B) If we are going to continue using Wiki>Wording then I would suggest that
rather than using Bug #1427 as a flag that we create a "Permanent P1" entry
I shall probably create such an entry there anyway just to ensure some ongoing
Manual team/QA focus.

------------------------------------------------------------------------------------

With regard to the particular issue the Edit Metadata Tags dialog.

We carried a P2 in the Manual for almost a year where Gale noted:
>The tags window now has an alternative title "Edit Metadata Tags for Export"
>when it opens at the export step

I came to address this recently in the current clean-up hiatus.  I tested the
Export Multiple and concluded (wrongly) that the P2 was wrong as the
Export Multiple Metadata dialog shows the simpler form that we show on
the Manual for "Metadata Tags editor".

Gale correced me with:
>Export Multiple has the title as in the image, but single export shows
>"Edit Metadata Tags for Export". So a minor code bug and I suppose we
>don't need to change the Manual for now.

So now we have a minor code bug - so I posted on the Manual page asking
if we should log this as such.

I then as "doer decides" decided that it would be simpler and more in line with our
current protocol to log this simple change on the Wording page in the Wiki
early yesterday.

As I was thinking about this during the day I thought once again as "doer decides"
that it would be a good idea to get this simple change into the code as part of the
hiatus clean-up - otherwise it would be pending until the following release - which
is why I lobbied James to see if he was prepared to fix it. 

Most of the history of this can clearly be seen in the top ednote on this page and


(By the way - If I was a QAer who was also a dev I would have simply logged it as
a "minor code bug" at P5 probably - and then just gone in as "doer decides" and
effected just the change that I lobbied James for:
a) because it's crisper,
b) because as Gale pointed out the longer form tends to imply that it only applies
    to the export and not the data - which is an incorrect inference for a user to make
Thereby leaving it to be marked as Quickfixed - but nicely corrected for 2.1.3).


Peter

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

James Crook
My suggestion is that the default constituency for consensus on that
page is Gale, Steve and Peter.
Additionally I think all three are experienced enough to know what is
likely to and what is not likely to be contentious.

Particularly during freeze, I would like wording changes judged not
likely to be contentious by the poster to be put on the wording page
itself.  If they think a change is likely to be contentious, or detailed
wording is possibly in need of refinement, they put it on the wording
talk page, moving it to the wording page (or even into code if not in
freeze) when they think consensus has been reached.

Another approach is to only prompt me to check new wording in when
consensus has already been checked.    That way I am in little danger of
committing a controversial wording change during freeze.

I adamantly don't want individual bugs for individual wording changes.  
The overhead of bug tracking via Bugzilla for a typo makes bugzilla
unsuitable for one-at-a-time wording fixes (except perhaps the rara avis
P1 wording changes Gale talks of).

--James.



On 3/2/2017 10:13 AM, Peter Sampson wrote:

> A) If we are going to be continuing to use Wiki>Wording then can we please
> have some clarity in terms of consensus as to:
> a) Who is the constituency for that consensus?
> b) What is the quorum to consider consensus achieved ?
>
> Or is there some other protocol we should be considering/using?
>
>
> B) If we are going to continue using Wiki>Wording then I would suggest that
> rather than using Bug #1427 as a flag that we create a "Permanent P1" entry
> in the cleanup Manual page:
> http://alphamanual.audacityteam.org/man/Plan_for_P1/P2_clean-up
> I shall probably create such an entry there anyway just to ensure some
> ongoing
> Manual team/QA focus.
>
> ------------------------------------------------------------------------------------
>
> With regard to the particular issue the Edit Metadata Tags dialog.
>
> We carried a P2 in the Manual for almost a year where Gale noted:
>> The tags window now has an alternative title "Edit Metadata Tags for
> Export"
>> when it opens at the export step
> I came to address this recently in the current clean-up hiatus.  I tested
> the
> Export Multiple and concluded (wrongly) that the P2 was wrong as the
> Export Multiple Metadata dialog shows the simpler form that we show on
> the Manual for "Metadata Tags editor".
>
> Gale correced me with:
>> Export Multiple has the title as in the image, but single export shows
>> "Edit Metadata Tags for Export". So a minor code bug and I suppose we
>> don't need to change the Manual for now.
> So now we have a minor code bug - so I posted on the Manual page asking
> if we should log this as such.
>
> I then as "doer decides" decided that it would be simpler and more in line
> with our
> current protocol to log this simple change on the Wording page in the Wiki
> early yesterday.
>
> As I was thinking about this during the day I thought once again as "doer
> decides"
> that it would be a good idea to get this simple change into the code as
> part of the
> hiatus clean-up - otherwise it would be pending until the following release
> - which
> is why I lobbied James to see if he was prepared to fix it.
>
> Most of the history of this can clearly be seen in the top ednote on this
> page and
> by following its history:
> http://alphamanual.audacityteam.org/man/Metadata_Editor
>
>
>
> *(By the way - If I was a QAer who was also a dev I would have simply
> logged it as*
>
> *a "minor code bug" at P5 probably - and then just gone in as "doer
> decides" and*
>
>
>
>
> *effected just the change that I lobbied James for:a) because it's
> crisper,b) because as Gale pointed out the longer form tends to imply that
> it only applies     to the export and not the data - which is an incorrect
> inference for a user to makeThereby leaving it to be marked as Quickfixed -
> but nicely corrected for 2.1.3).*
>
> Peter



------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

Peter Sampson-2
James wrote:

>My suggestion is that the default constituency for consensus on that
>page is Gale, Steve and Peter.
>Additionally I think all three are experienced enough to know what is
>likely to and what is not likely to be contentious.

i.e QA decides ...

But does a majority carry if 2 agree and one resolutely disagrees?

Peter

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

James Crook
On 3/2/2017 12:09 PM, Peter Sampson wrote:
> James wrote:
>
>> My suggestion is that the default constituency for consensus on that
>> page is Gale, Steve and Peter.
>> Additionally I think all three are experienced enough to know what is
>> likely to and what is not likely to be contentious.
> i.e QA decides ...
>
> But does a majority carry if 2 agree and one resolutely disagrees?
Nope.  That's not consensus.  If there's a lot of emotion in it, then
that's when more people are invited to look at the wording-talk-page.  
It probably is already not right to check it in during freeze.  The
extreme is we end up voting on it as a team, unlikely, but it always is
a way out when consensus is not reached.

--James.

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

Gale
Administrator
In reply to this post by James Crook
So the new idea is basically anything but typos start on the
Wording Talk page?

And RM has to "watch" the Wording article page?

That's OK by me - anything is OK by me really, except separate
bugs per wording issue.

Another consideration for RM at freeze is of course translation
breaking. The Metadata rewording did not break anything
because the string changed to was already used.



Gale


On 2 March 2017 at 11:33, James Crook <[hidden email]> wrote:

> My suggestion is that the default constituency for consensus on that
> page is Gale, Steve and Peter.
> Additionally I think all three are experienced enough to know what is
> likely to and what is not likely to be contentious.
>
> Particularly during freeze, I would like wording changes judged not
> likely to be contentious by the poster to be put on the wording page
> itself.  If they think a change is likely to be contentious, or detailed
> wording is possibly in need of refinement, they put it on the wording
> talk page, moving it to the wording page (or even into code if not in
> freeze) when they think consensus has been reached.
>
> Another approach is to only prompt me to check new wording in when
> consensus has already been checked.    That way I am in little danger of
> committing a controversial wording change during freeze.
>
> I adamantly don't want individual bugs for individual wording changes.
> The overhead of bug tracking via Bugzilla for a typo makes bugzilla
> unsuitable for one-at-a-time wording fixes (except perhaps the rara avis
> P1 wording changes Gale talks of).
>
> --James.
>
>
>
> On 3/2/2017 10:13 AM, Peter Sampson wrote:
>> A) If we are going to be continuing to use Wiki>Wording then can we please
>> have some clarity in terms of consensus as to:
>> a) Who is the constituency for that consensus?
>> b) What is the quorum to consider consensus achieved ?
>>
>> Or is there some other protocol we should be considering/using?
>>
>>
>> B) If we are going to continue using Wiki>Wording then I would suggest that
>> rather than using Bug #1427 as a flag that we create a "Permanent P1" entry
>> in the cleanup Manual page:
>> http://alphamanual.audacityteam.org/man/Plan_for_P1/P2_clean-up
>> I shall probably create such an entry there anyway just to ensure some
>> ongoing
>> Manual team/QA focus.
>>
>> ------------------------------------------------------------------------------------
>>
>> With regard to the particular issue the Edit Metadata Tags dialog.
>>
>> We carried a P2 in the Manual for almost a year where Gale noted:
>>> The tags window now has an alternative title "Edit Metadata Tags for
>> Export"
>>> when it opens at the export step
>> I came to address this recently in the current clean-up hiatus.  I tested
>> the
>> Export Multiple and concluded (wrongly) that the P2 was wrong as the
>> Export Multiple Metadata dialog shows the simpler form that we show on
>> the Manual for "Metadata Tags editor".
>>
>> Gale correced me with:
>>> Export Multiple has the title as in the image, but single export shows
>>> "Edit Metadata Tags for Export". So a minor code bug and I suppose we
>>> don't need to change the Manual for now.
>> So now we have a minor code bug - so I posted on the Manual page asking
>> if we should log this as such.
>>
>> I then as "doer decides" decided that it would be simpler and more in line
>> with our
>> current protocol to log this simple change on the Wording page in the Wiki
>> early yesterday.
>>
>> As I was thinking about this during the day I thought once again as "doer
>> decides"
>> that it would be a good idea to get this simple change into the code as
>> part of the
>> hiatus clean-up - otherwise it would be pending until the following release
>> - which
>> is why I lobbied James to see if he was prepared to fix it.
>>
>> Most of the history of this can clearly be seen in the top ednote on this
>> page and
>> by following its history:
>> http://alphamanual.audacityteam.org/man/Metadata_Editor
>>
>>
>>
>> *(By the way - If I was a QAer who was also a dev I would have simply
>> logged it as*
>>
>> *a "minor code bug" at P5 probably - and then just gone in as "doer
>> decides" and*
>>
>>
>>
>>
>> *effected just the change that I lobbied James for:a) because it's
>> crisper,b) because as Gale pointed out the longer form tends to imply that
>> it only applies     to the export and not the data - which is an incorrect
>> inference for a user to makeThereby leaving it to be marked as Quickfixed -
>> but nicely corrected for 2.1.3).*
>>
>> Peter
>
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

James Crook
On 3/3/2017 1:42 AM, Gale Andrews wrote:
> So the new idea is basically anything but typos start on the
> Wording Talk page?
No.  If you, Peter or Steve reckon it is unlikely to be a controversial
change it can go straight on the main page.  For example, in-app
instructions have not been updated to take account of a change in UI, a
change in copyright date, a way to remove verbosity that does not change
the sense.

Something contentious like removing an exclamation mark, as we have
seen, would need to start on the talk page.


> And RM has to "watch" the Wording article page?

No.  He is obliged to visit it at start of freeze, and collect things
from it.  At other times it is optional for RM.  RM might review it
before each RC.  Depends on the RM.


> That's OK by me - anything is OK by me really, except separate
> bugs per wording issue.
>
> Another consideration for RM at freeze is of course translation
> breaking. The Metadata rewording did not break anything
> because the string changed to was already used.
Yes.  I took that into consideration.  I am also aware that my new
wording (for alphas only) welcome won't be translated for 2.1.3 alphas.  
Not a problem.

--James.


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

Gale
Administrator
On 3 March 2017 at 09:33, James Crook <[hidden email]> wrote:
> On 3/3/2017 1:42 AM, Gale Andrews wrote:
>> So the new idea is basically anything but typos start on the
>> Wording Talk page?
> No.  If you, Peter or Steve reckon it is unlikely to be a controversial
> change it can go straight on the main page.  For example, in-app
> instructions have not been updated to take account of a change in UI, a
> change in copyright date, a way to remove verbosity that does not change
> the sense.

That implies then that Peter/Steve/myself would have to converse
off list first to ascertain that we actually do agree to put directly on the
article page (unless e.g. already decided on the Forum). The example
you give is unarguable, but the exact wording might not be.

For something that was never thought of before, it seems better to me
to put on the Talk page and wait for comments for a few days. That
gives others the chance to chip in too.


> Something contentious like removing an exclamation mark, as we have
> seen, would need to start on the talk page.
>
>
>> And RM has to "watch" the Wording article page?
>
> No.  He is obliged to visit it at start of freeze, and collect things
> from it.  At other times it is optional for RM.  RM might review it
> before each RC.  Depends on the RM.

Then basically we can't rely on the Wiki page being actioned in
freeze and I think we would still have to track P2 or P1 wording
issues (at least) in the Summary wording bug. We would probably
still have to use the Wording Talk page as a thought pad, to avoid
too many comments in the Summary wording bug.

Perhaps you would like to reconsider?



Gale




>> That's OK by me - anything is OK by me really, except separate
>> bugs per wording issue.
>>
>> Another consideration for RM at freeze is of course translation
>> breaking. The Metadata rewording did not break anything
>> because the string changed to was already used.
> Yes.  I took that into consideration.  I am also aware that my new
> wording (for alphas only) welcome won't be translated for 2.1.3 alphas.
> Not a problem.
>
> --James.
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

James Crook
> Perhaps you would like to reconsider?
Not sure exactly what I should be reconsidering.

It's pretty rare that it will be appropriate to make wording changes
during freeze and after .po files have gone to translators....

I've added a general section 'requests to RM' to the
http://wiki.audacityteam.org/wiki/Next_Release page, so that e.g.
requests to update wording during FREEZE are not lost if I don't do them
immediately at that time.

This should avoid the need for using bug 1427.

This should solve a more general problem than me possibly not acting on
a 'wording' update.







On 3/3/2017 4:28 PM, Gale Andrews wrote:

> On 3 March 2017 at 09:33, James Crook <[hidden email]> wrote:
>> On 3/3/2017 1:42 AM, Gale Andrews wrote:
>>> So the new idea is basically anything but typos start on the
>>> Wording Talk page?
>> No.  If you, Peter or Steve reckon it is unlikely to be a controversial
>> change it can go straight on the main page.  For example, in-app
>> instructions have not been updated to take account of a change in UI, a
>> change in copyright date, a way to remove verbosity that does not change
>> the sense.
> That implies then that Peter/Steve/myself would have to converse
> off list first to ascertain that we actually do agree to put directly on the
> article page (unless e.g. already decided on the Forum). The example
> you give is unarguable, but the exact wording might not be.
>
> For something that was never thought of before, it seems better to me
> to put on the Talk page and wait for comments for a few days. That
> gives others the chance to chip in too.

It's up to you/Peter/Steve the precise details of how you use the page.  
I am pointing out that if I am asked to make a wording change during
freeze, and pointed to the wording page, by default, if nothing else
tells me otherwise, I'll assume what I see there can be treated as a
consensus view.

Surely that is reasonable?


>
>
>> Something contentious like removing an exclamation mark, as we have
>> seen, would need to start on the talk page.
>>
>>
>>> And RM has to "watch" the Wording article page?
>> No.  He is obliged to visit it at start of freeze, and collect things
>> from it.  At other times it is optional for RM.  RM might review it
>> before each RC.  Depends on the RM.
> Then basically we can't rely on the Wiki page being actioned in
> freeze and I think we would still have to track P2 or P1 wording
> issues (at least) in the Summary wording bug. We would probably
> still have to use the Wording Talk page as a thought pad, to avoid
> too many comments in the Summary wording bug.
>
> Perhaps you would like to reconsider?
>
>
>
> Gale


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Tracking wording changes that don't need coding changes

Gale
Administrator
On 3 March 2017 at 17:37, James Crook <[hidden email]> wrote:

>> Perhaps you would like to reconsider?
> Not sure exactly what I should be reconsidering.
>
> It's pretty rare that it will be appropriate to make wording changes
> during freeze and after .po files have gone to translators....
>
> I've added a general section 'requests to RM' to the
> http://wiki.audacityteam.org/wiki/Next_Release page, so that e.g.
> requests to update wording during FREEZE are not lost if I don't do them
> immediately at that time.
>
> This should avoid the need for using bug 1427.
>
> This should solve a more general problem than me possibly not acting on
> a 'wording' update.

Well, I didn't like the idea of using Summary Wording Bug as well
as Wiki that you proposed a few days ago, but I was assuming
if we didn't do that, the RM whoever it is would be obligated to
always watch the Wording Article page. I mean the "Watch" tab,
you get e-mailed when the page changes.

If it may be necessary for me to add a P1 or P2 Bugzilla item
during freeze for a wording issue so bad that it trumps it can't be
translated, then to my mind we might just as well use the Summary
Wording bug as you first suggested, after any necessary triage on
the Wiki talk page.

At least the procedure is clear that way, every item is rated and risk
reduced.  I've never felt the explanatory yellow divs on the Wording
article page are really clear.


> On 3/3/2017 4:28 PM, Gale Andrews wrote:
>> On 3 March 2017 at 09:33, James Crook <[hidden email]> wrote:
>>> On 3/3/2017 1:42 AM, Gale Andrews wrote:
>>>> So the new idea is basically anything but typos start on the
>>>> Wording Talk page?
>>> No.  If you, Peter or Steve reckon it is unlikely to be a controversial
>>> change it can go straight on the main page.  For example, in-app
>>> instructions have not been updated to take account of a change in UI, a
>>> change in copyright date, a way to remove verbosity that does not change
>>> the sense.
>> That implies then that Peter/Steve/myself would have to converse
>> off list first to ascertain that we actually do agree to put directly on the
>> article page (unless e.g. already decided on the Forum). The example
>> you give is unarguable, but the exact wording might not be.
>>
>> For something that was never thought of before, it seems better to me
>> to put on the Talk page and wait for comments for a few days. That
>> gives others the chance to chip in too.
>
> It's up to you/Peter/Steve the precise details of how you use the page.
> I am pointing out that if I am asked to make a wording change during
> freeze, and pointed to the wording page, by default, if nothing else
> tells me otherwise, I'll assume what I see there can be treated as a
> consensus view.
>
> Surely that is reasonable?

If the RM is watching the Wording article page I think it is reasonable
for it to be used so that only consensus items are placed there.

I think this means that many times, an item *would* start on the
Talk page.


Gale


>>
>>> Something contentious like removing an exclamation mark, as we have
>>> seen, would need to start on the talk page.
>>>
>>>
>>>> And RM has to "watch" the Wording article page?
>>> No.  He is obliged to visit it at start of freeze, and collect things
>>> from it.  At other times it is optional for RM.  RM might review it
>>> before each RC.  Depends on the RM.
>> Then basically we can't rely on the Wiki page being actioned in
>> freeze and I think we would still have to track P2 or P1 wording
>> issues (at least) in the Summary wording bug. We would probably
>> still have to use the Wording Talk page as a thought pad, to avoid
>> too many comments in the Summary wording bug.
>>
>> Perhaps you would like to reconsider?
>>
>>
>>
>> Gale
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Audacity-quality mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-quality

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Audacity-quality mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-quality
Loading...