[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: beta@ feedback mailing list?

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 19 May 2017 01:02:55 +0200

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 <jacek_at_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.


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

Received on 2017-05-19 01:03:21 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.