beta@ feedback mailing list?

[Daniel Shahaf <d....@daniel.shahaf.name>]

Johan, Stefan and I were talking on IRC about getting more people (devs
and users) to run trunk / prereleases, in order to find more bugs before
.0's release.

One of the ideas that came up was to establish a dedicated mailing list
for beta / pre-release feedback.  The thinking is that having a channel
for advanced users to discuss 1.10-dev issues in — without noise from
support requests or design discussions — might encourage more such
discussion to happen.

Thoughts?

Re: beta@ feedback mailing list?

[Jacek Materna <ja...@assembla.com>]

Great to hear. I agree - it's a fairly wide topic. Nothing to jump on quickly.

As an aside, I wanted to augment my original response which had an
omission of a reference.

> Lets consider the five main work flows:
> - reviewing a patch submission;
> - reviewing a (typically recent) commit;
> - reviewing a back-port nomination (from trunk to branches/1.9.x);
> - reviewing a patch to a vulnerability (this is done on private@).
> - beta/feedback release

The top four points came from a private discussion I had with Daniel
Shahaf, who correctly suggested a strategy to me on attacking this
topic around work flow preservation. Thanks Daniel.

On Mon, May 15, 2017 at 2:37 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Thu, May 11, 2017 at 4:03 PM, Jacek Materna <ja...@assembla.com> wrote:
>> On Thu, May 11, 2017 at 10:14 AM, Stefan Sperling <st...@elego.de> wrote:
>>> On Thu, May 11, 2017 at 01:04:01AM +0200, Johan Corveleyn wrote:
>>>> How do other ASF projects do this actually? Forums, presence in other
>>>> online places, more modern website look and feel, ...?
>>>
>>> They use github :)
>>
>>
>> On Thu, May 11, 2017 at 1:04 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>>> On Tue, May 9, 2017 at 3:32 PM, Jacek Materna <ja...@assembla.com> wrote:
>>>> Just observing from afar, in my opinion the root of what you are
>>>> trying to achieve here ties more to a lack of 'modern' collaboration.
>>>> If we want to engage the community/users more (expand the
>>>> IB/participation sphere - new - users) I would also explore
>>>> alternative mediums (versus email). One of the reasons Github has been
>>>> so successful in making git an overwhelming force has little to do
>>>> with git itself. They made the process easy, rewarding and exciting to
>>>> contribute as a user.
>>>>
>>>> An approachable UX leads to more engagement - every time. I think it
>>>> would be great if we had an army of excited users wanting to test new
>>>> features. The product would benefit. Users in SaaS for example always
>>>> enjoy being [volunteering] part of a "beta" program - there is
>>>> something satisfying for users in it. On the flip-side "beta" program
>>>> for on-premise "enterprise" products are rarely so.
>>>>
>>>> Adding ontop the beta@ ... If we can make the "beta" collaborative,
>>>> more engaging for users I think its a real step forward towards an
>>>> army.
>>>
>>> I think you've got a point here, Jacek. I can see that our general
>>> UX-impression as a project / community comes across as dated. It would
>>> be great if we could improve that UX, and make it more modern, if that
>>> helps reaching a broader group of users to help us beta-testing etc
>>> ... and increase enthousiasm for our upcoming release.
>>>
>>> Do you (or anyone) have any concrete suggestions (within reach of our
>>> very limited resources, especially regarding volunteer time to spend
>>> on it)? People that want to help with this?
>>>
>>> How do other ASF projects do this actually? Forums, presence in other
>>> online places, more modern website look and feel, ...?
>>>
>>> --
>>> Johan
>>
>> Thinking out loud here ...
>>
>> Idea here is to change incrementally, so we can: change tools, cannot
>> impact work flow, limit effort and amplify our capabilities as a team.
>>
>> Lets consider the five main work flows:
>> - reviewing a patch submission;
>> - reviewing a (typically recent) commit;
>> - reviewing a back-port nomination (from trunk to branches/1.9.x);
>> - reviewing a patch to a vulnerability (this is done on private@).
>> - beta/feedback release
>>
>> Focusing on #5 for this thread and knowing that apache projects cannot
>> have mandatory infrastructure dependencies on third parties, in order
>> to ensure the projects' long-term independence; projects may use
>> third-party-hosted tools, but they may not rely on such tools - the
>> projects always have to have a Plan B for in case the third party
>> service goes down.
>>
>> If we wanted to try the "github" model - Assembla is more than happy
>> to support the community with native SVN support for "collab".
>>
>> For the case of beta@ we've done this successfully before where we
>> create a public area for users to discuss, comment on features, code,
>> ideas for an upcoming release. It would be extremely simple to put
>> 1.10 into a repo with blame/compare/pull request/protected directories
>> capabilities along side ticket tracking for feedback.
>>
>> If the test is successful and we improve quality/feedback, it's a great win.
>>
>> I can also help get resources to move other channels such as the
>> forums, public discussion around 1.10 - once we close on a date.
>> Getting good engagement is not as easy as a forum - marketing is a
>> very important axis to get results, especially if we want to reach
>> audiences typically not involved, such as for example game artists who
>> use SVN every day - plenty of persona's out there that are using SVN
>> for its power, are non-technical but would love the opportunity to
>> help shape the "latest" SVN release with feedback.
>>
>> I think a modern subversion website is a great idea. I could look at
>> getting resources to help with that as well. Even a simple
>> re-surfacing may be a great step.
>>
>> If nobody is allergic to it I could setup a hosted 1.10-beta and see
>> what everyone has to say with a concrete dartboard to throw darts at -
>> worst case we burn it down and/or get the idea train going.
>
> Hi Jacek,
>
> Thanks a lot for these suggestions. They are all constructive ideas,
> but I think we'll have to chew a bit on them.
>
> I certainly want us to make progress in these areas, but it might take
> a while to discuss these things.
> Just wanted to drop a quick note that this hasn't fallen on deaf ears ...
> --
> Johan



-- 

Jacek Materna
CTO

Assembla
+1 210 410 7661
+48 578 296 708

Re: beta@ feedback mailing list?

[Johan Corveleyn <jc...@gmail.com>]

On Thu, May 11, 2017 at 4:03 PM, Jacek Materna <ja...@assembla.com> wrote:
> On Thu, May 11, 2017 at 10:14 AM, Stefan Sperling <st...@elego.de> wrote:
>> On Thu, May 11, 2017 at 01:04:01AM +0200, Johan Corveleyn wrote:
>>> How do other ASF projects do this actually? Forums, presence in other
>>> online places, more modern website look and feel, ...?
>>
>> They use github :)
>
>
> On Thu, May 11, 2017 at 1:04 AM, Johan Corveleyn <jc...@gmail.com> wrote:
>> On Tue, May 9, 2017 at 3:32 PM, Jacek Materna <ja...@assembla.com> wrote:
>>> Just observing from afar, in my opinion the root of what you are
>>> trying to achieve here ties more to a lack of 'modern' collaboration.
>>> If we want to engage the community/users more (expand the
>>> IB/participation sphere - new - users) I would also explore
>>> alternative mediums (versus email). One of the reasons Github has been
>>> so successful in making git an overwhelming force has little to do
>>> with git itself. They made the process easy, rewarding and exciting to
>>> contribute as a user.
>>>
>>> An approachable UX leads to more engagement - every time. I think it
>>> would be great if we had an army of excited users wanting to test new
>>> features. The product would benefit. Users in SaaS for example always
>>> enjoy being [volunteering] part of a "beta" program - there is
>>> something satisfying for users in it. On the flip-side "beta" program
>>> for on-premise "enterprise" products are rarely so.
>>>
>>> Adding ontop the beta@ ... If we can make the "beta" collaborative,
>>> more engaging for users I think its a real step forward towards an
>>> army.
>>
>> I think you've got a point here, Jacek. I can see that our general
>> UX-impression as a project / community comes across as dated. It would
>> be great if we could improve that UX, and make it more modern, if that
>> helps reaching a broader group of users to help us beta-testing etc
>> ... and increase enthousiasm for our upcoming release.
>>
>> Do you (or anyone) have any concrete suggestions (within reach of our
>> very limited resources, especially regarding volunteer time to spend
>> on it)? People that want to help with this?
>>
>> How do other ASF projects do this actually? Forums, presence in other
>> online places, more modern website look and feel, ...?
>>
>> --
>> Johan
>
> Thinking out loud here ...
>
> Idea here is to change incrementally, so we can: change tools, cannot
> impact work flow, limit effort and amplify our capabilities as a team.
>
> Lets consider the five main work flows:
> - reviewing a patch submission;
> - reviewing a (typically recent) commit;
> - reviewing a back-port nomination (from trunk to branches/1.9.x);
> - reviewing a patch to a vulnerability (this is done on private@).
> - beta/feedback release
>
> Focusing on #5 for this thread and knowing that apache projects cannot
> have mandatory infrastructure dependencies on third parties, in order
> to ensure the projects' long-term independence; projects may use
> third-party-hosted tools, but they may not rely on such tools - the
> projects always have to have a Plan B for in case the third party
> service goes down.
>
> If we wanted to try the "github" model - Assembla is more than happy
> to support the community with native SVN support for "collab".
>
> For the case of beta@ we've done this successfully before where we
> create a public area for users to discuss, comment on features, code,
> ideas for an upcoming release. It would be extremely simple to put
> 1.10 into a repo with blame/compare/pull request/protected directories
> capabilities along side ticket tracking for feedback.
>
> If the test is successful and we improve quality/feedback, it's a great win.
>
> I can also help get resources to move other channels such as the
> forums, public discussion around 1.10 - once we close on a date.
> Getting good engagement is not as easy as a forum - marketing is a
> very important axis to get results, especially if we want to reach
> audiences typically not involved, such as for example game artists who
> use SVN every day - plenty of persona's out there that are using SVN
> for its power, are non-technical but would love the opportunity to
> help shape the "latest" SVN release with feedback.
>
> I think a modern subversion website is a great idea. I could look at
> getting resources to help with that as well. Even a simple
> re-surfacing may be a great step.
>
> If nobody is allergic to it I could setup a hosted 1.10-beta and see
> what everyone has to say with a concrete dartboard to throw darts at -
> worst case we burn it down and/or get the idea train going.

Hi Jacek,

Thanks a lot for these suggestions. They are all constructive ideas,
but I think we'll have to chew a bit on them.

I certainly want us to make progress in these areas, but it might take
a while to discuss these things.
Just wanted to drop a quick note that this hasn't fallen on deaf ears ...
-- 
Johan

Re: beta@ feedback mailing list?

[Daniel Shahaf <d....@daniel.shahaf.name>]

Johan Corveleyn wrote on Fri, 19 May 2017 01:02 +0200:
> On Thu, May 11, 2017 at 4:03 PM, Jacek Materna <ja...@assembla.com> wrote:
> > Getting good engagement is not as easy as a forum - marketing is a
> > very important axis to get results, especially if we want to reach
> > audiences typically not involved, such as for example game artists who
> > use SVN every day - plenty of persona's out there that are using SVN
> > for its power, are non-technical but would love the opportunity to
> > help shape the "latest" SVN release with feedback.
> 
> Good point. It would be great if we could "harvest" that feedback
> we're currently missing. Most of us here are not known for their
> marketing skills, so any help to reach out to wider audiences would be
> much appreciated.
> 
> For instance, I think it would be good if we could build up a place
> where "all users that want to help shape the latest SVN with feedback"
> would feel welcome (and I'm assuming here that "making them submit
> their feedback to a mailinglist" is not approachable enough).

Can we make the mailing lists more approachable?

I assume most people already have email, so it'd be easier to engage them with
something that runs over email than with something that requires learning yet
another tool, registering to yet another site, etc. .

Re: beta@ feedback mailing list?

[Johan Corveleyn <jc...@gmail.com>]

Hi Jacek,

Sorry for the late response (as I said, this required some chewing
:-). I talked a bit about this on irc with Daniel. See my thoughts
below (Daniel, feel free to chime in).

On Thu, May 11, 2017 at 4:03 PM, Jacek Materna <ja...@assembla.com> wrote:
> Thinking out loud here ...
>
> Idea here is to change incrementally, so we can: change tools, cannot
> impact work flow, limit effort and amplify our capabilities as a team.

Incremental changes are good :-). Minor workflow changes can be
acceptable (in exchange for enough added value), but that'll have to
be discussed. Limited effort and amplifying our capabilities: +1!

> Lets consider the five main work flows:
> - reviewing a patch submission;
> - reviewing a (typically recent) commit;
> - reviewing a back-port nomination (from trunk to branches/1.9.x);
> - reviewing a patch to a vulnerability (this is done on private@).
> - beta/feedback release
>
> Focusing on #5 for this thread and knowing that apache projects cannot
> have mandatory infrastructure dependencies on third parties, in order
> to ensure the projects' long-term independence; projects may use
> third-party-hosted tools, but they may not rely on such tools - the
> projects always have to have a Plan B for in case the third party
> service goes down.

Indeed.

> If we wanted to try the "github" model - Assembla is more than happy
> to support the community with native SVN support for "collab".

What is "collab"?

> For the case of beta@ we've done this successfully before where we
> create a public area for users to discuss, comment on features, code,
> ideas for an upcoming release. It would be extremely simple to put
> 1.10 into a repo with blame/compare/pull request/protected directories
> capabilities along side ticket tracking for feedback.
>
> If the test is successful and we improve quality/feedback, it's a great win.

Hmmm, not sure about this. Setting up some kind of mirror of our 1.10
branch (or trunk) on github or something like it ... interesting
thought :-), but I'm not sure if we're ready for that. These days
there is also ASF-infra-supported read-only mirroring on github (in
fact, github.com/apache/subversion already exists -- though we don't
do much with it). So if we wanted to go that way, I think that would
be the most logical choice. Or do you mean something different?

> I can also help get resources to move other channels such as the
> forums, public discussion around 1.10 - once we close on a date.

Which forums do you mean? Do you mean some current forums already in
existence, hosted by Assembla?

> Getting good engagement is not as easy as a forum - marketing is a
> very important axis to get results, especially if we want to reach
> audiences typically not involved, such as for example game artists who
> use SVN every day - plenty of persona's out there that are using SVN
> for its power, are non-technical but would love the opportunity to
> help shape the "latest" SVN release with feedback.

Good point. It would be great if we could "harvest" that feedback
we're currently missing. Most of us here are not known for their
marketing skills, so any help to reach out to wider audiences would be
much appreciated.

For instance, I think it would be good if we could build up a place
where "all users that want to help shape the latest SVN with feedback"
would feel welcome (and I'm assuming here that "making them submit
their feedback to a mailinglist" is not approachable enough). Though I
guess that would require at least a couple of the existing devs to
engage there (setting up some kind of gateway between "other channel"
and our existing mailinglist(s) might help here, to lower the bar for
the existing devs to interact).

Furthermore, once we're closing in on 1.10 and want to start creating
some buzz, it would be great if Assembla (and other vendors of course)
could amplify that through their own channels, and get the feedback
back to us.

> I think a modern subversion website is a great idea. I could look at
> getting resources to help with that as well. Even a simple
> re-surfacing may be a great step.

Great! Any help in this regard is certainly welcome. Though we'll have
to reach consensus before redesigning anything, of course. Or progress
in small steps that we can easily digest. Maybe there are some small
tweaks or cleanups we can do on the short term which can already help
a lot.

To get a bit more insight into this, maybe we / you could list some of
the shortcomings of the current website? I'm absolutely no expert (and
neither are most devs here), so any insight into this is more than
welcome. Some examples of what a modern website would look like might
help as well.

What do you mean with "a simple re-surfacing"?

> If nobody is allergic to it I could setup a hosted 1.10-beta and see
> what everyone has to say with a concrete dartboard to throw darts at -
> worst case we burn it down and/or get the idea train going.

-- 
Johan

Re: beta@ feedback mailing list?

[Jacek Materna <ja...@assembla.com>]

On Thu, May 11, 2017 at 10:14 AM, Stefan Sperling <st...@elego.de> wrote:
> On Thu, May 11, 2017 at 01:04:01AM +0200, Johan Corveleyn wrote:
>> How do other ASF projects do this actually? Forums, presence in other
>> online places, more modern website look and feel, ...?
>
> They use github :)


On Thu, May 11, 2017 at 1:04 AM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, May 9, 2017 at 3:32 PM, Jacek Materna <ja...@assembla.com> wrote:
>> Just observing from afar, in my opinion the root of what you are
>> trying to achieve here ties more to a lack of 'modern' collaboration.
>> If we want to engage the community/users more (expand the
>> IB/participation sphere - new - users) I would also explore
>> alternative mediums (versus email). One of the reasons Github has been
>> so successful in making git an overwhelming force has little to do
>> with git itself. They made the process easy, rewarding and exciting to
>> contribute as a user.
>>
>> An approachable UX leads to more engagement - every time. I think it
>> would be great if we had an army of excited users wanting to test new
>> features. The product would benefit. Users in SaaS for example always
>> enjoy being [volunteering] part of a "beta" program - there is
>> something satisfying for users in it. On the flip-side "beta" program
>> for on-premise "enterprise" products are rarely so.
>>
>> Adding ontop the beta@ ... If we can make the "beta" collaborative,
>> more engaging for users I think its a real step forward towards an
>> army.
>
> I think you've got a point here, Jacek. I can see that our general
> UX-impression as a project / community comes across as dated. It would
> be great if we could improve that UX, and make it more modern, if that
> helps reaching a broader group of users to help us beta-testing etc
> ... and increase enthousiasm for our upcoming release.
>
> Do you (or anyone) have any concrete suggestions (within reach of our
> very limited resources, especially regarding volunteer time to spend
> on it)? People that want to help with this?
>
> How do other ASF projects do this actually? Forums, presence in other
> online places, more modern website look and feel, ...?
>
> --
> Johan

Thinking out loud here ...

Idea here is to change incrementally, so we can: change tools, cannot
impact work flow, limit effort and amplify our capabilities as a team.

Lets consider the five main work flows:
- reviewing a patch submission;
- reviewing a (typically recent) commit;
- reviewing a back-port nomination (from trunk to branches/1.9.x);
- reviewing a patch to a vulnerability (this is done on private@).
- beta/feedback release

Focusing on #5 for this thread and knowing that apache projects cannot
have mandatory infrastructure dependencies on third parties, in order
to ensure the projects' long-term independence; projects may use
third-party-hosted tools, but they may not rely on such tools - the
projects always have to have a Plan B for in case the third party
service goes down.

If we wanted to try the "github" model - Assembla is more than happy
to support the community with native SVN support for "collab".

For the case of beta@ we've done this successfully before where we
create a public area for users to discuss, comment on features, code,
ideas for an upcoming release. It would be extremely simple to put
1.10 into a repo with blame/compare/pull request/protected directories
capabilities along side ticket tracking for feedback.

If the test is successful and we improve quality/feedback, it's a great win.

I can also help get resources to move other channels such as the
forums, public discussion around 1.10 - once we close on a date.
Getting good engagement is not as easy as a forum - marketing is a
very important axis to get results, especially if we want to reach
audiences typically not involved, such as for example game artists who
use SVN every day - plenty of persona's out there that are using SVN
for its power, are non-technical but would love the opportunity to
help shape the "latest" SVN release with feedback.

I think a modern subversion website is a great idea. I could look at
getting resources to help with that as well. Even a simple
re-surfacing may be a great step.

If nobody is allergic to it I could setup a hosted 1.10-beta and see
what everyone has to say with a concrete dartboard to throw darts at -
worst case we burn it down and/or get the idea train going.

Re: beta@ feedback mailing list?

[Stefan Sperling <st...@elego.de>]

On Thu, May 11, 2017 at 01:04:01AM +0200, Johan Corveleyn wrote:
> How do other ASF projects do this actually? Forums, presence in other
> online places, more modern website look and feel, ...?

They use github :)

Re: beta@ feedback mailing list?

[Johan Corveleyn <jc...@gmail.com>]

On Tue, May 9, 2017 at 3:32 PM, Jacek Materna <ja...@assembla.com> wrote:
> Just observing from afar, in my opinion the root of what you are
> trying to achieve here ties more to a lack of 'modern' collaboration.
> If we want to engage the community/users more (expand the
> IB/participation sphere - new - users) I would also explore
> alternative mediums (versus email). One of the reasons Github has been
> so successful in making git an overwhelming force has little to do
> with git itself. They made the process easy, rewarding and exciting to
> contribute as a user.
>
> An approachable UX leads to more engagement - every time. I think it
> would be great if we had an army of excited users wanting to test new
> features. The product would benefit. Users in SaaS for example always
> enjoy being [volunteering] part of a "beta" program - there is
> something satisfying for users in it. On the flip-side "beta" program
> for on-premise "enterprise" products are rarely so.
>
> Adding ontop the beta@ ... If we can make the "beta" collaborative,
> more engaging for users I think its a real step forward towards an
> army.

I think you've got a point here, Jacek. I can see that our general
UX-impression as a project / community comes across as dated. It would
be great if we could improve that UX, and make it more modern, if that
helps reaching a broader group of users to help us beta-testing etc
... and increase enthousiasm for our upcoming release.

Do you (or anyone) have any concrete suggestions (within reach of our
very limited resources, especially regarding volunteer time to spend
on it)? People that want to help with this?

How do other ASF projects do this actually? Forums, presence in other
online places, more modern website look and feel, ...?

-- 
Johan

Re: beta@ feedback mailing list?

[Jacek Materna <ja...@assembla.com>]

Just observing from afar, in my opinion the root of what you are
trying to achieve here ties more to a lack of 'modern' collaboration.
If we want to engage the community/users more (expand the
IB/participation sphere - new - users) I would also explore
alternative mediums (versus email). One of the reasons Github has been
so successful in making git an overwhelming force has little to do
with git itself. They made the process easy, rewarding and exciting to
contribute as a user.

An approachable UX leads to more engagement - every time. I think it
would be great if we had an army of excited users wanting to test new
features. The product would benefit. Users in SaaS for example always
enjoy being [volunteering] part of a "beta" program - there is
something satisfying for users in it. On the flip-side "beta" program
for on-premise "enterprise" products are rarely so.

Adding ontop the beta@ ... If we can make the "beta" collaborative,
more engaging for users I think its a real step forward towards an
army.

On Tue, May 9, 2017 at 1:28 PM, Johan Corveleyn <jc...@gmail.com> wrote:
> On Tue, May 9, 2017 at 1:06 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
>> Andreas Stieger wrote on Tue, May 09, 2017 at 12:55:31 +0200:
>>> Daniel Shahaf wrote:
>>> > One of the ideas that came up was to establish a dedicated mailing list
>>> > for beta / pre-release feedback.  The thinking is that having a channel
>>> > for advanced users to discuss 1.10-dev issues in — without noise from
>>> > support requests or design discussions — might encourage more such
>>> > discussion to happen.
>>>
>>> I don't know that given the current volume on either dev@ or users@
>>> would give way to a noise issue that would require a dedicated list
>>> for beta.
>>
>> The point wasn't that the current lists are too busy.  The point was
>> whether creating a dedicated list would encourage or enable users to
>> give feedback.
>>
>> I.e., would we receive more feedback with a dedicated list than with our
>> "post to users@" policy (the one we repeat in every release announcement)?
>
> Yes, I think that's a valid argument. It might help in creating some
> more traction focused around beta-testing 1.10 (in that case, maybe we
> should call the next 1.10 pre-release a "beta" instead of an "alpha"
> -- otherwise the announcement on our website might be a bit weird:
> "Subversion 1.10 alpha 3 has been released. Please test and report
> your feedback on beta-users@s.a.o" :-))
>
> --
> Johan



-- 

Jacek Materna
CTO

Assembla
210-410-7661

Re: beta@ feedback mailing list?

[Johan Corveleyn <jc...@gmail.com>]

On Tue, May 9, 2017 at 1:06 PM, Daniel Shahaf <d....@daniel.shahaf.name> wrote:
> Andreas Stieger wrote on Tue, May 09, 2017 at 12:55:31 +0200:
>> Daniel Shahaf wrote:
>> > One of the ideas that came up was to establish a dedicated mailing list
>> > for beta / pre-release feedback.  The thinking is that having a channel
>> > for advanced users to discuss 1.10-dev issues in — without noise from
>> > support requests or design discussions — might encourage more such
>> > discussion to happen.
>>
>> I don't know that given the current volume on either dev@ or users@
>> would give way to a noise issue that would require a dedicated list
>> for beta.
>
> The point wasn't that the current lists are too busy.  The point was
> whether creating a dedicated list would encourage or enable users to
> give feedback.
>
> I.e., would we receive more feedback with a dedicated list than with our
> "post to users@" policy (the one we repeat in every release announcement)?

Yes, I think that's a valid argument. It might help in creating some
more traction focused around beta-testing 1.10 (in that case, maybe we
should call the next 1.10 pre-release a "beta" instead of an "alpha"
-- otherwise the announcement on our website might be a bit weird:
"Subversion 1.10 alpha 3 has been released. Please test and report
your feedback on beta-users@s.a.o" :-))

-- 
Johan

Re: beta@ feedback mailing list?

[Daniel Shahaf <d....@daniel.shahaf.name>]

Andreas Stieger wrote on Tue, May 09, 2017 at 12:55:31 +0200:
> Daniel Shahaf wrote:
> > One of the ideas that came up was to establish a dedicated mailing list
> > for beta / pre-release feedback.  The thinking is that having a channel
> > for advanced users to discuss 1.10-dev issues in — without noise from
> > support requests or design discussions — might encourage more such
> > discussion to happen.
> 
> I don't know that given the current volume on either dev@ or users@
> would give way to a noise issue that would require a dedicated list
> for beta.

The point wasn't that the current lists are too busy.  The point was
whether creating a dedicated list would encourage or enable users to
give feedback.

I.e., would we receive more feedback with a dedicated list than with our
"post to users@" policy (the one we repeat in every release announcement)?

Re: beta@ feedback mailing list?

[Andreas Stieger <An...@gmx.de>]

Daniel Shahaf wrote:
> One of the ideas that came up was to establish a dedicated mailing list
> for beta / pre-release feedback.  The thinking is that having a channel
> for advanced users to discuss 1.10-dev issues in — without noise from
> support requests or design discussions — might encourage more such
> discussion to happen.

I don't know that given the current volume on either dev@ or users@ would give way to a noise issue that would require a dedicated list for beta.

We already ask users to contact users@ for "build problems, configuration issues, etc, as well as usage questions." I think discussing beta release issues on users@ sounds perfectly reasonable to me, until such point where implementation details are being discussed.

users@: beta issues including building, configuration, usage, performance
dev@: implementation, patches, release management.

Andreas

Re: beta@ feedback mailing list?

[Stefan Sperling <st...@stsp.name>]

On Tue, May 09, 2017 at 10:40:17AM +0000, Daniel Shahaf wrote:
> Johan, Stefan and I were talking on IRC about getting more people (devs
> and users) to run trunk / prereleases, in order to find more bugs before
> .0's release.
> 
> One of the ideas that came up was to establish a dedicated mailing list
> for beta / pre-release feedback.  The thinking is that having a channel
> for advanced users to discuss 1.10-dev issues in — without noise from
> support requests or design discussions — might encourage more such
> discussion to happen.
> 
> Thoughts?

Does the current level of noise on our lists really justify another list?
As far as I can tell the number of postings is steadily going down.

That said, if a special-purpose list such as this is useful to a subset
of our community, then I don't see why not.