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 <jcor...@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 <s...@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 <jcor...@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