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 <jcorvel_at_gmail.com> wrote:
> On Thu, May 11, 2017 at 4:03 PM, Jacek Materna <jacek_at_assembla.com> wrote:
>> On Thu, May 11, 2017 at 10:14 AM, Stefan Sperling <stsp_at_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 <jcorvel_at_gmail.com> wrote:
>>> On Tue, May 9, 2017 at 3:32 PM, Jacek Materna <jacek_at_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
Received on 2017-05-15 17:03:48 CEST