Quantcast

Proposal - Sprucing up 'getting involved'

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

Proposal - Sprucing up 'getting involved'

James Crook
I'm looking at improving our 'Get Involved' pages.

http://www.audacityteam.org/community/

I'd like to add icons for the different ways of getting involved.  We're
very text heavy currently.


I'd like to add a new page for the early adopters initiative.
The question is where to direct early adopters to.

* If we were further ahead with Q2A I would say that would be the place,
and the questions would be about enhancement requests and the new features.
* The most likely option at this stage is instead a google group, which
gives us an email list again that we can announce on.
* A third option is a board on the forum.
* A fourth is to direct people here on the quality list.  We might have
to change how we use this list quite a bit though.

--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: Proposal - Sprucing up 'getting involved'

Gale
Administrator
On 23 March 2017 at 13:09, James Crook <[hidden email]> wrote:
> I'm looking at improving our 'Get Involved' pages.
>
> http://www.audacityteam.org/community/

Yes, thanks.



> I'd like to add icons for the different ways of getting involved.  We're
> very text heavy currently.
>
>
> I'd like to add a new page for the early adopters initiative.

I don't know why we concentrate on early adopters. As far as I
know we want testers, of whom early adopters are a subset.

Have we considered "channels" for the different types of build (as
the way to "market" each type)? There seems to be good precedent
for that e.g. with web browsers.


> The question is where to direct early adopters to.
>
> * If we were further ahead with Q2A I would say that would be the place,
> and the questions would be about enhancement requests and the new features.
> * The most likely option at this stage is instead a google group, which
> gives us an email list again that we can announce on.
> * A third option is a board on the forum.
> * A fourth is to direct people here on the quality list.  We might have
> to change how we use this list quite a bit though.

I think the weakest options there are Q2A and the -quality list. I think
some of our discussions here may be a turnoff for some. If we could
have had a new list, that might have been first choice for me.

I would want a new forum instance, not a new board on the existing
Forum, if we went that route.

Does Google Groups support proper HTML? We kind of get used to
BBCode on the Forum but it isn't ideal for many people.

.
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: Proposal - Sprucing up 'getting involved'

James Crook
On 3/24/2017 1:24 AM, Gale Andrews wrote:

> On 23 March 2017 at 13:09, James Crook <[hidden email]> wrote:
>> I'm looking at improving our 'Get Involved' pages.
>>
>> http://www.audacityteam.org/community/
> Yes, thanks.
>> I'd like to add icons for the different ways of getting involved.  We're
>> very text heavy currently.
>>
>>
>> I'd like to add a new page for the early adopters initiative.
> I don't know why we concentrate on early adopters. As far as I
> know we want testers, of whom early adopters are a subset.

Consider these calls to action:

1. (early adopter) "Get early access to work-in-progress on Audacity
that has exciting new features.  Not all of these features will become
mainstream, but your feedback on the features and bugs will help us
define future versions of Audacity"
2. (tester) "Come and try out a buggy version of Audacity with your
projects, and really help us find the bugs so that other people can
benefit from a more stable Audacity"

2's are more valuable to us, but 1 is a massively more attractive
proposition to most people.  Dark Audacity 2.1.3x (approach 1) was much
more effective at getting work in progress tried out by new people than
2.1.2 RC1 (approach 2).

I think it is far more likely that we will have a good outcome by
attracting early adopters, making the process of being involved in that
initiative fun, and from that find that there are people willing to put
in the extra effort to do more systematic testing, than by appealing to
people's wish to help others.

The appeal of '2' is more like "come and be a professional tester", and
it sounds a lot more like work.


> Have we considered "channels" for the different types of build (as the way to "market" each type)? There seems to be good precedent for that e.g. with web browsers.
Please say more.

>
>> The question is where to direct early adopters to.
>>
>> * If we were further ahead with Q2A I would say that would be the place,
>> and the questions would be about enhancement requests and the new features.
>> * The most likely option at this stage is instead a google group, which
>> gives us an email list again that we can announce on.
>> * A third option is a board on the forum.
>> * A fourth is to direct people here on the quality list.  We might have
>> to change how we use this list quite a bit though.
> I think the weakest options there are Q2A and the -quality list. I think
> some of our discussions here may be a turnoff for some. If we could
> have had a new list, that might have been first choice for me.
Google group IS an e-mail list.  It is just it has a web based email
archive that goes a bit beyond mailman.  So that sounds like a decision
to use a google group.  I'll assume that unless you say otherwise.

> I would want a new forum instance, not a new board on the existing
> Forum, if we went that route.
>
> Does Google Groups support proper HTML? We kind of get used to
> BBCode on the Forum but it isn't ideal for many people.
>
> .
> 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: Proposal - Sprucing up 'getting involved'

Stevethefiddle
On 24 March 2017 at 09:48, James Crook <[hidden email]> wrote:

> On 3/24/2017 1:24 AM, Gale Andrews wrote:
>> On 23 March 2017 at 13:09, James Crook <[hidden email]> wrote:
>>> I'm looking at improving our 'Get Involved' pages.
>>>
>>> http://www.audacityteam.org/community/
>> Yes, thanks.
>>> I'd like to add icons for the different ways of getting involved.  We're
>>> very text heavy currently.
>>>
>>>
>>> I'd like to add a new page for the early adopters initiative.
>> I don't know why we concentrate on early adopters. As far as I
>> know we want testers, of whom early adopters are a subset.
>
> Consider these calls to action:
>
> 1. (early adopter) "Get early access to work-in-progress on Audacity
> that has exciting new features.  Not all of these features will become
> mainstream, but your feedback on the features and bugs will help us
> define future versions of Audacity"
> 2. (tester) "Come and try out a buggy version of Audacity with your
> projects, and really help us find the bugs so that other people can
> benefit from a more stable Audacity"
>
> 2's are more valuable to us, but 1 is a massively more attractive
> proposition to most people.

Which is fine until we make a bad mistake and early adopters lose
important work.

My preference would be:

3. (tester) Get early access to exciting new features and help us
define future versions of Audacity...

Steve

> Dark Audacity 2.1.3x (approach 1) was much
> more effective at getting work in progress tried out by new people than
> 2.1.2 RC1 (approach 2).
>
> I think it is far more likely that we will have a good outcome by
> attracting early adopters, making the process of being involved in that
> initiative fun, and from that find that there are people willing to put
> in the extra effort to do more systematic testing, than by appealing to
> people's wish to help others.
>
> The appeal of '2' is more like "come and be a professional tester", and
> it sounds a lot more like work.
>
>
>> Have we considered "channels" for the different types of build (as the way to "market" each type)? There seems to be good precedent for that e.g. with web browsers.
> Please say more.
>
>>
>>> The question is where to direct early adopters to.
>>>
>>> * If we were further ahead with Q2A I would say that would be the place,
>>> and the questions would be about enhancement requests and the new features.
>>> * The most likely option at this stage is instead a google group, which
>>> gives us an email list again that we can announce on.
>>> * A third option is a board on the forum.
>>> * A fourth is to direct people here on the quality list.  We might have
>>> to change how we use this list quite a bit though.
>> I think the weakest options there are Q2A and the -quality list. I think
>> some of our discussions here may be a turnoff for some. If we could
>> have had a new list, that might have been first choice for me.
> Google group IS an e-mail list.  It is just it has a web based email
> archive that goes a bit beyond mailman.  So that sounds like a decision
> to use a google group.  I'll assume that unless you say otherwise.
>
>> I would want a new forum instance, not a new board on the existing
>> Forum, if we went that route.
>>
>> Does Google Groups support proper HTML? We kind of get used to
>> BBCode on the Forum but it isn't ideal for many people.
>>
>> .
>> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal - Sprucing up 'getting involved'

Peter Sampson-2
James wrote:
>The appeal of '2' is more like "come and be a professional tester",
>and it sounds a lot more like work.

it IS a lot more work ;-)))

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: Proposal - Sprucing up 'getting involved'

Peter Sampson-2
In reply to this post by Stevethefiddle


On Fri, Mar 24, 2017 at 10:02 AM, Steve the Fiddle <[hidden email]> wrote:
On 24 March 2017 at 09:48, James Crook <[hidden email]> wrote:
> On 3/24/2017 1:24 AM, Gale Andrews wrote:
>> On 23 March 2017 at 13:09, James Crook <[hidden email]> wrote:
>>> I'm looking at improving our 'Get Involved' pages.
>>>
>>> http://www.audacityteam.org/community/
>> Yes, thanks.
>>> I'd like to add icons for the different ways of getting involved.  We're
>>> very text heavy currently.
>>>
>>>
>>> I'd like to add a new page for the early adopters initiative.
>> I don't know why we concentrate on early adopters. As far as I
>> know we want testers, of whom early adopters are a subset.
>
> Consider these calls to action:
>
> 1. (early adopter) "Get early access to work-in-progress on Audacity
> that has exciting new features.  Not all of these features will become
> mainstream, but your feedback on the features and bugs will help us
> define future versions of Audacity"
> 2. (tester) "Come and try out a buggy version of Audacity with your
> projects, and really help us find the bugs so that other people can
> benefit from a more stable Audacity"
>
> 2's are more valuable to us, but 1 is a massively more attractive
> proposition to most people.

Which is fine until we make a bad mistake and early adopters lose
important work.

My preference would be:

3. (tester) Get early access to exciting new features and help us
define future versions of Audacity...


I think my preference would be (effectively 1 plus 2):

4. (tester) Get early access to exciting new features and help us
define future versions of Audacity. And help us find the bugs so that
other people can benefit from a more stable Audacity".

Peter

 

Steve

> Dark Audacity 2.1.3x (approach 1) was much
> more effective at getting work in progress tried out by new people than
> 2.1.2 RC1 (approach 2).
>
> I think it is far more likely that we will have a good outcome by
> attracting early adopters, making the process of being involved in that
> initiative fun, and from that find that there are people willing to put
> in the extra effort to do more systematic testing, than by appealing to
> people's wish to help others.
>
> The appeal of '2' is more like "come and be a professional tester", and
> it sounds a lot more like work.
>
>
>> Have we considered "channels" for the different types of build (as the way to "market" each type)? There seems to be good precedent for that e.g. with web browsers.
> Please say more.
>
>>
>>> The question is where to direct early adopters to.
>>>
>>> * If we were further ahead with Q2A I would say that would be the place,
>>> and the questions would be about enhancement requests and the new features.
>>> * The most likely option at this stage is instead a google group, which
>>> gives us an email list again that we can announce on.
>>> * A third option is a board on the forum.
>>> * A fourth is to direct people here on the quality list.  We might have
>>> to change how we use this list quite a bit though.
>> I think the weakest options there are Q2A and the -quality list. I think
>> some of our discussions here may be a turnoff for some. If we could
>> have had a new list, that might have been first choice for me.
> Google group IS an e-mail list.  It is just it has a web based email
> archive that goes a bit beyond mailman.  So that sounds like a decision
> to use a google group.  I'll assume that unless you say otherwise.
>
>> I would want a new forum instance, not a new board on the existing
>> Forum, if we went that route.
>>
>> Does Google Groups support proper HTML? We kind of get used to
>> BBCode on the Forum but it isn't ideal for many people.
>>
>> .
>> 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


------------------------------------------------------------------------------
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: Proposal - Sprucing up 'getting involved'

James Crook
On 3/24/2017 10:23 AM, Peter Sampson wrote:

> Steve the Fiddle wrote:
>> James Crook wrote:
>>> Gale Andrews wrote:
>>>> I don't know why we concentrate on early adopters. As far as I
>>>> know we want testers, of whom early adopters are a subset.
>>> Consider these calls to action:
>>>
>>> 1. (early adopter) "Get early access to work-in-progress on Audacity
>>> that has exciting new features.  Not all of these features will become
>>> mainstream, but your feedback on the features and bugs will help us
>>> define future versions of Audacity"
>>> 2. (tester) "Come and try out a buggy version of Audacity with your
>>> projects, and really help us find the bugs so that other people can
>>> benefit from a more stable Audacity"
>>>
>>> 2's are more valuable to us, but 1 is a massively more attractive
>>> proposition to most people.
>> Which is fine until we make a bad mistake and early adopters lose
>> important work.
>>
>> My preference would be:
>>
>> 3. (tester) Get early access to exciting new features and help us
>> define future versions of Audacity...
>>
> I think my preference would be (effectively 1 plus 2):
>
> 4. (tester) Get early access to exciting new features and help us
> define future versions of Audacity. And help us find the bugs so that
> other people can benefit from a more stable Audacity".
>
> Peter
Are we vehemently agreeing again?  Both 3 and 4 are appeals to early
adopters.

To be a bit clearer, we need to lead with the idea of new and exciting
things to try out.


The strategy I am prepared to work on involves exciting new experimental
code.  In the process it exercises other new code added since 2.1.3.  We
have a pool of people with different hardware giving bug and feature
feedback.  Feature feedback on work in progress is going to auteurs, and
there may be dialogue between the auteurs and this pool of engaged early
adopters.

I think it is a misconception that there are, say, 16 people out there
who would volunteer to test the way we most need it, if we just make a
call for that directly.  Rather there are (at least) 30,000 people out
there who will give new experimental code a try out.  Many of those
would be willing to give a little feedback to us 'Subsonic Microphones
don't work with Dolby enabled, for me'.  A few could get more involved
than that.  16 may actually over time become testers.  That happens IF
being part of the energy of the initiative is fun.

I don't want to waste my time on a strategy that is based on the
misconception of pre exisitng testers ready to volunteer, if only they
knew it was needed.  The strategy I am going for is to get people using
and communicating with us about new experimental versions.  Grow a small
number of actual testers from that larger pool.

So having explained the strategy I envisage more clearly, Peter, Steve
do you agree it is a good strategy?  And Gale do you agree it is an
acceptable strategy, or would you veto it, if you had a veto? As you are
QM I think you do have a veto, and it is why I didn't put the idea into
action last August using DA to attract people.


--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: Proposal - Sprucing up 'getting involved'

Gale
Administrator
On 24 March 2017 at 15:51, James Crook <[hidden email]> wrote:

> On 3/24/2017 10:23 AM, Peter Sampson wrote:
>> Steve the Fiddle wrote:
>>> James Crook wrote:
>>>> Gale Andrews wrote:
>>>>> I don't know why we concentrate on early adopters. As far as I
>>>>> know we want testers, of whom early adopters are a subset.
>>>> Consider these calls to action:
>>>>
>>>> 1. (early adopter) "Get early access to work-in-progress on Audacity
>>>> that has exciting new features.  Not all of these features will become
>>>> mainstream, but your feedback on the features and bugs will help us
>>>> define future versions of Audacity"
>>>> 2. (tester) "Come and try out a buggy version of Audacity with your
>>>> projects, and really help us find the bugs so that other people can
>>>> benefit from a more stable Audacity"
>>>>
>>>> 2's are more valuable to us, but 1 is a massively more attractive
>>>> proposition to most people.
>>> Which is fine until we make a bad mistake and early adopters lose
>>> important work.
>>>
>>> My preference would be:
>>>
>>> 3. (tester) Get early access to exciting new features and help us
>>> define future versions of Audacity...
>>>
>> I think my preference would be (effectively 1 plus 2):
>>
>> 4. (tester) Get early access to exciting new features and help us
>> define future versions of Audacity. And help us find the bugs so that
>> other people can benefit from a more stable Audacity".
>>
>> Peter
> Are we vehemently agreeing again?  Both 3 and 4 are appeals to early
> adopters.

To me early adopters are the icing on the cake. People to do the
"hard work" are essential. I could become unavailable at any time
and Peter bless him is older than I am. Then what?

If we make it sound too much like "fun" we underplay the risk of
using pre-releases and minimise the chance that we will get
many or any nightly builds testers out of it.


> To be a bit clearer, we need to lead with the idea of new and exciting
> things to try out.

Yes but there are caveats too, and the bleeding edge nightly build
testers do have a more demanding (some might say, boring) task.

It needs a different level of commitment, and more willingness to
take risk.

I am sure you know what I talking about with channels (the Microsoft
Insider program calls them "rings"). For example
https://www.chromium.org/getting-involved/dev-channel .

"Nightly Builds", "Milestone builds" aka KTT (that we might call "beta" if
not for user misunderstanding of that term and 1.3 bugginess) and
"Releases" fall naturally into that scheme.

So you could sign up to a Google Group about Nightly Builds and a
Google Group about Milestone builds. Probably RC's would be in this
Milestone Group. We want more exciting names than these.

Branches about new work like Fish Eye or Punch In fall a little outside
this scheme as they would be intermittent builds between (and mostly
before) Milestone builds. They are not mutually exclusive of Nightly
Builds or Milestone builds. They do carry more risk than Milestones.
They could (for those testing the new feature) carry more risk than
nightlies.

DA would somewhat "stand outside" as an auteur build which is
a supply of someone's personal ideas that go beyond a specific
new feature, but aims for more stability than a feature-specific
build. But perhaps it fits most closely into this "feature" Group.
DA's code (in its entirety) is not likely to be in the Milestone builds.

I would guess these feature builds would be their own Google Group
too. Not everyone who is signed up will be interested in all of these
builds. Many may prefer to wait for the Milestone build to see if the
feature gets in, in which case it will probably be quite refined and stable
by then.


> The strategy I am prepared to work on involves exciting new experimental
> code.  In the process it exercises other new code added since 2.1.3.  We
> have a pool of people with different hardware giving bug and feature
> feedback.  Feature feedback on work in progress is going to auteurs, and
> there may be dialogue between the auteurs and this pool of engaged early
> adopters.
>
> I think it is a misconception that there are, say, 16 people out there
> who would volunteer to test the way we most need it, if we just make a
> call for that directly.

I am not convinced it is a misconception. Unless we say we also want
these people we most want, and let people know that nightly builds
actually exist, we have a self-fulfilling prophecy that we won't get these
people.

.

> Rather there are (at least) 30,000 people out
> there who will give new experimental code a try out.  Many of those
> would be willing to give a little feedback to us 'Subsonic Microphones
> don't work with Dolby enabled, for me'.  A few could get more involved
> than that.  16 may actually over time become testers.  That happens IF
> being part of the energy of the initiative is fun.
>
> I don't want to waste my time on a strategy that is based on the
> misconception of pre exisitng testers ready to volunteer, if only they
> knew it was needed.  The strategy I am going for is to get people using
> and communicating with us about new experimental versions.  Grow a small
> number of actual testers from that larger pool.
>
> So having explained the strategy I envisage more clearly,

Actually I already (and long ago) understand how you envisage it.


> Peter, Steve  do you agree it is a good strategy?  And Gale do you agree it is an
> acceptable strategy, or would you veto it, if you had a veto? As you are
> QM I think you do have a veto, and it is why I didn't put the idea into
> action last August using DA to attract people.

Team's feelings about DA is a separate issue as you know that we
must urgently resolve.

If things go well, DA will not be the only experimental build on offer.

As for so-called veto, why does it have to be one call for your early
adopters or no call?  I think the concept of different channels (which
in our case would manifest as different Google Groups) could work.

Fundamentally I don't think we can even have an initiative until we
sort out in our own mind the relationship/differences between KTT
and different types of "experimental build". Of course we also need
the resources to provide all the different types of build we envisage.
Are KTT's possible?

In my idea, we get as many people as we can signed up to each
Google Group. I don't imagine the nightly builds group will have the
interest of the other groups. But we won't know if it would be a complete
flop unless we try it. Is there really almost no-one on Chrome's Canary
channel? I don't believe that for a minute.



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: Proposal - Sprucing up 'getting involved'

James Crook
On 3/24/2017 9:25 PM, Gale Andrews wrote:

> On 24 March 2017 at 15:51, James Crook <[hidden email]> wrote:
>> On 3/24/2017 10:23 AM, Peter Sampson wrote:
>>> Steve the Fiddle wrote:
>>>> James Crook wrote:
>>>>> Gale Andrews wrote:
>>>>>> I don't know why we concentrate on early adopters. As far as I
>>>>>> know we want testers, of whom early adopters are a subset.
>>>>> Consider these calls to action:
>>>>>
>>>>> 1. (early adopter) "Get early access to work-in-progress on Audacity
>>>>> that has exciting new features.  Not all of these features will become
>>>>> mainstream, but your feedback on the features and bugs will help us
>>>>> define future versions of Audacity"
>>>>> 2. (tester) "Come and try out a buggy version of Audacity with your
>>>>> projects, and really help us find the bugs so that other people can
>>>>> benefit from a more stable Audacity"
>>>>>
>>>>> 2's are more valuable to us, but 1 is a massively more attractive
>>>>> proposition to most people.
>>>> Which is fine until we make a bad mistake and early adopters lose
>>>> important work.
>>>>
>>>> My preference would be:
>>>>
>>>> 3. (tester) Get early access to exciting new features and help us
>>>> define future versions of Audacity...
>>>>
>>> I think my preference would be (effectively 1 plus 2):
>>>
>>> 4. (tester) Get early access to exciting new features and help us
>>> define future versions of Audacity. And help us find the bugs so that
>>> other people can benefit from a more stable Audacity".
>>>
>>> Peter
>> Are we vehemently agreeing again?  Both 3 and 4 are appeals to early
>> adopters.
> To me early adopters are the icing on the cake.
-1
Early adopters are the key.  With them we have a pool of people who will
try some build that is not an official release.

> People to do the "hard work" are essential. I could become unavailable at any time
> and Peter bless him is older than I am. Then what?
+1
I am getting older too.


> If we make it sound too much like "fun" we underplay the risk of
> using pre-releases
+1
We need text explaining why official releases differ to these builds.

> and minimise the chance that we will get many or any nightly builds testers out of it.
-1.
Getting nightly-build testers depends on a connection first.  That
connection has to be initiated and then grow.

>
>> To be a bit clearer, we need to lead with the idea of new and exciting
>> things to try out.
> Yes but there are caveats too, and the bleeding edge nightly build
> testers do have a more demanding (some might say, boring) task.
+1
Yes they do.
> It needs a different level of commitment, and more willingness to
> take risk.
+1

> I am sure you know what I talking about with channels (the Microsoft
> Insider program calls them "rings"). For example
> https://www.chromium.org/getting-involved/dev-channel .
>
> "Nightly Builds", "Milestone builds" aka KTT (that we might call "beta" if
> not for user misunderstanding of that term and 1.3 bugginess) and
> "Releases" fall naturally into that scheme.
>
> So you could sign up to a Google Group about Nightly Builds and a
> Google Group about Milestone builds. Probably RC's would be in this
> Milestone Group. We want more exciting names than these.
>
> Branches about new work like Fish Eye or Punch In fall a little outside
> this scheme as they would be intermittent builds between (and mostly
> before) Milestone builds. They are not mutually exclusive of Nightly
> Builds or Milestone builds. They do carry more risk than Milestones.
> They could (for those testing the new feature) carry more risk than
> nightlies.
>
> DA would somewhat "stand outside" as an auteur build which is
> a supply of someone's personal ideas that go beyond a specific
> new feature, but aims for more stability than a feature-specific
> build. But perhaps it fits most closely into this "feature" Group.
> DA's code (in its entirety) is not likely to be in the Milestone builds.
>
> I would guess these feature builds would be their own Google Group
> too. Not everyone who is signed up will be interested in all of these
> builds. Many may prefer to wait for the Milestone build to see if the
> feature gets in, in which case it will probably be quite refined and stable
> by then.
-1
That sounds mad and unworkable to me.
We are surely not going to have a google group for each 'ring'?

It might be possible to have different boards on a forum, I suppose.  I
think it would still be cumbersome.

>
>> The strategy I am prepared to work on involves exciting new experimental
>> code.  In the process it exercises other new code added since 2.1.3.  We
>> have a pool of people with different hardware giving bug and feature
>> feedback.  Feature feedback on work in progress is going to auteurs, and
>> there may be dialogue between the auteurs and this pool of engaged early
>> adopters.
>>
>> I think it is a misconception that there are, say, 16 people out there
>> who would volunteer to test the way we most need it, if we just make a
>> call for that directly.
> I am not convinced it is a misconception. Unless we say we also want
> these people we most want, and let people know that nightly builds
> actually exist, we have a self-fulfilling prophecy that we won't get these
> people.

Sounds like an impasse then.

The kind of billing for testing that Steve and Peter are suggesting is
OK, as the OFFER of exciting new experimental builds is still clear.

>> Rather there are (at least) 30,000 people out
>> there who will give new experimental code a try out.  Many of those
>> would be willing to give a little feedback to us 'Subsonic Microphones
>> don't work with Dolby enabled, for me'.  A few could get more involved
>> than that.  16 may actually over time become testers.  That happens IF
>> being part of the energy of the initiative is fun.
>>
>> I don't want to waste my time on a strategy that is based on the
>> misconception of pre exisitng testers ready to volunteer, if only they
>> knew it was needed.  The strategy I am going for is to get people using
>> and communicating with us about new experimental versions.  Grow a small
>> number of actual testers from that larger pool.
>>
>> So having explained the strategy I envisage more clearly,
> Actually I already (and long ago) understand how you envisage it.
>
>
>> Peter, Steve  do you agree it is a good strategy?  And Gale do you agree it is an
>> acceptable strategy, or would you veto it, if you had a veto? As you are
>> QM I think you do have a veto, and it is why I didn't put the idea into
>> action last August using DA to attract people.
> Team's feelings about DA is a separate issue as you know that we
> must urgently resolve.
This conversation is about any experimental builds, and any new features
being checked into HEAD.  The relevance of DA is that we had an
opportunity to use DA this way last August and the offer was turned down
by you.

You seemed at the time to be saying we should demand people test
nightlies, because that is what we need.  You seemed to overlook that
experimental builds contain recent code, typically up to date with HEAD
and with other additions too.  You seemed to be saying encouraging
people to try out experimental builds was a pointless strategy.

Do you think encouraging people to try out experimental builds a
pointless strategy or do you think it acceptable?  You did not answer if
you think the early adopter strategy acceptable.


> If things go well, DA will not be the only experimental build on offer.
+1

> As for so-called veto, why does it have to be one call for your early
> adopters or no call?  I think the concept of different channels (which
> in our case would manifest as different Google Groups) could work.
If you have five or six CTAs on the same page you get less aggregate
response than having one.

I am willing to work on a CTA for early adopters as I believe that CTA
will feed through into vastly more people who are engaged with and
helping Audacity than other calls - and of course because I have already
put considerable time and energy into making the possibility of that CTA
being effective.

I am also OK with having a page with a CTA for out and out testers. I am
willing to put some work into that on icons wording and graphics,
working on text to show it is professional level of skill, showing how
things knit together to ensure quality for official releases.

My main focus is though on the early adopter CTA, because the response
to that is likely to repay work on it many more times over.  If we do
get 16 nightly testers from the second CTA I'd be delighted.


> Fundamentally I don't think we can even have an initiative until we
> sort out in our own mind the relationship/differences between KTT
> and different types of "experimental build". Of course we also need
> the resources to provide all the different types of build we envisage.
> Are KTT's possible?
Well I am sorted in my mind about these.
Auteur Builds (DA, FishEye), KTT (roughly half way to release), RCs,
Nightlies

KTTs are possible, but pointless without people to kick the tyres.



> In my idea, we get as many people as we can signed up to each
> Google Group. I don't imagine the nightly builds group will have the
> interest of the other groups. But we won't know if it would be a complete
> flop unless we try it.
-1
I've got bandwidth to run or co-run a google group for early adopters,
with a smattering of more dedicated folk in it, but not for a channel
for each 'ring'.  If you regard separating the different folk as an
essential, then forum or discourse or q2a are a better fit.
I suppose if you want to run/moderate the KTT, the RC and the nightly
channel each on a different google group yourself then I am '0'



> Is there really almost no-one on Chrome's Canary channel? I don't believe that for a minute.
Chrome canary is special/different.  The Google canary program is very
carefully worked out, with many employees volunteering/involved in the
test.  Canary is also pretty reliable/good/usable in a way that our
nightlies aren't.



>
>
>
> 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: Proposal - Sprucing up 'getting involved'

Gale
Administrator
On 24 March 2017 at 22:46, James Crook <[hidden email]> wrote:

> On 3/24/2017 9:25 PM, Gale Andrews wrote:
>> On 24 March 2017 at 15:51, James Crook <[hidden email]> wrote:
>>> On 3/24/2017 10:23 AM, Peter Sampson wrote:
>>>> Steve the Fiddle wrote:
>>>>> James Crook wrote:
>>>>>> Gale Andrews wrote:
>>>>>>> I don't know why we concentrate on early adopters. As far as I
>>>>>>> know we want testers, of whom early adopters are a subset.
>>>>>> Consider these calls to action:
>>>>>>
>>>>>> 1. (early adopter) "Get early access to work-in-progress on Audacity
>>>>>> that has exciting new features.  Not all of these features will become
>>>>>> mainstream, but your feedback on the features and bugs will help us
>>>>>> define future versions of Audacity"
>>>>>> 2. (tester) "Come and try out a buggy version of Audacity with your
>>>>>> projects, and really help us find the bugs so that other people can
>>>>>> benefit from a more stable Audacity"
>>>>>>
>>>>>> 2's are more valuable to us, but 1 is a massively more attractive
>>>>>> proposition to most people.
>>>>> Which is fine until we make a bad mistake and early adopters lose
>>>>> important work.
>>>>>
>>>>> My preference would be:
>>>>>
>>>>> 3. (tester) Get early access to exciting new features and help us
>>>>> define future versions of Audacity...
>>>>>
>>>> I think my preference would be (effectively 1 plus 2):
>>>>
>>>> 4. (tester) Get early access to exciting new features and help us
>>>> define future versions of Audacity. And help us find the bugs so that
>>>> other people can benefit from a more stable Audacity".
>>>>
>>>> Peter
>>> Are we vehemently agreeing again?  Both 3 and 4 are appeals to early
>>> adopters.
>> To me early adopters are the icing on the cake.
> -1
> Early adopters are the key.  With them we have a pool of people who will
> try some build that is not an official release.

And while better than not having that "pool", we agree it is not what
we most want.


>> People to do the "hard work" are essential. I could become unavailable at any time
>> and Peter bless him is older than I am. Then what?
> +1
> I am getting older too.
>
>
>> If we make it sound too much like "fun" we underplay the risk of
>> using pre-releases
> +1
> We need text explaining why official releases differ to these builds.
>
>> and minimise the chance that we will get many or any nightly builds testers out of it.
> -1.
> Getting nightly-build testers depends on a connection first.  That
> connection has to be initiated and then grow.

Then don't block us maklng that direct connection. And support me in
posting the nightly builds officially, instead of on strange private sites.


>>> To be a bit clearer, we need to lead with the idea of new and exciting
>>> things to try out.
>> Yes but there are caveats too, and the bleeding edge nightly build
>> testers do have a more demanding (some might say, boring) task.
> +1
> Yes they do.
>> It needs a different level of commitment, and more willingness to
>> take risk.
> +1
>
>> I am sure you know what I talking about with channels (the Microsoft
>> Insider program calls them "rings"). For example
>> https://www.chromium.org/getting-involved/dev-channel .
>>
>> "Nightly Builds", "Milestone builds" aka KTT (that we might call "beta" if
>> not for user misunderstanding of that term and 1.3 bugginess) and
>> "Releases" fall naturally into that scheme.
>>
>> So you could sign up to a Google Group about Nightly Builds and a
>> Google Group about Milestone builds. Probably RC's would be in this
>> Milestone Group. We want more exciting names than these.
>>
>> Branches about new work like Fish Eye or Punch In fall a little outside
>> this scheme as they would be intermittent builds between (and mostly
>> before) Milestone builds. They are not mutually exclusive of Nightly
>> Builds or Milestone builds. They do carry more risk than Milestones.
>> They could (for those testing the new feature) carry more risk than
>> nightlies.
>>
>> DA would somewhat "stand outside" as an auteur build which is
>> a supply of someone's personal ideas that go beyond a specific
>> new feature, but aims for more stability than a feature-specific
>> build. But perhaps it fits most closely into this "feature" Group.
>> DA's code (in its entirety) is not likely to be in the Milestone builds.
>>
>> I would guess these feature builds would be their own Google Group
>> too. Not everyone who is signed up will be interested in all of these
>> builds. Many may prefer to wait for the Milestone build to see if the
>> feature gets in, in which case it will probably be quite refined and stable
>> by then.
> -1
> That sounds mad and unworkable to me.

I thought hard before writing it. I have long thought your plan
inadequate.


> We are surely not going to have a google group for each 'ring'?

Will mixing "rings" into one Google Group work? I think not. The
early adopters won't want to be reading a lot of heavy detail about
nightly builds (should we be so lucky) and other things above their
heads or interest level.


> It might be possible to have different boards on a forum, I suppose.
> I think it would still be cumbersome.

Does that comment mean then that Google Groups are hard to manage ?
Please tell me what the problems are.

This is exactly why I wanted to sort out what "experimental builds" mean.
Perhaps we can manage with two Groups or Forum boards, nightlies
and other.

I suspect "experimental builds" just means James's DA project, to begin
with, right?


>>> The strategy I am prepared to work on involves exciting new experimental
>>> code.  In the process it exercises other new code added since 2.1.3.  We
>>> have a pool of people with different hardware giving bug and feature
>>> feedback.  Feature feedback on work in progress is going to auteurs, and
>>> there may be dialogue between the auteurs and this pool of engaged early
>>> adopters.
>>>
>>> I think it is a misconception that there are, say, 16 people out there
>>> who would volunteer to test the way we most need it, if we just make a
>>> call for that directly.
>> I am not convinced it is a misconception. Unless we say we also want
>> these people we most want, and let people know that nightly builds
>> actually exist, we have a self-fulfilling prophecy that we won't get these
>> people.
>
> Sounds like an impasse then.

Again, why must we have only an early adopters' call, or nothing?


> The kind of billing for testing that Steve and Peter are suggesting is
> OK, as the OFFER of exciting new experimental builds is still clear.

Good. I want "exciting, get to see it first" to be part of the advertising
to those testing experimental builds (with the caveats we agree about).


>>> Rather there are (at least) 30,000 people out
>>> there who will give new experimental code a try out.  Many of those
>>> would be willing to give a little feedback to us 'Subsonic Microphones
>>> don't work with Dolby enabled, for me'.  A few could get more involved
>>> than that.  16 may actually over time become testers.  That happens IF
>>> being part of the energy of the initiative is fun.
>>>
>>> I don't want to waste my time on a strategy that is based on the
>>> misconception of pre exisitng testers ready to volunteer, if only they
>>> knew it was needed.  The strategy I am going for is to get people using
>>> and communicating with us about new experimental versions.  Grow a small
>>> number of actual testers from that larger pool.
>>>
>>> So having explained the strategy I envisage more clearly,
>> Actually I already (and long ago) understand how you envisage it.
>>
>>
>>> Peter, Steve  do you agree it is a good strategy?  And Gale do you agree it is an
>>> acceptable strategy, or would you veto it, if you had a veto? As you are
>>> QM I think you do have a veto, and it is why I didn't put the idea into
>>> action last August using DA to attract people.
>> Team's feelings about DA is a separate issue as you know that we
>> must urgently resolve.
> This conversation is about any experimental builds, and any new features
> being checked into HEAD.

HEAD is nightly builds as well. Until you specify clearly, I don't know
what the conversation is about (you have now clarified below).


> The relevance of DA is that we had an opportunity to use DA this way last
> August and the offer was turned down by you.

Yes because there were internal differences about DA being a separate
project from Audacity.


> You seemed at the time to be saying we should demand people test
> nightlies, because that is what we need.  You seemed to overlook that
> experimental builds contain recent code, typically up to date with HEAD
> and with other additions too.

Experimental "release" or pre-release" builds forked off HEAD will indeed
contain modified HEAD at the time they are published, with the unmodified
parts gradually drifting out of date. I said this was definitely
better than not
having such builds/testers.

Even with this there is work in managing the feedback, but if you are
volunteering to do most of that management, why not?


> You seemed to be saying encouraging people to try out experimental
> builds was a pointless strategy.

I don't believe I ever said "pointless". It is I believe an insufficient
approach but better than nothing.


> Do you think encouraging people to try out experimental builds a
> pointless strategy or do you think it acceptable?  You did not answer if
> you think the early adopter strategy acceptable.

I have given my opinion on it in the previous paragraph and
elsewhere. I don't understand what the possible benefits are of
*not* having a separate initiative, advertised at the same time,
at least for nightly builds.


>> If things go well, DA will not be the only experimental build on offer.
> +1
>
>> As for so-called veto, why does it have to be one call for your early
>> adopters or no call?  I think the concept of different channels (which
>> in our case would manifest as different Google Groups) could work.
> If you have five or six CTAs on the same page you get less aggregate
> response than having one.

I guess that CTA might mean "Call to Action".

Nowhere have I asked for six calls to action.


> I am willing to work on a CTA for early adopters

Are you then the only one who is allowed to make a call for action?

> as I believe that CTA will feed through into vastly more people who are
>  engaged with and helping Audacity than other calls and of course
> because I have already put considerable time and energy into making
> the possibility of that CTA being effective.

Are you referring to DA again there?


> I am also OK with having a page with a CTA for out and out testers. I am
> willing to put some work into that on icons wording and graphics,
> working on text to show it is professional level of skill, showing how
> things knit together to ensure quality for official releases.

All right, that sounds like a few grains of compromise we might
be able to build on. I hope we can do so.


> My main focus is though on the early adopter CTA, because the response
> to that is likely to repay work on it many more times over.  If we do
> get 16 nightly testers from the second CTA I'd be delighted.

I don't think I was asking that you James had to do a testing CTA
yourself, or that you James had yourself to run any separate "place
to hang out" there might be for "testers".I was asking you not to
outright oppose those ideas.

To me, a separate place or places identified with some specific build
type is clearly preferable to wooliness.

Two CTA's would work for me, but I think it inadvisable to have the
"testers" hang out in the same place as the "early adopters".

Also I still don't see why this can't in principle be bundled as one
initiative. Still calling it "(testers)" as Steve/Peter suggested makes
it easier to bundle.

The idea of separate Groups was that it is clear what the differences
between the groups are and it is also clear that a person could sign
up to all (both) of the groups if they wanted.

Another benefit - the more casual "early adopters" won't need to
be bothered with text / download links about KTT/RC/nightlies.
If any of them do want to go further, they know where the other
Group is.


>> Fundamentally I don't think we can even have an initiative until we
>> sort out in our own mind the relationship/differences between KTT
>> and different types of "experimental build". Of course we also need
>> the resources to provide all the different types of build we envisage.
>> Are KTT's possible?
> Well I am sorted in my mind about these.
> Auteur Builds (DA, FishEye), KTT (roughly half way to release), RCs,
> Nightlies
>
> KTTs are possible, but pointless without people to kick the tyres.

So those are listed in increasing order of "boredom" and declining
likelihood of involvement, more or less.

Might it be better to go for Punch In (or preparation for Punch In)
above FishEye? I can't see the latter being the attraction that Punch
In would be, and I can see the benefit of getting extra feedback on the
interface of Punch In.

>
>
>> In my idea, we get as many people as we can signed up to each
>> Google Group. I don't imagine the nightly builds group will have the
>> interest of the other groups. But we won't know if it would be a complete
>> flop unless we try it.
> -1
> I've got bandwidth to run or co-run a google group for early adopters,
> with a smattering of more dedicated folk in it, but not for a channel
> for each 'ring'.  If you regard separating the different folk as an
> essential, then forum or discourse or q2a are a better fit.
> I suppose if you want to run/moderate the KTT, the RC and the nightly
> channel each on a different google group yourself then I am '0'

The RC could not stand on its own as a separate group, and I don't want
to go above three "channels". I was hampered by not knowing what your
experimental builds meant.

Clearly the most separate build type is the nightlies.


Gale


>> Is there really almost no-one on Chrome's Canary channel? I don't believe that for a minute.
> Chrome canary is special/different.  The Google canary program is very
> carefully worked out, with many employees volunteering/involved in the
> test.  Canary is also pretty reliable/good/usable in a way that our
> nightlies aren't.
>
>
>
>>
>>
>>
>> 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: Proposal - Sprucing up 'getting involved'

Peter Sampson-2
Gale wrote:
>  ... And support me in posting the nightly builds officially, instead of on
>strange private sites.

+1

I certainly would support that - it woulld make our nightly builds look more
accessible and a proper part of the project - more official.

Of couse there would need to be some serious "Here be dragons..." notices.


>Might it be better to go for Punch In (or preparation for Punch In)
>above FishEye? I can't see the latter being the attraction that Punch
>In would be, and I can see the benefit of getting extra feedback on the
>interface of Punch In.

+1

I think it would be much better to prioritize Punch-In over Fish-Eye, we
get lots of call for punch-in - only yesterday i captured a fresh vote for
this from a Facebook poster (who was clearly far from being a naive user
albeit at that stage a little unknowledgeable about the Audacity way of
doing things and its capabilities.

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: Proposal - Sprucing up 'getting involved'

James Crook
In reply to this post by Gale
On 3/25/2017 5:13 AM, Gale Andrews wrote:

> On 24 March 2017 at 22:46, James Crook <[hidden email]> wrote:
>> On 3/24/2017 9:25 PM, Gale Andrews wrote:
>>> On 24 March 2017 at 15:51, James Crook <[hidden email]> wrote:
>>>> On 3/24/2017 10:23 AM, Peter Sampson wrote:
>>>>> Steve the Fiddle wrote:
>>>>>> James Crook wrote:
>>>>>>> Gale Andrews wrote:
>>>>>>>> I don't know why we concentrate on early adopters. As far as I
>>>>>>>> know we want testers, of whom early adopters are a subset.
>>>>>>> Consider these calls to action:
>>>>>>>
>>>>>>> 1. (early adopter) "Get early access to work-in-progress on Audacity
>>>>>>> that has exciting new features.  Not all of these features will become
>>>>>>> mainstream, but your feedback on the features and bugs will help us
>>>>>>> define future versions of Audacity"
>>>>>>> 2. (tester) "Come and try out a buggy version of Audacity with your
>>>>>>> projects, and really help us find the bugs so that other people can
>>>>>>> benefit from a more stable Audacity"
>>>>>>>
>>>>>>> 2's are more valuable to us, but 1 is a massively more attractive
>>>>>>> proposition to most people.
>>>>>> Which is fine until we make a bad mistake and early adopters lose
>>>>>> important work.
>>>>>>
>>>>>> My preference would be:
>>>>>>
>>>>>> 3. (tester) Get early access to exciting new features and help us
>>>>>> define future versions of Audacity...
>>>>>>
>>>>> I think my preference would be (effectively 1 plus 2):
>>>>>
>>>>> 4. (tester) Get early access to exciting new features and help us
>>>>> define future versions of Audacity. And help us find the bugs so that
>>>>> other people can benefit from a more stable Audacity".
>>>>>
>>>>> Peter
>>>> Are we vehemently agreeing again?  Both 3 and 4 are appeals to early
>>>> adopters.
>>> To me early adopters are the icing on the cake.
>> -1
>> Early adopters are the key.  With them we have a pool of people who will
>> try some build that is not an official release.
> And while better than not having that "pool", we agree it is not what
> we most want.

Agree, but still maintain a more engaged 'pool' is a more likely
strategy to get us what we want.


>
>>> People to do the "hard work" are essential. I could become unavailable at any time
>>> and Peter bless him is older than I am. Then what?
>> +1
>> I am getting older too.
>>
>>
>>> If we make it sound too much like "fun" we underplay the risk of
>>> using pre-releases
>> +1
>> We need text explaining why official releases differ to these builds.
>>
>>> and minimise the chance that we will get many or any nightly builds testers out of it.
>> -1.
>> Getting nightly-build testers depends on a connection first.  That
>> connection has to be initiated and then grow.
> Then don't block us maklng that direct connection.
I don't block you in that.
> And support me in posting the nightly builds officially, instead of on strange private sites.
I do support that.

>
>>>> To be a bit clearer, we need to lead with the idea of new and exciting
>>>> things to try out.
>>> Yes but there are caveats too, and the bleeding edge nightly build
>>> testers do have a more demanding (some might say, boring) task.
>> +1
>> Yes they do.
>>> It needs a different level of commitment, and more willingness to
>>> take risk.
>> +1
>>
>>> I am sure you know what I talking about with channels (the Microsoft
>>> Insider program calls them "rings"). For example
>>> https://www.chromium.org/getting-involved/dev-channel .
>>>
>>> "Nightly Builds", "Milestone builds" aka KTT (that we might call "beta" if
>>> not for user misunderstanding of that term and 1.3 bugginess) and
>>> "Releases" fall naturally into that scheme.
>>>
>>> So you could sign up to a Google Group about Nightly Builds and a
>>> Google Group about Milestone builds. Probably RC's would be in this
>>> Milestone Group. We want more exciting names than these.
>>>
>>> Branches about new work like Fish Eye or Punch In fall a little outside
>>> this scheme as they would be intermittent builds between (and mostly
>>> before) Milestone builds. They are not mutually exclusive of Nightly
>>> Builds or Milestone builds. They do carry more risk than Milestones.
>>> They could (for those testing the new feature) carry more risk than
>>> nightlies.
>>>
>>> DA would somewhat "stand outside" as an auteur build which is
>>> a supply of someone's personal ideas that go beyond a specific
>>> new feature, but aims for more stability than a feature-specific
>>> build. But perhaps it fits most closely into this "feature" Group.
>>> DA's code (in its entirety) is not likely to be in the Milestone builds.
>>>
>>> I would guess these feature builds would be their own Google Group
>>> too. Not everyone who is signed up will be interested in all of these
>>> builds. Many may prefer to wait for the Milestone build to see if the
>>> feature gets in, in which case it will probably be quite refined and stable
>>> by then.
>> -1
>> That sounds mad and unworkable to me.
> I thought hard before writing it. I have long thought your plan
> inadequate.
>
>
>> We are surely not going to have a google group for each 'ring'?
> Will mixing "rings" into one Google Group work?
Could do.  Early-adopter-vladislav reports a unicode problem that isn't
actually from a new feature, and we believe is fixed in a nightly.  He
is an enthusiast, and tries out the nightly.  Confirms, YES it works.

> I think not.
I think supporting the most dedicated testers, more dedicated than vlad,
will depend on us having q2a too.  Then we can have questions like 'How
can I reproduce 42 (Timer Record doesn't stop)', 'How can I reproduce
1460 (RT effects disabled)' and vote up the best answers.

Again this allows mixing the rings, as people will filter the q2a
differently (using tags).

> The early adopters won't want to be reading a lot of heavy detail about
> nightly builds (should we be so lucky) and other things above their
> heads or interest level.
If we should be so lucky, engaging one to one off list if it is just one
or two could work.  If it's more than one or two you/we could create an
email-list then, or work to make this quality@ list suitable for them too.

>
>> It might be possible to have different boards on a forum, I suppose.
>> I think it would still be cumbersome.
> Does that comment mean then that Google Groups are hard to manage ?
> Please tell me what the problems are.
No more so than an ordinary moderated email list.

> This is exactly why I wanted to sort out what "experimental builds" mean.
> Perhaps we can manage with two Groups or Forum boards, nightlies
> and other.
Yes (modified).
Group 1: Early adopters with mention of KTT (if we do KTT)
Group 2: Dedicated testers, nightlies, culminating in RCs.

> I suspect "experimental builds" just means James's DA project, to begin
> with, right?
No actually, because the key DA changes are already (now) filtering into
audacity head itself.  The experimental builds during 2.2.0 are most
likely to be one from Paul, one with MIDI_OUT and possibly a branch-line
build (by me) giving Robert's 'selection' menu a try out
(EXPERIMENTAL_SELECTION_MENU).

Early adopters will have plenty of cool new stuff to try out with those
experimental builds, plus the menu rearrangement,  plus the theme
changes from head.




>
>>>> The strategy I am prepared to work on involves exciting new experimental
>>>> code.  In the process it exercises other new code added since 2.1.3.  We
>>>> have a pool of people with different hardware giving bug and feature
>>>> feedback.  Feature feedback on work in progress is going to auteurs, and
>>>> there may be dialogue between the auteurs and this pool of engaged early
>>>> adopters.
>>>>
>>>> I think it is a misconception that there are, say, 16 people out there
>>>> who would volunteer to test the way we most need it, if we just make a
>>>> call for that directly.
>>> I am not convinced it is a misconception. Unless we say we also want
>>> these people we most want, and let people know that nightly builds
>>> actually exist, we have a self-fulfilling prophecy that we won't get these
>>> people.
>> Sounds like an impasse then.
> Again, why must we have only an early adopters' call, or nothing?
As I have said, we can have one page for an early adopter CTA, one for a
tester CTA.

I don't want the early-adopter CTA kiboshed by a message 'come and work
really hard doing unrewarding work on buggy versions of Audacity so that
other people can benefit'.  Instead, on a different page, we need a CTA
for dedicated testers.

>> The kind of billing for testing that Steve and Peter are suggesting is
>> OK, as the OFFER of exciting new experimental builds is still clear.
> Good. I want "exciting, get to see it first" to be part of the advertising
> to those testing experimental builds (with the caveats we agree about).
Fine.

>
>>>> Rather there are (at least) 30,000 people out
>>>> there who will give new experimental code a try out.  Many of those
>>>> would be willing to give a little feedback to us 'Subsonic Microphones
>>>> don't work with Dolby enabled, for me'.  A few could get more involved
>>>> than that.  16 may actually over time become testers.  That happens IF
>>>> being part of the energy of the initiative is fun.
>>>>
>>>> I don't want to waste my time on a strategy that is based on the
>>>> misconception of pre exisitng testers ready to volunteer, if only they
>>>> knew it was needed.  The strategy I am going for is to get people using
>>>> and communicating with us about new experimental versions.  Grow a small
>>>> number of actual testers from that larger pool.
>>>>
>>>> So having explained the strategy I envisage more clearly,
>>> Actually I already (and long ago) understand how you envisage it.
>>>
>>>
>>>> Peter, Steve  do you agree it is a good strategy?  And Gale do you agree it is an
>>>> acceptable strategy, or would you veto it, if you had a veto? As you are
>>>> QM I think you do have a veto, and it is why I didn't put the idea into
>>>> action last August using DA to attract people.
>>> Team's feelings about DA is a separate issue as you know that we
>>> must urgently resolve.
>> This conversation is about any experimental builds, and any new features
>> being checked into HEAD.
> HEAD is nightly builds as well. Until you specify clearly, I don't know
> what the conversation is about (you have now clarified below).
But I think we vehemently agree that early-adopters will be offered
selected 'good' builds from HEAD, rather than every single nightly.

>
>> The relevance of DA is that we had an opportunity to use DA this way last
>> August and the offer was turned down by you.
> Yes because there were internal differences about DA being a separate
> project from Audacity.
>
>
>> You seemed at the time to be saying we should demand people test
>> nightlies, because that is what we need.  You seemed to overlook that
>> experimental builds contain recent code, typically up to date with HEAD
>> and with other additions too.
> Experimental "release" or pre-release" builds forked off HEAD will indeed
> contain modified HEAD at the time they are published, with the unmodified
> parts gradually drifting out of date. I said this was definitely
> better than not having such builds/testers.
When there is a refresh of an experimental build, it can pick up what is
in HEAD again.  Have a look at the git history for DA. You'll see merges
from HEAD into it.

> Even with this there is work in managing the feedback, but if you are
> volunteering to do most of that management, why not?
I am volunteering to manage the early-adopter list.  If Paul chooses to
do an auteur build during 2.2.0 I'll expect him to field feedback on his
build.

>
>> You seemed to be saying encouraging people to try out experimental
>> builds was a pointless strategy.
> I don't believe I ever said "pointless". It is I believe an insufficient
> approach but better than nothing.
>
>
>> Do you think encouraging people to try out experimental builds a
>> pointless strategy or do you think it acceptable?  You did not answer if
>> you think the early adopter strategy acceptable.
> I have given my opinion on it in the previous paragraph and
> elsewhere. I don't understand what the possible benefits are of
> *not* having a separate initiative, advertised at the same time,
> at least for nightly builds.
We're (now) agreed we're having two CTAs, one for early adopters, one
for nightly testers.  (I think).

If you have a nightlies google-group, then the second CTA is basically
'sign up to that'.  And you take it from there if any people at all do
arrive there?



>
>
>>> If things go well, DA will not be the only experimental build on offer.
>> +1
>>
>>> As for so-called veto, why does it have to be one call for your early
>>> adopters or no call?  I think the concept of different channels (which
>>> in our case would manifest as different Google Groups) could work.
>> If you have five or six CTAs on the same page you get less aggregate
>> response than having one.
> I guess that CTA might mean "Call to Action".
Yes.

> Nowhere have I asked for six calls to action.
Our 'community' page http://www.audacityteam.org/community/ is in a
sense 5 different calls to action, which is one reason it isn't working.

I felt you might have been suggesting a separate call for each
'ring/channel'?

>
>> I am willing to work on a CTA for early adopters
> Are you then the only one who is allowed to make a call for action?
Far from it.

>
>> as I believe that CTA will feed through into vastly more people who are
>>   engaged with and helping Audacity than other calls and of course
>> because I have already put considerable time and energy into making
>> the possibility of that CTA being effective.
> Are you referring to DA again there?
Yes.
DA is magnet content to attract early adopters.


>
>> I am also OK with having a page with a CTA for out and out testers. I am
>> willing to put some work into that on icons wording and graphics,
>> working on text to show it is professional level of skill, showing how
>> things knit together to ensure quality for official releases.
> All right, that sounds like a few grains of compromise we might
> be able to build on. I hope we can do so.
>
>
>> My main focus is though on the early adopter CTA, because the response
>> to that is likely to repay work on it many more times over.  If we do
>> get 16 nightly testers from the second CTA I'd be delighted.
> I don't think I was asking that you James had to do a testing CTA
> yourself, or that you James had yourself to run any separate "place
> to hang out" there might be for "testers".I was asking you not to
> outright oppose those ideas.
I don't oppose the idea.

> To me, a separate place or places identified with some specific build
> type is clearly preferable to wooliness.
>
> Two CTA's would work for me, but I think it inadvisable to have the
> "testers" hang out in the same place as the "early adopters".
So two google groups.

I think that as q2a takes off, it will become a team resource and people
with many different interests in helping Audacity progress will
contribute to it.  Early adopters and nightly-testers will mingle on it.


> Also I still don't see why this can't in principle be bundled as one
> initiative. Still calling it "(testers)" as Steve/Peter suggested makes
> it easier to bundle.
You'll need to clarify.
Launching both initiatives at the same time is worth doing.  Clearly the
two initiatives aren't asking for the same thing from people who get
involved.

> The idea of separate Groups was that it is clear what the differences
> between the groups are and it is also clear that a person could sign
> up to all (both) of the groups if they wanted.
Still possible.


> Another benefit - the more casual "early adopters" won't need to
> be bothered with text / download links about KTT/RC/nightlies.
> If any of them do want to go further, they know where the other
> Group is.
OK.  Look forward to refinement of the KTT/RCs/Nightlies group by you.


>
>>> Fundamentally I don't think we can even have an initiative until we
>>> sort out in our own mind the relationship/differences between KTT
>>> and different types of "experimental build". Of course we also need
>>> the resources to provide all the different types of build we envisage.
>>> Are KTT's possible?
>> Well I am sorted in my mind about these.
>> Auteur Builds (DA, FishEye), KTT (roughly half way to release), RCs,
>> Nightlies
>>
>> KTTs are possible, but pointless without people to kick the tyres.
> So those are listed in increasing order of "boredom" and declining
> likelihood of involvement, more or less.
Yes.

> Might it be better to go for Punch In (or preparation for Punch In)
> above FishEye?
Yes.
Whether and what Paul offers as an experimental build is Paul's call.


> I can't see the latter being the attraction that Punch
> In would be, and I can see the benefit of getting extra feedback on the
> interface of Punch In.
>
>>
>>> In my idea, we get as many people as we can signed up to each
>>> Google Group. I don't imagine the nightly builds group will have the
>>> interest of the other groups. But we won't know if it would be a complete
>>> flop unless we try it.
>> -1
>> I've got bandwidth to run or co-run a google group for early adopters,
>> with a smattering of more dedicated folk in it, but not for a channel
>> for each 'ring'.  If you regard separating the different folk as an
>> essential, then forum or discourse or q2a are a better fit.
>> I suppose if you want to run/moderate the KTT, the RC and the nightly
>> channel each on a different google group yourself then I am '0'
> The RC could not stand on its own as a separate group, and I don't want
> to go above three "channels". I was hampered by not knowing what your
> experimental builds meant.
>
> Clearly the most separate build type is the nightlies.
>
>
> Gale
>
>
>>> Is there really almost no-one on Chrome's Canary channel? I don't believe that for a minute.
>> Chrome canary is special/different.  The Google canary program is very
>> carefully worked out, with many employees volunteering/involved in the
>> test.  Canary is also pretty reliable/good/usable in a way that our
>> nightlies aren't.
>>
>>
>>
>>>
>>>
>>> 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: Proposal - Sprucing up 'getting involved'

Stevethefiddle
In reply to this post by James Crook
Returning to the original proposals...
(I shall use the term "testers" as a general term for people using and
giving feedback, whether as "beta testers", "early adopters" or
whatever).

On 23 March 2017 at 13:09, James Crook <[hidden email]> wrote:
> I'm looking at improving our 'Get Involved' pages.
>
> http://www.audacityteam.org/community/

+1

>
> I'd like to add icons for the different ways of getting involved.  We're
> very text heavy currently.

+1 for making the website less "text heavy".

>
>
> I'd like to add a new page for the early adopters initiative.
> The question is where to direct early adopters to.
>
> * If we were further ahead with Q2A I would say that would be the place,
> and the questions would be about enhancement requests and the new features.
> * The most likely option at this stage is instead a google group, which
> gives us an email list again that we can announce on.
> * A third option is a board on the forum.
> * A fourth is to direct people here on the quality list.  We might have
> to change how we use this list quite a bit though.

-1 for using an email list as the primary forum for testers. While
email lists are a favourite for developers, this is not for
developers, so let's use a format that is more popular with the
general public.

Perhaps we will need more than one communication channel for testers,
but for the purpose of launching a "testers" initiative, we need to
have one primary channel. That communication channel needs to be
enticing / engaging for "testers", and needs to be *effective*.

What does *effective* mean? What outcomes are we looking for? In
deciding on the primary communication channel for testers, this must
be the most important question.

Steve

>
> --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: Proposal - Sprucing up 'getting involved'

James Crook
On 3/25/2017 9:35 AM, Steve the Fiddle wrote:

> Returning to the original proposals...
> (I shall use the term "testers" as a general term for people using and
> giving feedback, whether as "beta testers", "early adopters" or
> whatever).
>
> On 23 March 2017 at 13:09, James Crook <[hidden email]> wrote:
>> I'm looking at improving our 'Get Involved' pages.
>>
>> http://www.audacityteam.org/community/
> +1
>
>> I'd like to add icons for the different ways of getting involved.  We're
>> very text heavy currently.
> +1 for making the website less "text heavy".
>
>>
>> I'd like to add a new page for the early adopters initiative.
>> The question is where to direct early adopters to.
>>
>> * If we were further ahead with Q2A I would say that would be the place,
>> and the questions would be about enhancement requests and the new features.
>> * The most likely option at this stage is instead a google group, which
>> gives us an email list again that we can announce on.
>> * A third option is a board on the forum.
>> * A fourth is to direct people here on the quality list.  We might have
>> to change how we use this list quite a bit though.
> -1 for using an email list as the primary forum for testers. While
> email lists are a favourite for developers, this is not for
> developers, so let's use a format that is more popular with the
> general public.
>
> Perhaps we will need more than one communication channel for testers,
> but for the purpose of launching a "testers" initiative, we need to
> have one primary channel. That communication channel needs to be
> enticing / engaging for "testers", and needs to be *effective*.
There needs to be SOME channel which is essentially a push channel with
announcements, e.g. that Build-X is available.  The sizzlier stuff is
eminently suitable for FB.  Each such sizzly post would need the word
EXPERIMENTAL on it though, to avoid seducing random visitors who are
just interested in very stable releases.

'Discourse' could work as a channel for the nitty gritty two-way
conversation.  I think 'q2a' would work better.

I'm very happy to do early-adopters on q2a (without a google group) and
using facebook instead for our announces.  I don't know what Gale would
be most happy with for dedicated-testers.  Certainly they'd be welcome
to share the q2a, as I don't see dedicated-testers getting in the way of
the early-adopters there or vise-versa.

Steve, what do you specifically suggest?  Would FB + q2a sound plausible
to you as an approach (for the early-adopters)?


> What does *effective* mean? What outcomes are we looking for? In deciding on the primary communication channel for testers, this must be the most important question.
How would you word the goals Steve?

> Steve
>


------------------------------------------------------------------------------
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: Proposal - Sprucing up 'getting involved'

Stevethefiddle
On 25 March 2017 at 12:36, James Crook <[hidden email]> wrote:

> On 3/25/2017 9:35 AM, Steve the Fiddle wrote:
>> Returning to the original proposals...
>> (I shall use the term "testers" as a general term for people using and
>> giving feedback, whether as "beta testers", "early adopters" or
>> whatever).
>>
>> On 23 March 2017 at 13:09, James Crook <[hidden email]> wrote:
>>> I'm looking at improving our 'Get Involved' pages.
>>>
>>> http://www.audacityteam.org/community/
>> +1
>>
>>> I'd like to add icons for the different ways of getting involved.  We're
>>> very text heavy currently.
>> +1 for making the website less "text heavy".
>>
>>>
>>> I'd like to add a new page for the early adopters initiative.
>>> The question is where to direct early adopters to.
>>>
>>> * If we were further ahead with Q2A I would say that would be the place,
>>> and the questions would be about enhancement requests and the new features.
>>> * The most likely option at this stage is instead a google group, which
>>> gives us an email list again that we can announce on.
>>> * A third option is a board on the forum.
>>> * A fourth is to direct people here on the quality list.  We might have
>>> to change how we use this list quite a bit though.
>> -1 for using an email list as the primary forum for testers. While
>> email lists are a favourite for developers, this is not for
>> developers, so let's use a format that is more popular with the
>> general public.
>>
>> Perhaps we will need more than one communication channel for testers,
>> but for the purpose of launching a "testers" initiative, we need to
>> have one primary channel. That communication channel needs to be
>> enticing / engaging for "testers", and needs to be *effective*.
> There needs to be SOME channel which is essentially a push channel with
> announcements, e.g. that Build-X is available.  The sizzlier stuff is
> eminently suitable for FB.  Each such sizzly post would need the word
> EXPERIMENTAL on it though, to avoid seducing random visitors who are
> just interested in very stable releases.
>
> 'Discourse' could work as a channel for the nitty gritty two-way
> conversation.  I think 'q2a' would work better.
>
> I'm very happy to do early-adopters on q2a (without a google group) and
> using facebook instead for our announces.  I don't know what Gale would
> be most happy with for dedicated-testers.  Certainly they'd be welcome
> to share the q2a, as I don't see dedicated-testers getting in the way of
> the early-adopters there or vise-versa.
>
> Steve, what do you specifically suggest?  Would FB + q2a sound plausible
> to you as an approach (for the early-adopters)?

Certainly "plausible".
I think fb is a good idea for the "announce" part.
I don't know how well q2a will work for other goals, but I'm not sure
what your other goals are. If you think it  will work, then I see no
harm in trying it. (Nothing ventured, nothing gained).

>
>
>> What does *effective* mean? What outcomes are we looking for? In deciding on the primary communication channel for testers, this must be the most important question.
> How would you word the goals Steve?

"Feedback" is probably the main goal isn't it?

Steve

>
>> Steve
>>

------------------------------------------------------------------------------
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: Proposal - Sprucing up 'getting involved'

James Crook
On 3/25/2017 4:37 PM, Steve the Fiddle wrote:

> On 25 March 2017 at 12:36, James Crook <[hidden email]> wrote:
>> Steve, what do you specifically suggest? Would FB + q2a sound
>> plausible to you as an approach (for the early-adopters)?
> Certainly "plausible".
> I think fb is a good idea for the "announce" part.
> I don't know how well q2a will work for other goals, but I'm not sure
> what your other goals are. If you think it  will work, then I see no
> harm in trying it. (Nothing ventured, nothing gained).
>
>>
>>> What does *effective* mean? What outcomes are we looking for? In deciding on the primary communication channel for testers, this must be the most important question.
>> How would you word the goals Steve?
> "Feedback" is probably the main goal isn't it?
Perhaps "Engagement"?
We already get some 'feedback' from feedback@, but it tends to be
fly-by.  I'm looking to get contributors who give more constructive
feedback, over a longer time.  Yes, it is feedback, but of a certain kind.

--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: Proposal - Sprucing up 'getting involved'

Gale
Administrator
In reply to this post by James Crook
On 25 March 2017 at 09:28, James Crook <[hidden email]> wrote:

> On 3/25/2017 5:13 AM, Gale Andrews wrote:
>> On 24 March 2017 at 22:46, James Crook <[hidden email]> wrote:
>>> On 3/24/2017 9:25 PM, Gale Andrews wrote:
>>>> On 24 March 2017 at 15:51, James Crook <[hidden email]> wrote:
>>>>> On 3/24/2017 10:23 AM, Peter Sampson wrote:
>>>>>> Steve the Fiddle wrote:
>>>>>>> James Crook wrote:
>>>>>>>> Gale Andrews wrote:
>>>>>>>>> I don't know why we concentrate on early adopters. As far as I
>>>>>>>>> know we want testers, of whom early adopters are a subset.
>>>>>>>> Consider these calls to action:
>>>>>>>>
>>>>>>>> 1. (early adopter) "Get early access to work-in-progress on Audacity
>>>>>>>> that has exciting new features.  Not all of these features will become
>>>>>>>> mainstream, but your feedback on the features and bugs will help us
>>>>>>>> define future versions of Audacity"
>>>>>>>> 2. (tester) "Come and try out a buggy version of Audacity with your
>>>>>>>> projects, and really help us find the bugs so that other people can
>>>>>>>> benefit from a more stable Audacity"
>>>>>>>>
>>>>>>>> 2's are more valuable to us, but 1 is a massively more attractive
>>>>>>>> proposition to most people.
>>>>>>> Which is fine until we make a bad mistake and early adopters lose
>>>>>>> important work.
>>>>>>>
>>>>>>> My preference would be:
>>>>>>>
>>>>>>> 3. (tester) Get early access to exciting new features and help us
>>>>>>> define future versions of Audacity...
>>>>>>>
>>>>>> I think my preference would be (effectively 1 plus 2):
>>>>>>
>>>>>> 4. (tester) Get early access to exciting new features and help us
>>>>>> define future versions of Audacity. And help us find the bugs so that
>>>>>> other people can benefit from a more stable Audacity".
>>>>>>
>>>>>> Peter
>>>>> Are we vehemently agreeing again?  Both 3 and 4 are appeals to early
>>>>> adopters.
>>>> To me early adopters are the icing on the cake.
>>> -1
>>> Early adopters are the key.  With them we have a pool of people who will
>>> try some build that is not an official release.
>> And while better than not having that "pool", we agree it is not what
>> we most want.
>
> Agree, but still maintain a more engaged 'pool' is a more likely
> strategy to get us what we want.
>
>
>>
>>>> People to do the "hard work" are essential. I could become unavailable at any time
>>>> and Peter bless him is older than I am. Then what?
>>> +1
>>> I am getting older too.
>>>
>>>
>>>> If we make it sound too much like "fun" we underplay the risk of
>>>> using pre-releases
>>> +1
>>> We need text explaining why official releases differ to these builds.
>>>
>>>> and minimise the chance that we will get many or any nightly builds testers out of it.
>>> -1.
>>> Getting nightly-build testers depends on a connection first.  That
>>> connection has to be initiated and then grow.
>> Then don't block us maklng that direct connection.
> I don't block you in that.
>> And support me in posting the nightly builds officially, instead of on strange private sites.
> I do support that.

Good.


>>>>> To be a bit clearer, we need to lead with the idea of new and exciting
>>>>> things to try out.
>>>> Yes but there are caveats too, and the bleeding edge nightly build
>>>> testers do have a more demanding (some might say, boring) task.
>>> +1
>>> Yes they do.
>>>> It needs a different level of commitment, and more willingness to
>>>> take risk.
>>> +1
>>>
>>>> I am sure you know what I talking about with channels (the Microsoft
>>>> Insider program calls them "rings"). For example
>>>> https://www.chromium.org/getting-involved/dev-channel .
>>>>
>>>> "Nightly Builds", "Milestone builds" aka KTT (that we might call "beta" if
>>>> not for user misunderstanding of that term and 1.3 bugginess) and
>>>> "Releases" fall naturally into that scheme.
>>>>
>>>> So you could sign up to a Google Group about Nightly Builds and a
>>>> Google Group about Milestone builds. Probably RC's would be in this
>>>> Milestone Group. We want more exciting names than these.
>>>>
>>>> Branches about new work like Fish Eye or Punch In fall a little outside
>>>> this scheme as they would be intermittent builds between (and mostly
>>>> before) Milestone builds. They are not mutually exclusive of Nightly
>>>> Builds or Milestone builds. They do carry more risk than Milestones.
>>>> They could (for those testing the new feature) carry more risk than
>>>> nightlies.
>>>>
>>>> DA would somewhat "stand outside" as an auteur build which is
>>>> a supply of someone's personal ideas that go beyond a specific
>>>> new feature, but aims for more stability than a feature-specific
>>>> build. But perhaps it fits most closely into this "feature" Group.
>>>> DA's code (in its entirety) is not likely to be in the Milestone builds.
>>>>
>>>> I would guess these feature builds would be their own Google Group
>>>> too. Not everyone who is signed up will be interested in all of these
>>>> builds. Many may prefer to wait for the Milestone build to see if the
>>>> feature gets in, in which case it will probably be quite refined and stable
>>>> by then.
>>> -1
>>> That sounds mad and unworkable to me.
>> I thought hard before writing it. I have long thought your plan
>> inadequate.
>>
>>
>>> We are surely not going to have a google group for each 'ring'?
>> Will mixing "rings" into one Google Group work?
> Could do.  Early-adopter-vladislav reports a unicode problem that isn't
> actually from a new feature, and we believe is fixed in a nightly.  He
> is an enthusiast, and tries out the nightly.  Confirms, YES it works.

To some extent this depends how many early adopters are "enthusiasts"
and whether they bore the less enthusiastic.

If he became very enthusiastic and installed the nightlies regularly I
don't see him belonging so clearly in an early adopters group that
was the only group.

>> I think not.
> I think supporting the most dedicated testers, more dedicated than vlad,
> will depend on us having q2a too.  Then we can have questions like 'How
> can I reproduce 42 (Timer Record doesn't stop)', 'How can I reproduce
> 1460 (RT effects disabled)' and vote up the best answers.

I "vote" -1 to Q2A before we try it amongst ourselves.  And I am still not
convinced we want the above sort of material asked about and reported
back on in an early adopters group.

If you have direct experience from DA that the different skill levels play
well together, and given I do want to have some call for higher level testers,
then I suppose we could try it with one group.

I think it is probably a mistake, based on expectation but not evidence.

Do the others have insight?


> Again this allows mixing the rings, as people will filter the q2a
> differently (using tags).
>
>> The early adopters won't want to be reading a lot of heavy detail about
>> nightly builds (should we be so lucky) and other things above their
>> heads or interest level.
> If we should be so lucky, engaging one to one off list if it is just one
> or two could work.  If it's more than one or two you/we could create an
> email-list then, or work to make this quality@ list suitable for them too.

If there was from the start a separate list for dedicated testers that
was part of the initiative, might that not create some impetus of its
own?


>>> It might be possible to have different boards on a forum, I suppose.
>>> I think it would still be cumbersome.
>> Does that comment mean then that Google Groups are hard to manage ?
>> Please tell me what the problems are.
> No more so than an ordinary moderated email list.
>
>> This is exactly why I wanted to sort out what "experimental builds" mean.
>> Perhaps we can manage with two Groups or Forum boards, nightlies
>> and other.
> Yes (modified).
> Group 1: Early adopters with mention of KTT (if we do KTT)
> Group 2: Dedicated testers, nightlies, culminating in RCs.

Alright. I would hope your early adopters would be more engaged than
the average user and that some would test the RC's. It's a balance.


>> I suspect "experimental builds" just means James's DA project, to begin
>> with, right?
> No actually, because the key DA changes are already (now) filtering into
> audacity head itself.  The experimental builds during 2.2.0 are most
> likely to be one from Paul, one with MIDI_OUT and possibly a branch-line
> build (by me) giving Robert's 'selection' menu a try out
> (EXPERIMENTAL_SELECTION_MENU).

> Early adopters will have plenty of cool new stuff to try out with those
> experimental builds, plus the menu rearrangement,  plus the theme
> changes from head.

I hope we can avoid the use of the term "auteur" builds until Team's
views on these and DA are clarified.


>>>>> The strategy I am prepared to work on involves exciting new experimental
>>>>> code.  In the process it exercises other new code added since 2.1.3.  We
>>>>> have a pool of people with different hardware giving bug and feature
>>>>> feedback.  Feature feedback on work in progress is going to auteurs, and
>>>>> there may be dialogue between the auteurs and this pool of engaged early
>>>>> adopters.
>>>>>
>>>>> I think it is a misconception that there are, say, 16 people out there
>>>>> who would volunteer to test the way we most need it, if we just make a
>>>>> call for that directly.
>>>> I am not convinced it is a misconception. Unless we say we also want
>>>> these people we most want, and let people know that nightly builds
>>>> actually exist, we have a self-fulfilling prophecy that we won't get these
>>>> people.
>>> Sounds like an impasse then.
>> Again, why must we have only an early adopters' call, or nothing?
> As I have said, we can have one page for an early adopter CTA, one for a
> tester CTA.
>
> I don't want the early-adopter CTA kiboshed by a message 'come and work
> really hard doing unrewarding work on buggy versions of Audacity so that
> other people can benefit'.  Instead, on a different page, we need a CTA
> for dedicated testers.

I really hope you are not going to be as dismissive as that about
dedicated testers. In some cases these dedicated testers do get
to see the latest features before anyone.

And we are not going to boot them out of any group there is for them
if they are only occasional bug reporters/testers of the nightlies.


>>> The kind of billing for testing that Steve and Peter are suggesting is
>>> OK, as the OFFER of exciting new experimental builds is still clear.
>> Good. I want "exciting, get to see it first" to be part of the advertising
>> to those testing experimental builds (with the caveats we agree about).
> Fine.
>
>>
>>>>> Rather there are (at least) 30,000 people out
>>>>> there who will give new experimental code a try out.  Many of those
>>>>> would be willing to give a little feedback to us 'Subsonic Microphones
>>>>> don't work with Dolby enabled, for me'.  A few could get more involved
>>>>> than that.  16 may actually over time become testers.  That happens IF
>>>>> being part of the energy of the initiative is fun.
>>>>>
>>>>> I don't want to waste my time on a strategy that is based on the
>>>>> misconception of pre exisitng testers ready to volunteer, if only they
>>>>> knew it was needed.  The strategy I am going for is to get people using
>>>>> and communicating with us about new experimental versions.  Grow a small
>>>>> number of actual testers from that larger pool.
>>>>>
>>>>> So having explained the strategy I envisage more clearly,
>>>> Actually I already (and long ago) understand how you envisage it.
>>>>
>>>>
>>>>> Peter, Steve  do you agree it is a good strategy?  And Gale do you agree it is an
>>>>> acceptable strategy, or would you veto it, if you had a veto? As you are
>>>>> QM I think you do have a veto, and it is why I didn't put the idea into
>>>>> action last August using DA to attract people.
>>>> Team's feelings about DA is a separate issue as you know that we
>>>> must urgently resolve.
>>> This conversation is about any experimental builds, and any new features
>>> being checked into HEAD.
>> HEAD is nightly builds as well. Until you specify clearly, I don't know
>> what the conversation is about (you have now clarified below).
> But I think we vehemently agree that early-adopters will be offered
> selected 'good' builds from HEAD, rather than every single nightly.
>
>>
>>> The relevance of DA is that we had an opportunity to use DA this way last
>>> August and the offer was turned down by you.
>> Yes because there were internal differences about DA being a separate
>> project from Audacity.
>>
>>
>>> You seemed at the time to be saying we should demand people test
>>> nightlies, because that is what we need.  You seemed to overlook that
>>> experimental builds contain recent code, typically up to date with HEAD
>>> and with other additions too.
>> Experimental "release" or pre-release" builds forked off HEAD will indeed
>> contain modified HEAD at the time they are published, with the unmodified
>> parts gradually drifting out of date. I said this was definitely
>> better than not having such builds/testers.
> When there is a refresh of an experimental build, it can pick up what is
> in HEAD again.  Have a look at the git history for DA. You'll see merges
> from HEAD into it.
>
>> Even with this there is work in managing the feedback, but if you are
>> volunteering to do most of that management, why not?
> I am volunteering to manage the early-adopter list.  If Paul chooses to
> do an auteur build during 2.2.0 I'll expect him to field feedback on his
> build.

This feedback managed by Paul will be on the early adopters Group
won't it?


>>> You seemed to be saying encouraging people to try out experimental
>>> builds was a pointless strategy.
>> I don't believe I ever said "pointless". It is I believe an insufficient
>> approach but better than nothing.
>>
>>
>>> Do you think encouraging people to try out experimental builds a
>>> pointless strategy or do you think it acceptable?  You did not answer if
>>> you think the early adopter strategy acceptable.
>> I have given my opinion on it in the previous paragraph and
>> elsewhere. I don't understand what the possible benefits are of
>> *not* having a separate initiative, advertised at the same time,
>> at least for nightly builds.
> We're (now) agreed we're having two CTAs, one for early adopters, one
> for nightly testers.  (I think).

Yes, broad agreement on that.


> If you have a nightlies google-group, then the second CTA is basically
> 'sign up to that'.  And you take it from there if any people at all do
> arrive there?

Of course. Though another possibility is the second CTA is "sign up to
the -quality and devel list" and manage any extra traffic we get as best
we can.

I think it would be good to say in the second CTA "sign up to something"
rather than -  "go and test and take it from there". We should be clear the
time involvement in signing up to those lists, if so.


>>>> If things go well, DA will not be the only experimental build on offer.
>>> +1
>>>
>>>> As for so-called veto, why does it have to be one call for your early
>>>> adopters or no call?  I think the concept of different channels (which
>>>> in our case would manifest as different Google Groups) could work.
>>> If you have five or six CTAs on the same page you get less aggregate
>>> response than having one.
>> I guess that CTA might mean "Call to Action".
> Yes.
>
>> Nowhere have I asked for six calls to action.
> Our 'community' page http://www.audacityteam.org/community/ is in a
> sense 5 different calls to action, which is one reason it isn't working.
>
> I felt you might have been suggesting a separate call for each
> 'ring/channel'?

I was just considering rings for specific build types as logical dividers
for different Groups (if we had them).

I would actually have "kiboshed" (as you put it) your early adopters
CTA by having one CTA.

2017 Early adopters and testers initiative.

What picture fits you?

* Do you want to test experimental builds, not as stable as releases
  but reasonably so, and be first to see new features proposed for
  Audacity releases? Do you want to be part of shaping those features?

  == > Sign yourself up now to the Early Adopters channel.

* You want more? You want to test the builds we make each night, so
   you see everything first that is in our master development tree, and
   also be a regular part of testing our bug fixes? You accept these are
   the bleeding edge and you'll need to back up any production work
   you're doing? We want you too!

   == > Sign yourself up now to the Advanced Testers channel.

Don't worry! You can sign up to both groups, so you don't miss a thing.

I guess James has fallen off his chair laughing by now, but I don't
think the above is that bad.


>>> I am willing to work on a CTA for early adopters
>> Are you then the only one who is allowed to make a call for action?
> Far from it.
>
>>
>>> as I believe that CTA will feed through into vastly more people who are
>>>   engaged with and helping Audacity than other calls and of course
>>> because I have already put considerable time and energy into making
>>> the possibility of that CTA being effective.
>> Are you referring to DA again there?
> Yes.
> DA is magnet content to attract early adopters.
>
>
>>
>>> I am also OK with having a page with a CTA for out and out testers. I am
>>> willing to put some work into that on icons wording and graphics,
>>> working on text to show it is professional level of skill, showing how
>>> things knit together to ensure quality for official releases.
>> All right, that sounds like a few grains of compromise we might
>> be able to build on. I hope we can do so.
>>
>>
>>> My main focus is though on the early adopter CTA, because the response
>>> to that is likely to repay work on it many more times over.  If we do
>>> get 16 nightly testers from the second CTA I'd be delighted.
>> I don't think I was asking that you James had to do a testing CTA
>> yourself, or that you James had yourself to run any separate "place
>> to hang out" there might be for "testers".I was asking you not to
>> outright oppose those ideas.
> I don't oppose the idea.
>
>> To me, a separate place or places identified with some specific build
>> type is clearly preferable to wooliness.
>>
>> Two CTA's would work for me, but I think it inadvisable to have the
>> "testers" hang out in the same place as the "early adopters".
> So two google groups.

Perhaps. See my new thoughts above. Unlike you, I think separating
into two CTA's might mean less uptake for the advanced testers.


> I think that as q2a takes off, it will become a team resource and people
> with many different interests in helping Audacity progress will
> contribute to it.  Early adopters and nightly-testers will mingle on it.

Hmm. Let's try it ourselves first.


>> Also I still don't see why this can't in principle be bundled as one
>> initiative. Still calling it "(testers)" as Steve/Peter suggested makes
>> it easier to bundle.
> You'll need to clarify.
> Launching both initiatives at the same time is worth doing.  Clearly the
> two initiatives aren't asking for the same thing from people who get
> involved.

I clarified above, but at the moment you are the doer on this.


>> The idea of separate Groups was that it is clear what the differences
>> between the groups are and it is also clear that a person could sign
>> up to all (both) of the groups if they wanted.
> Still possible.
>
>
>> Another benefit - the more casual "early adopters" won't need to
>> be bothered with text / download links about KTT/RC/nightlies.
>> If any of them do want to go further, they know where the other
>> Group is.
> OK.  Look forward to refinement of the KTT/RCs/Nightlies group by you.

The nightlies have a very different stability expectation to KTT and RC.

Can I assume there won't be any experimental builds after any KTT?



Gale


>>>> Fundamentally I don't think we can even have an initiative until we
>>>> sort out in our own mind the relationship/differences between KTT
>>>> and different types of "experimental build". Of course we also need
>>>> the resources to provide all the different types of build we envisage.
>>>> Are KTT's possible?
>>> Well I am sorted in my mind about these.
>>> Auteur Builds (DA, FishEye), KTT (roughly half way to release), RCs,
>>> Nightlies
>>>
>>> KTTs are possible, but pointless without people to kick the tyres.
>> So those are listed in increasing order of "boredom" and declining
>> likelihood of involvement, more or less.
> Yes.
>
>> Might it be better to go for Punch In (or preparation for Punch In)
>> above FishEye?
> Yes.
> Whether and what Paul offers as an experimental build is Paul's call.
>
>
>> I can't see the latter being the attraction that Punch
>> In would be, and I can see the benefit of getting extra feedback on the
>> interface of Punch In.
>>
>>>
>>>> In my idea, we get as many people as we can signed up to each
>>>> Google Group. I don't imagine the nightly builds group will have the
>>>> interest of the other groups. But we won't know if it would be a complete
>>>> flop unless we try it.
>>> -1
>>> I've got bandwidth to run or co-run a google group for early adopters,
>>> with a smattering of more dedicated folk in it, but not for a channel
>>> for each 'ring'.  If you regard separating the different folk as an
>>> essential, then forum or discourse or q2a are a better fit.
>>> I suppose if you want to run/moderate the KTT, the RC and the nightly
>>> channel each on a different google group yourself then I am '0'
>> The RC could not stand on its own as a separate group, and I don't want
>> to go above three "channels". I was hampered by not knowing what your
>> experimental builds meant.
>>
>> Clearly the most separate build type is the nightlies.
>>
>>
>> Gale
>>
>>
>>>> Is there really almost no-one on Chrome's Canary channel? I don't believe that for a minute.
>>> Chrome canary is special/different.  The Google canary program is very
>>> carefully worked out, with many employees volunteering/involved in the
>>> test.  Canary is also pretty reliable/good/usable in a way that our
>>> nightlies aren't.
>>>
>>>
>>>
>>>>
>>>>
>>>> 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: Proposal - Sprucing up 'getting involved'

Gale
Administrator
In reply to this post by Stevethefiddle
Facebook is all but unusable IMO for any type of serious work,
with or without Q2A. You can't even ENTER without posting a
premature message, posting images is luck or obscure logic,
and all constrained within a few column inches.

You can't see more than a few replies without multiple clicking
around, sometimes having to open a URL in a new window
to see all the recent posts.

Going by the figures we are not even promoting FB properly and
need a paid (or volunteer) expert in how to do so.

Of course we will announce the CTA(s) on Facebook and "juicy bits"
that we would also announce to the main place where these testers
hang out. And with safety warnings.

Are you then Steve also opposed to using a new Forum installation?



Gale


On 25 March 2017 at 16:37, Steve the Fiddle <[hidden email]> wrote:

> On 25 March 2017 at 12:36, James Crook <[hidden email]> wrote:
>> On 3/25/2017 9:35 AM, Steve the Fiddle wrote:
>>> Returning to the original proposals...
>>> (I shall use the term "testers" as a general term for people using and
>>> giving feedback, whether as "beta testers", "early adopters" or
>>> whatever).
>>>
>>> On 23 March 2017 at 13:09, James Crook <[hidden email]> wrote:
>>>> I'm looking at improving our 'Get Involved' pages.
>>>>
>>>> http://www.audacityteam.org/community/
>>> +1
>>>
>>>> I'd like to add icons for the different ways of getting involved.  We're
>>>> very text heavy currently.
>>> +1 for making the website less "text heavy".
>>>
>>>>
>>>> I'd like to add a new page for the early adopters initiative.
>>>> The question is where to direct early adopters to.
>>>>
>>>> * If we were further ahead with Q2A I would say that would be the place,
>>>> and the questions would be about enhancement requests and the new features.
>>>> * The most likely option at this stage is instead a google group, which
>>>> gives us an email list again that we can announce on.
>>>> * A third option is a board on the forum.
>>>> * A fourth is to direct people here on the quality list.  We might have
>>>> to change how we use this list quite a bit though.
>>> -1 for using an email list as the primary forum for testers. While
>>> email lists are a favourite for developers, this is not for
>>> developers, so let's use a format that is more popular with the
>>> general public.
>>>
>>> Perhaps we will need more than one communication channel for testers,
>>> but for the purpose of launching a "testers" initiative, we need to
>>> have one primary channel. That communication channel needs to be
>>> enticing / engaging for "testers", and needs to be *effective*.
>> There needs to be SOME channel which is essentially a push channel with
>> announcements, e.g. that Build-X is available.  The sizzlier stuff is
>> eminently suitable for FB.  Each such sizzly post would need the word
>> EXPERIMENTAL on it though, to avoid seducing random visitors who are
>> just interested in very stable releases.
>>
>> 'Discourse' could work as a channel for the nitty gritty two-way
>> conversation.  I think 'q2a' would work better.
>>
>> I'm very happy to do early-adopters on q2a (without a google group) and
>> using facebook instead for our announces.  I don't know what Gale would
>> be most happy with for dedicated-testers.  Certainly they'd be welcome
>> to share the q2a, as I don't see dedicated-testers getting in the way of
>> the early-adopters there or vise-versa.
>>
>> Steve, what do you specifically suggest?  Would FB + q2a sound plausible
>> to you as an approach (for the early-adopters)?
>
> Certainly "plausible".
> I think fb is a good idea for the "announce" part.
> I don't know how well q2a will work for other goals, but I'm not sure
> what your other goals are. If you think it  will work, then I see no
> harm in trying it. (Nothing ventured, nothing gained).
>
>>
>>
>>> What does *effective* mean? What outcomes are we looking for? In deciding on the primary communication channel for testers, this must be the most important question.
>> How would you word the goals Steve?
>
> "Feedback" is probably the main goal isn't it?
>
> Steve
>
>>
>>> Steve
>>>
>
> ------------------------------------------------------------------------------
> 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: Proposal - Sprucing up 'getting involved'

James Crook
In reply to this post by Gale

On 3/26/2017 6:29 AM, Gale Andrews wrote:

> On 25 March 2017 at 09:28, James Crook <[hidden email]> wrote:
>> On 3/25/2017 5:13 AM, Gale Andrews wrote:
>>> On 24 March 2017 at 22:46, James Crook <[hidden email]> wrote:
>>>> On 3/24/2017 9:25 PM, Gale Andrews wrote:
>>>>> On 24 March 2017 at 15:51, James Crook <[hidden email]> wrote:
>>>>>> On 3/24/2017 10:23 AM, Peter Sampson wrote:
>>>>>>> Steve the Fiddle wrote:
>>>>>>>> James Crook wrote:
>>>>>>>>> Gale Andrews wrote:
>>>>>>>>>> I don't know why we concentrate on early adopters. As far as I
>>>>>>>>>> know we want testers, of whom early adopters are a subset.
>>>>>>>>> Consider these calls to action:
>>>>>>>>>
>>>>>>>>> 1. (early adopter) "Get early access to work-in-progress on Audacity
>>>>>>>>> that has exciting new features.  Not all of these features will become
>>>>>>>>> mainstream, but your feedback on the features and bugs will help us
>>>>>>>>> define future versions of Audacity"
>>>>>>>>> 2. (tester) "Come and try out a buggy version of Audacity with your
>>>>>>>>> projects, and really help us find the bugs so that other people can
>>>>>>>>> benefit from a more stable Audacity"
>>>>>>>>>
>>>>>>>>> 2's are more valuable to us, but 1 is a massively more attractive
>>>>>>>>> proposition to most people.
>>>>>>>> Which is fine until we make a bad mistake and early adopters lose
>>>>>>>> important work.
>>>>>>>>
>>>>>>>> My preference would be:
>>>>>>>>
>>>>>>>> 3. (tester) Get early access to exciting new features and help us
>>>>>>>> define future versions of Audacity...
>>>>>>>>
>>>>>>> I think my preference would be (effectively 1 plus 2):
>>>>>>>
>>>>>>> 4. (tester) Get early access to exciting new features and help us
>>>>>>> define future versions of Audacity. And help us find the bugs so that
>>>>>>> other people can benefit from a more stable Audacity".
>>>>>>>
>>>>>>> Peter
>>>>>> Are we vehemently agreeing again?  Both 3 and 4 are appeals to early
>>>>>> adopters.
>>>>> To me early adopters are the icing on the cake.
>>>> -1
>>>> Early adopters are the key.  With them we have a pool of people who will
>>>> try some build that is not an official release.
>>> And while better than not having that "pool", we agree it is not what
>>> we most want.
>> Agree, but still maintain a more engaged 'pool' is a more likely
>> strategy to get us what we want.
>>
>>
>>>>> People to do the "hard work" are essential. I could become unavailable at any time
>>>>> and Peter bless him is older than I am. Then what?
>>>> +1
>>>> I am getting older too.
>>>>
>>>>
>>>>> If we make it sound too much like "fun" we underplay the risk of
>>>>> using pre-releases
>>>> +1
>>>> We need text explaining why official releases differ to these builds.
>>>>
>>>>> and minimise the chance that we will get many or any nightly builds testers out of it.
>>>> -1.
>>>> Getting nightly-build testers depends on a connection first.  That
>>>> connection has to be initiated and then grow.
>>> Then don't block us maklng that direct connection.
>> I don't block you in that.
>>> And support me in posting the nightly builds officially, instead of on strange private sites.
>> I do support that.
> Good.
>
>
>>>>>> To be a bit clearer, we need to lead with the idea of new and exciting
>>>>>> things to try out.
>>>>> Yes but there are caveats too, and the bleeding edge nightly build
>>>>> testers do have a more demanding (some might say, boring) task.
>>>> +1
>>>> Yes they do.
>>>>> It needs a different level of commitment, and more willingness to
>>>>> take risk.
>>>> +1
>>>>
>>>>> I am sure you know what I talking about with channels (the Microsoft
>>>>> Insider program calls them "rings"). For example
>>>>> https://www.chromium.org/getting-involved/dev-channel .
>>>>>
>>>>> "Nightly Builds", "Milestone builds" aka KTT (that we might call "beta" if
>>>>> not for user misunderstanding of that term and 1.3 bugginess) and
>>>>> "Releases" fall naturally into that scheme.
>>>>>
>>>>> So you could sign up to a Google Group about Nightly Builds and a
>>>>> Google Group about Milestone builds. Probably RC's would be in this
>>>>> Milestone Group. We want more exciting names than these.
>>>>>
>>>>> Branches about new work like Fish Eye or Punch In fall a little outside
>>>>> this scheme as they would be intermittent builds between (and mostly
>>>>> before) Milestone builds. They are not mutually exclusive of Nightly
>>>>> Builds or Milestone builds. They do carry more risk than Milestones.
>>>>> They could (for those testing the new feature) carry more risk than
>>>>> nightlies.
>>>>>
>>>>> DA would somewhat "stand outside" as an auteur build which is
>>>>> a supply of someone's personal ideas that go beyond a specific
>>>>> new feature, but aims for more stability than a feature-specific
>>>>> build. But perhaps it fits most closely into this "feature" Group.
>>>>> DA's code (in its entirety) is not likely to be in the Milestone builds.
>>>>>
>>>>> I would guess these feature builds would be their own Google Group
>>>>> too. Not everyone who is signed up will be interested in all of these
>>>>> builds. Many may prefer to wait for the Milestone build to see if the
>>>>> feature gets in, in which case it will probably be quite refined and stable
>>>>> by then.
>>>> -1
>>>> That sounds mad and unworkable to me.
>>> I thought hard before writing it. I have long thought your plan
>>> inadequate.
>>>
>>>
>>>> We are surely not going to have a google group for each 'ring'?
>>> Will mixing "rings" into one Google Group work?
>> Could do.  Early-adopter-vladislav reports a unicode problem that isn't
>> actually from a new feature, and we believe is fixed in a nightly.  He
>> is an enthusiast, and tries out the nightly.  Confirms, YES it works.
> To some extent this depends how many early adopters are "enthusiasts"
> and whether they bore the less enthusiastic.
The lists are moderated.  I would moderate boring people. Essentially
I'd hand the useful boring ones over to you to sort out.  If they were
simply boring and not useful to Audacity ("I'm a troll fol di rol") I
would just moderate them.

> If he became very enthusiastic and installed the nightlies regularly I
> don't see him belonging so clearly in an early adopters group that
> was the only group.
Vlad is unlikely to become so enthusiastic so quickly.  Karyme might, if
we are working on RTL language support, in HEAD, with many steps forward
in the nightlies.  That would likely be in the context of a specific
developer making changes that address her care abouts.  There would
likely be a conversation between her and that developer.

If I am wrong about numbers, and we are very successful in getting
dedicated nightly testers, then an email list for them is no problem.  
If the numbers are tiny, then one-to-one interaction can work.  As I've
said, and seem to need to repeat, you can set up and moderate a list for
nightly testers anyway, just in case.

>
>>> I think not.
>> I think supporting the most dedicated testers, more dedicated than vlad,
>> will depend on us having q2a too.  Then we can have questions like 'How
>> can I reproduce 42 (Timer Record doesn't stop)', 'How can I reproduce
>> 1460 (RT effects disabled)' and vote up the best answers.
> I "vote" -1 to Q2A before we try it amongst ourselves.  And I am still not
> convinced we want the above sort of material asked about and reported
> back on in an early adopters group.
>
> If you have direct experience from DA that the different skill levels play
> well together, and given I do want to have some call for higher level testers,
> then I suppose we could try it with one group.
I have not tried q2a with them and don't have such evidence from DA.

I do see that Stackoverflow is able to cope with a large number of
people and a truly vast range of skill levels and special interests -
without people treading on each others toes too much.


> I think it is probably a mistake, based on expectation but not evidence.
>
> Do the others have insight?
>
>
>> Again this allows mixing the rings, as people will filter the q2a
>> differently (using tags).
>>
>>> The early adopters won't want to be reading a lot of heavy detail about
>>> nightly builds (should we be so lucky) and other things above their
>>> heads or interest level.
>> If we should be so lucky, engaging one to one off list if it is just one
>> or two could work.  If it's more than one or two you/we could create an
>> email-list then, or work to make this quality@ list suitable for them too.
> If there was from the start a separate list for dedicated testers that
> was part of the initiative, might that not create some impetus of its
> own?
Again, you are welcome to have and moderate such a list.


>
>>>> It might be possible to have different boards on a forum, I suppose.
>>>> I think it would still be cumbersome.
>>> Does that comment mean then that Google Groups are hard to manage ?
>>> Please tell me what the problems are.
>> No more so than an ordinary moderated email list.
>>
>>> This is exactly why I wanted to sort out what "experimental builds" mean.
>>> Perhaps we can manage with two Groups or Forum boards, nightlies
>>> and other.
>> Yes (modified).
>> Group 1: Early adopters with mention of KTT (if we do KTT)
>> Group 2: Dedicated testers, nightlies, culminating in RCs.
> Alright. I would hope your early adopters would be more engaged than
> the average user and that some would test the RC's. It's a balance.
When/if early adopters do test the RCs it's a sign of them taking steps
to being more dedicated testers.  We could make it one of the KPI?

>
>>> I suspect "experimental builds" just means James's DA project, to begin
>>> with, right?
>> No actually, because the key DA changes are already (now) filtering into
>> audacity head itself.  The experimental builds during 2.2.0 are most
>> likely to be one from Paul, one with MIDI_OUT and possibly a branch-line
>> build (by me) giving Robert's 'selection' menu a try out
>> (EXPERIMENTAL_SELECTION_MENU).
>> Early adopters will have plenty of cool new stuff to try out with those
>> experimental builds, plus the menu rearrangement,  plus the theme
>> changes from head.
> I hope we can avoid the use of the term "auteur" builds until Team's
> views on these and DA are clarified.
What term would you prefer?

>>>>>> The strategy I am prepared to work on involves exciting new experimental
>>>>>> code.  In the process it exercises other new code added since 2.1.3.  We
>>>>>> have a pool of people with different hardware giving bug and feature
>>>>>> feedback.  Feature feedback on work in progress is going to auteurs, and
>>>>>> there may be dialogue between the auteurs and this pool of engaged early
>>>>>> adopters.
>>>>>>
>>>>>> I think it is a misconception that there are, say, 16 people out there
>>>>>> who would volunteer to test the way we most need it, if we just make a
>>>>>> call for that directly.
>>>>> I am not convinced it is a misconception. Unless we say we also want
>>>>> these people we most want, and let people know that nightly builds
>>>>> actually exist, we have a self-fulfilling prophecy that we won't get these
>>>>> people.
>>>> Sounds like an impasse then.
>>> Again, why must we have only an early adopters' call, or nothing?
>> As I have said, we can have one page for an early adopter CTA, one for a
>> tester CTA.
>>
>> I don't want the early-adopter CTA kiboshed by a message 'come and work
>> really hard doing unrewarding work on buggy versions of Audacity so that
>> other people can benefit'.  Instead, on a different page, we need a CTA
>> for dedicated testers.
> I really hope you are not going to be as dismissive as that about
> dedicated testers. In some cases these dedicated testers do get
> to see the latest features before anyone.
My thinking is that good dedicated testers are wary of the cool new
stuff.  New stuff introduces risks and regressions.  The dedicated
testers are not opposed to cool new stuff, they know its value, but they
are wary of it.

I am not being dismissive.  I am trying to spell out for you how having
both messages in the same call would be disastrous.


> And we are not going to boot them out of any group there is for them
> if they are only occasional bug reporters/testers of the nightlies.
>
>
>>>> The kind of billing for testing that Steve and Peter are suggesting is
>>>> OK, as the OFFER of exciting new experimental builds is still clear.
>>> Good. I want "exciting, get to see it first" to be part of the advertising
>>> to those testing experimental builds (with the caveats we agree about).
>> Fine.
>>
>>>>>> Rather there are (at least) 30,000 people out
>>>>>> there who will give new experimental code a try out.  Many of those
>>>>>> would be willing to give a little feedback to us 'Subsonic Microphones
>>>>>> don't work with Dolby enabled, for me'.  A few could get more involved
>>>>>> than that.  16 may actually over time become testers.  That happens IF
>>>>>> being part of the energy of the initiative is fun.
>>>>>>
>>>>>> I don't want to waste my time on a strategy that is based on the
>>>>>> misconception of pre exisitng testers ready to volunteer, if only they
>>>>>> knew it was needed.  The strategy I am going for is to get people using
>>>>>> and communicating with us about new experimental versions.  Grow a small
>>>>>> number of actual testers from that larger pool.
>>>>>>
>>>>>> So having explained the strategy I envisage more clearly,
>>>>> Actually I already (and long ago) understand how you envisage it.
>>>>>
>>>>>
>>>>>> Peter, Steve  do you agree it is a good strategy?  And Gale do you agree it is an
>>>>>> acceptable strategy, or would you veto it, if you had a veto? As you are
>>>>>> QM I think you do have a veto, and it is why I didn't put the idea into
>>>>>> action last August using DA to attract people.
>>>>> Team's feelings about DA is a separate issue as you know that we
>>>>> must urgently resolve.
>>>> This conversation is about any experimental builds, and any new features
>>>> being checked into HEAD.
>>> HEAD is nightly builds as well. Until you specify clearly, I don't know
>>> what the conversation is about (you have now clarified below).
>> But I think we vehemently agree that early-adopters will be offered
>> selected 'good' builds from HEAD, rather than every single nightly.
>>
>>>> The relevance of DA is that we had an opportunity to use DA this way last
>>>> August and the offer was turned down by you.
>>> Yes because there were internal differences about DA being a separate
>>> project from Audacity.
>>>
>>>
>>>> You seemed at the time to be saying we should demand people test
>>>> nightlies, because that is what we need.  You seemed to overlook that
>>>> experimental builds contain recent code, typically up to date with HEAD
>>>> and with other additions too.
>>> Experimental "release" or pre-release" builds forked off HEAD will indeed
>>> contain modified HEAD at the time they are published, with the unmodified
>>> parts gradually drifting out of date. I said this was definitely
>>> better than not having such builds/testers.
>> When there is a refresh of an experimental build, it can pick up what is
>> in HEAD again.  Have a look at the git history for DA. You'll see merges
>> from HEAD into it.
>>
>>> Even with this there is work in managing the feedback, but if you are
>>> volunteering to do most of that management, why not?
>> I am volunteering to manage the early-adopter list.  If Paul chooses to
>> do an auteur build during 2.2.0 I'll expect him to field feedback on his
>> build.
> This feedback managed by Paul will be on the early adopters Group
> won't it?
Yes.

>>>> You seemed to be saying encouraging people to try out experimental
>>>> builds was a pointless strategy.
>>> I don't believe I ever said "pointless". It is I believe an insufficient
>>> approach but better than nothing.
>>>
>>>
>>>> Do you think encouraging people to try out experimental builds a
>>>> pointless strategy or do you think it acceptable?  You did not answer if
>>>> you think the early adopter strategy acceptable.
>>> I have given my opinion on it in the previous paragraph and
>>> elsewhere. I don't understand what the possible benefits are of
>>> *not* having a separate initiative, advertised at the same time,
>>> at least for nightly builds.
>> We're (now) agreed we're having two CTAs, one for early adopters, one
>> for nightly testers.  (I think).
> Yes, broad agreement on that.
>
>
>> If you have a nightlies google-group, then the second CTA is basically
>> 'sign up to that'.  And you take it from there if any people at all do
>> arrive there?
> Of course. Though another possibility is the second CTA is "sign up to
> the -quality and devel list" and manage any extra traffic we get as best
> we can.
The extra traffic to -quality isn't an issue.

More of an issue is that the existing conversations, and sometimes
disputes, on -quality might be a turn off.  We might need to work at
changing the energy to be more welcoming to new contribs.

> I think it would be good to say in the second CTA "sign up to something"
> rather than -  "go and test and take it from there". We should be clear the
> time involvement in signing up to those lists, if so.
That is pretty much what I was saying.

My 'take it from there' is saying you (Gale) take it from there, in
managing that list.

>>>>> If things go well, DA will not be the only experimental build on offer.
>>>> +1
>>>>
>>>>> As for so-called veto, why does it have to be one call for your early
>>>>> adopters or no call?  I think the concept of different channels (which
>>>>> in our case would manifest as different Google Groups) could work.
>>>> If you have five or six CTAs on the same page you get less aggregate
>>>> response than having one.
>>> I guess that CTA might mean "Call to Action".
>> Yes.
>>
>>> Nowhere have I asked for six calls to action.
>> Our 'community' page http://www.audacityteam.org/community/ is in a
>> sense 5 different calls to action, which is one reason it isn't working.
>>
>> I felt you might have been suggesting a separate call for each
>> 'ring/channel'?
> I was just considering rings for specific build types as logical dividers
> for different Groups (if we had them).
>
> I would actually have "kiboshed" (as you put it) your early adopters
> CTA by having one CTA.
Yes you would have.


> 2017 Early adopters and testers initiative.
>
> What picture fits you?
>
> * Do you want to test experimental builds, not as stable as releases
>    but reasonably so, and be first to see new features proposed for
>    Audacity releases? Do you want to be part of shaping those features?
>
>    == > Sign yourself up now to the Early Adopters channel.
>
> * You want more? You want to test the builds we make each night, so
>     you see everything first that is in our master development tree, and
>     also be a regular part of testing our bug fixes? You accept these are
>     the bleeding edge and you'll need to back up any production work
>     you're doing? We want you too!
>
>     == > Sign yourself up now to the Advanced Testers channel.
>
> Don't worry! You can sign up to both groups, so you don't miss a thing.
>
> I guess James has fallen off his chair laughing by now, but I don't
> think the above is that bad.
No I am not laughing.  Unfortunately.

It's tragic.

It's not just bad.  It's disastrously bad.  And I'm not laughing,
because by not solving that problem, it is preventing Audacity being
fun, both in test and in development.

I am not talking just happy clappy fun, which is what early-adopters
initiative might seem like to you.  There is fun in test too.

A CTA for test is more like:

"Over 17 years we have developed an approach to testing that is
organised, professional, and that has helped us scale to millions of
users.  Audacity wouldn't be where it is now without it.  We need to
test to find hidden problems, to work with developers, to find and nail
the problems that matter to our users, and to give Audacity users an
outstanding experience.  Want to help?  It's not an easy journey, but
you can get started on it now:
==>  Sign up on the Advanced Testers portal."



>
>>>> I am willing to work on a CTA for early adopters
>>> Are you then the only one who is allowed to make a call for action?
>> Far from it.
>>
>>>> as I believe that CTA will feed through into vastly more people who are
>>>>    engaged with and helping Audacity than other calls and of course
>>>> because I have already put considerable time and energy into making
>>>> the possibility of that CTA being effective.
>>> Are you referring to DA again there?
>> Yes.
>> DA is magnet content to attract early adopters.
>>
>>
>>>> I am also OK with having a page with a CTA for out and out testers. I am
>>>> willing to put some work into that on icons wording and graphics,
>>>> working on text to show it is professional level of skill, showing how
>>>> things knit together to ensure quality for official releases.
>>> All right, that sounds like a few grains of compromise we might
>>> be able to build on. I hope we can do so.
>>>
>>>
>>>> My main focus is though on the early adopter CTA, because the response
>>>> to that is likely to repay work on it many more times over.  If we do
>>>> get 16 nightly testers from the second CTA I'd be delighted.
>>> I don't think I was asking that you James had to do a testing CTA
>>> yourself, or that you James had yourself to run any separate "place
>>> to hang out" there might be for "testers".I was asking you not to
>>> outright oppose those ideas.
>> I don't oppose the idea.
>>
>>> To me, a separate place or places identified with some specific build
>>> type is clearly preferable to wooliness.
>>>
>>> Two CTA's would work for me, but I think it inadvisable to have the
>>> "testers" hang out in the same place as the "early adopters".
>> So two google groups.
> Perhaps. See my new thoughts above. Unlike you, I think separating
> into two CTA's might mean less uptake for the advanced testers.
Combining (i.e. mixing the message) will dramatically reduce the sign up
overall, I think, possibly to the point where it is pointless doing the
initiative.


>
>> I think that as q2a takes off, it will become a team resource and people
>> with many different interests in helping Audacity progress will
>> contribute to it.  Early adopters and nightly-testers will mingle on it.
> Hmm. Let's try it ourselves first.
+1.
Let us try it.

>
>>> Also I still don't see why this can't in principle be bundled as one
>>> initiative. Still calling it "(testers)" as Steve/Peter suggested makes
>>> it easier to bundle.
>> You'll need to clarify.
>> Launching both initiatives at the same time is worth doing.  Clearly the
>> two initiatives aren't asking for the same thing from people who get
>> involved.
> I clarified above, but at the moment you are the doer on this.
Indeed I am.

However you are QM Gale.

Clearly what I am working on has a strong connection with how we ensure
quality.  It also does involve more publicity.  That publicity
indirectly reflects well on my DA initiative.  You are entitled to say
that QA wants none of that.  As QM you are entitled to block an approach
that is primarily about more testing of cool new code.

>
>>> The idea of separate Groups was that it is clear what the differences
>>> between the groups are and it is also clear that a person could sign
>>> up to all (both) of the groups if they wanted.
>> Still possible.
>>
>>
>>> Another benefit - the more casual "early adopters" won't need to
>>> be bothered with text / download links about KTT/RC/nightlies.
>>> If any of them do want to go further, they know where the other
>>> Group is.
>> OK.  Look forward to refinement of the KTT/RCs/Nightlies group by you.
> The nightlies have a very different stability expectation to KTT and RC.
>
> Can I assume there won't be any experimental builds after any KTT?
You can assume something that is related.  You can assume that most RMs
will not accept notable new features into Audacity itself, for that
release, after the KTT.

If I have a brilliant idea for using Audacity to control my disco
lighting, I might well offer an experimental build just to try it out
after the KTT.  I'd be astonished if the RM pulled that new code into
mainstream for that release.

--James.



>
>
>
> Gale
>
>
>>>>> Fundamentally I don't think we can even have an initiative until we
>>>>> sort out in our own mind the relationship/differences between KTT
>>>>> and different types of "experimental build". Of course we also need
>>>>> the resources to provide all the different types of build we envisage.
>>>>> Are KTT's possible?
>>>> Well I am sorted in my mind about these.
>>>> Auteur Builds (DA, FishEye), KTT (roughly half way to release), RCs,
>>>> Nightlies
>>>>
>>>> KTTs are possible, but pointless without people to kick the tyres.
>>> So those are listed in increasing order of "boredom" and declining
>>> likelihood of involvement, more or less.
>> Yes.
>>
>>> Might it be better to go for Punch In (or preparation for Punch In)
>>> above FishEye?
>> Yes.
>> Whether and what Paul offers as an experimental build is Paul's call.
>>
>>
>>> I can't see the latter being the attraction that Punch
>>> In would be, and I can see the benefit of getting extra feedback on the
>>> interface of Punch In.
>>>
>>>>> In my idea, we get as many people as we can signed up to each
>>>>> Google Group. I don't imagine the nightly builds group will have the
>>>>> interest of the other groups. But we won't know if it would be a complete
>>>>> flop unless we try it.
>>>> -1
>>>> I've got bandwidth to run or co-run a google group for early adopters,
>>>> with a smattering of more dedicated folk in it, but not for a channel
>>>> for each 'ring'.  If you regard separating the different folk as an
>>>> essential, then forum or discourse or q2a are a better fit.
>>>> I suppose if you want to run/moderate the KTT, the RC and the nightly
>>>> channel each on a different google group yourself then I am '0'
>>> The RC could not stand on its own as a separate group, and I don't want
>>> to go above three "channels". I was hampered by not knowing what your
>>> experimental builds meant.
>>>
>>> Clearly the most separate build type is the nightlies.
>>>
>>>
>>> Gale
>>>
>>>>> Is there really almost no-one on Chrome's Canary channel? I don't believe that for a minute.
>>>> Chrome canary is special/different.  The Google canary program is very
>>>> carefully worked out, with many employees volunteering/involved in the
>>>> test.  Canary is also pretty reliable/good/usable in a way that our
>>>> nightlies aren't.
>>>>
>>>>> 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: Proposal - Sprucing up 'getting involved'

Stevethefiddle
In reply to this post by Gale
On 26 March 2017 at 06:44, Gale Andrews <[hidden email]> wrote:
> Facebook is all but unusable IMO for any type of serious work,
> with or without Q2A. You can't even ENTER without posting a
> premature message, posting images is luck or obscure logic,
> and all constrained within a few column inches.
>
> You can't see more than a few replies without multiple clicking
> around, sometimes having to open a URL in a new window
> to see all the recent posts.

The suggestion was to use fb (facebook) as a "push channel". If you
are interested in following announcements on this channel, visit the
page and click the "follow" button. When you receive email
notifications about posts, click the link in the email to read the
full post on fb. There is no need to do anything more than that.

>
> Going by the figures we are not even promoting FB properly and
> need a paid (or volunteer) expert in how to do so.

I'm definitely in favour of engaging a broader range of experts into
our team, however, considering that I only put the social media icons
onto the forum / website at the beginning of this month, but we've
already got over a thousand followers on fb.

The number of followers on twitter is still very small (32), but worth
noting that when we tweet it may be re-tweeted, so for example, 3
(10%) of our followers re-tweeted the release announcement, and those
tweeters have over fifteen hundred followers between them. We don't
know how many of their followers re-tweeted, but the actual reach is
very much greater than the number of followers suggests.

As I made clear at the outset that I favour a "slow and steady"
approach to our adoption of social media.

>
> Of course we will announce the CTA(s) on Facebook and "juicy bits"
> that we would also announce to the main place where these testers
> hang out. And with safety warnings.
>
> Are you then Steve also opposed to using a new Forum installation?

I think that a "forum" ("bulletin board") is one option. Q2A software
is another option. I don't think we should start with both at the same
time as imo that spreads our resources too thin.

If it were my choice - if I was running the "testers" initiative, then
I would probably go for a special new "read only" section on the
forum. People signing up as testers / early adopters would be
'rewarded' with read/write access. However, I'm not going to be
running this initiative, so I'm happy to leave the decision about the
type of 'forum' up to the major 'doers'. If James wants to try Q2A
software for this purpose, then I think we should give it a shot and
support it best we can.

However we do this, I'd not expect instant results, so we need to give
it a fair shot. If it doesn't work, then we can try something else.
Perhaps a 12 month trial and then review the initiative?

Steve

>
> Gale
>
>
> On 25 March 2017 at 16:37, Steve the Fiddle <[hidden email]> wrote:
>> On 25 March 2017 at 12:36, James Crook <[hidden email]> wrote:
>>> On 3/25/2017 9:35 AM, Steve the Fiddle wrote:
>>>> Returning to the original proposals...
>>>> (I shall use the term "testers" as a general term for people using and
>>>> giving feedback, whether as "beta testers", "early adopters" or
>>>> whatever).
>>>>
>>>> On 23 March 2017 at 13:09, James Crook <[hidden email]> wrote:
>>>>> I'm looking at improving our 'Get Involved' pages.
>>>>>
>>>>> http://www.audacityteam.org/community/
>>>> +1
>>>>
>>>>> I'd like to add icons for the different ways of getting involved.  We're
>>>>> very text heavy currently.
>>>> +1 for making the website less "text heavy".
>>>>
>>>>>
>>>>> I'd like to add a new page for the early adopters initiative.
>>>>> The question is where to direct early adopters to.
>>>>>
>>>>> * If we were further ahead with Q2A I would say that would be the place,
>>>>> and the questions would be about enhancement requests and the new features.
>>>>> * The most likely option at this stage is instead a google group, which
>>>>> gives us an email list again that we can announce on.
>>>>> * A third option is a board on the forum.
>>>>> * A fourth is to direct people here on the quality list.  We might have
>>>>> to change how we use this list quite a bit though.
>>>> -1 for using an email list as the primary forum for testers. While
>>>> email lists are a favourite for developers, this is not for
>>>> developers, so let's use a format that is more popular with the
>>>> general public.
>>>>
>>>> Perhaps we will need more than one communication channel for testers,
>>>> but for the purpose of launching a "testers" initiative, we need to
>>>> have one primary channel. That communication channel needs to be
>>>> enticing / engaging for "testers", and needs to be *effective*.
>>> There needs to be SOME channel which is essentially a push channel with
>>> announcements, e.g. that Build-X is available.  The sizzlier stuff is
>>> eminently suitable for FB.  Each such sizzly post would need the word
>>> EXPERIMENTAL on it though, to avoid seducing random visitors who are
>>> just interested in very stable releases.
>>>
>>> 'Discourse' could work as a channel for the nitty gritty two-way
>>> conversation.  I think 'q2a' would work better.
>>>
>>> I'm very happy to do early-adopters on q2a (without a google group) and
>>> using facebook instead for our announces.  I don't know what Gale would
>>> be most happy with for dedicated-testers.  Certainly they'd be welcome
>>> to share the q2a, as I don't see dedicated-testers getting in the way of
>>> the early-adopters there or vise-versa.
>>>
>>> Steve, what do you specifically suggest?  Would FB + q2a sound plausible
>>> to you as an approach (for the early-adopters)?
>>
>> Certainly "plausible".
>> I think fb is a good idea for the "announce" part.
>> I don't know how well q2a will work for other goals, but I'm not sure
>> what your other goals are. If you think it  will work, then I see no
>> harm in trying it. (Nothing ventured, nothing gained).
>>
>>>
>>>
>>>> What does *effective* mean? What outcomes are we looking for? In deciding on the primary communication channel for testers, this must be the most important question.
>>> How would you word the goals Steve?
>>
>> "Feedback" is probably the main goal isn't it?
>>
>> Steve
>>
>>>
>>>> Steve
>>>>
>>

------------------------------------------------------------------------------
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
12
Loading...