As mentioned in the blog post introducing the concept of the Community Roundtable Discussion posted on September 17th, we promised you a summary of what was discussed at this Community Roundtable.
Below you’ll find a gathering of notes made by three of the participants; Carole Logan, Laura Weatherhead and me, Kim Sneum Madsen. This will give you an insight into what was discussed and the thoughts around each topic as well as what the next steps will be.
As you’ll discover when reading, there will be duplicate points mentioned throughout this post. This is because we were three persons making notes and below is the result of us “just” merging our notes:
The Roundtable Attendees:
- Pete Duncanson
- Carole Logan
- Jeavon Leopold
- Callum Whyte
- Laura Weatherhead
- Jeffrey Schoemaker
- Adam Peter Nielsen
- Marc Stöcker
- Ilham Boulghallat
- Kim Sneum Madsen
- Jacob Midtgaard
- Niels Hartvig
How to sustain the continuous development of the Umbraco Project and the Umbraco Community?
The meeting kicked off with optimism. Each member shared their personal hopes; for the outcome of the three hours together, their aspirations for the community as a whole, and their own connections and experiences within it. The uniqueness of the Umbraco community was recognised by all, with an expressive commitment to trying to preserve the special spirit that pervaded community interactions and events and laid the foundation for the success of Umbraco CMS product.
It was felt that by getting a better understanding of the organic nature of the community, both past and present, it might be possible to map a path of a community member’s “journey” - from passive to active; contributing to leading - and use that journey to encourage new and existing developers to join in.
Thoughts on Motivation
The importance of fresh views and opinions to the community has been embraced in recent years with strides made in diversity and inclusion. However, as the product and company have matured there must be an increased emphasis placed on continuing to attract community members with diverse experiences and backgrounds.
It may not be possible at the present time to appeal with “shiny” new technology through the technical reach of the core product (given that the technologies involved here are unarguably mature) but there needs to be continued innovation - either through packages, product expansion or publicised “side projects” - to enthuse and motivate new members.
Despite improved and increasingly detailed documentation, there is still a high bar to getting started with getting Umbraco set-up. It is not as easy to piece something together on your lunch hour or get hooked into the “staircase” of iterative learning and contribution, as it once might have been.
Thoughts on Evangelism
The subject of evangelising Umbraco from one’s own platform (independent of Umbraco HQ) was explored from a number of angles, including the shifting tides of the community and the growth of the Umbraco product from open source roots through to commercialisation. There was some consensus that evangelical figures within the community had diminished compared to previous years, and some thought was put into why this might be or how it might be reversed.
One proposal was that evangelism is built upon intrinsic motivation - the pure desire to play and improve both one’s own experience as well as that of the product. Intrinsic motivation creates the drive to do something for “the greater good” without necessary recompense or return.
Another proposal was that evangelism blooms from a sense of responsibility. Of meaningful contribution and engaging with the product on an accountable level, so that the success or failure of features or functionality become linked with one’s own goals.
A final proposal was that evangelism comes from novelty; from curiosity. From being able to try something new within a familiar setting or use Umbraco to prop up new ideas or grow new projects.
In all cases - it was the creating of something valuable and meaningful that meant it became natural to want others to recognise and share in that creation, thus leading to greater engagement and the desire to evangelise the product. Being able to imbue the community with these feelings again could lead to a more defined sense of a shared “mission”.
Thoughts on Structure and Growth
As the Umbraco community and product have matured, increased in size and undergone widespread commercial uptake, it has been necessary to implement new processes and structure in order to accommodate the new scale of the project. This structure has eased some of the early “chaos” and the introduction of Pull request and Documentation teams has made it easier to contribute to the project and distribute the knowledge of how to do so through a wider audience than ever before.
However, what the product and community have gained in structure, they have lost in spontaneity, and this has reduced the ability of individuals to contribute larger or unrequested features/fixes. This dynamism once played a key role in allowing community members to feel part of the project as they were able to shoulder the burden of work that is now largely kept within Umbraco HQ.
As the community has grown, it is now too large to be able to support the “who you know” approach that has sustained it previously. Where there used to exist HQ members who acted as “lighthouses” for technical direction and questions, there must now be a distributed network of knowledge that is accessible to a wider horizon of community - especially those who are new or looking to make contributions. This complicates the issue of how to reduce the entry barriers and how to make meaningful headway on important issues - a single point of contact within HQ creates a bottleneck for productivity, but likewise, HQ buy-in and direction is often needed for anything valuable to happen.
Thoughts on Contribution
There was some discourse around what it means to “contribute” to Umbraco. For a long time, this has meant contributing code to the core product in the form of Pull Requests, but there was some discussion around alternative or additional ways that individuals can get involved - be this within the community itself, documentation or feedback.
The advent of the new RFC process has allowed the community to feedback and contribute to new major (and minor) developments within the core product. These changes and feedback contributions range from offering expert advice on moving to .NET Core to more incremental changes such as new ways of tackling various property types and implementations. There was some discussion to how this process can be non-inclusive given that it is played out within the confines of GitHub (must have a GitHub account) and requires contributors to be able to express their views clearly in English as well as being able to weather often turbulent feedback from others.
Although the RFC process is still in its infancy within the project (given that it was only introduced in mid-2019) it would be beneficial to appraise the process for success and adapt it to the often-unique workings of the Umbraco community. It was also discussed about the opportunity for community input into Release Candidate testing (as with the latest 8.2) and whether there would be potential for input into the features and functionality that are included in the planned product releases earlier in the cycle.
Thoughts on Purpose and Balance
Finally, there was some discussion around the purpose of the Umbraco project and how it was viewed within the group. Although the product was originally designed to make an editor’s life easier, it is also the tool of choice for many developers and as such, they are personally and professionally invested in improving it for both their own purposes and for their clients. It was believed that this balance of being designed for editors but being adopted by developers was an important point of balance for the product and tipping it too far one way or the other would be sure to lose community traction.
The fact that Umbraco strikes a balance allows it to be melded into the appropriate tool for the job because different use-cases in business or pleasure require a flexible tool. Even within the development sphere, there are striking differences between a developer who wishes to experiment and play with a product versus a developer who is implementing a strict business case.
Notes i.e. things said during the discussion
- It has been good to discuss and well needed.
- Ways to (re)vitalize the community and product.
- New technology interests. New tech is interesting and drives engagement. Give people the itch
- Freedom to write as and what they want.
- Bottom-up process. Not top-down.
- Contribution is often seen as being code only. Redefine what contribution is
- The community is very broad and has many viewpoints eg. tech/non-tech, new/”oldies”
- A clear path and low entry barriers entering into the community is important.
- Stability, ease and predictability come with more structure and process time and reduces anarchy. There is a chasm to be bridged between anarchy and structure
- Do retro’s and evaluate initiatives.
- How to get attention from HQ should be clearer
- Communication is key
- Make the unknown “Shannons” (HQ lighthouses) visible - perhaps making community lighthouses as well.
- Perceived lack of enthusiasm and new people joining the community (even if the numbers don’t reflect that)
- We should map out “contributor journey” like we would a customer journey to see the different motivations to contribute and also ways to contribute.
- PRs to the core isn’t the only way to contribute, how can we highlight the others?
- Less big PRs to core now, but as there is a bigger team at HQ now is that to be expected?
- Highlight innovative things made by the community with Umbraco.
- We need to allow the community to “make their own speedboats” and HQ to facilitate this. Thus, Umbraco HQ being seen as the big stable super tanker, which has difficulties in changing course quickly. We need fast, exciting projects/teams (speedboats) to be able to go out and experiment, keep people engaged, etc.
- Dev CMS or Editor CMS- we need it to be both editor/ business-friendly and developer-friendly.
- The RFC process- needs refining? Too intimidating/time-consuming?
Visibility to HQ:
- How to get in touch if you have an idea for PR.
- Can sometimes be easier if you already know the devs, how do we make this easier for new contributors?
- Community visibility of sprint planning?
- Good to see Release Candidates of next release, lets the community see what’s changed & feedback. Also, prepare if any breaking changes.
- Focused groups of experts working on particular “teams”.
- “Core” group in the middle (with HQ involvement) then more people involved in the circle's example.
- Need to ensure we have a “Pacman” slice out of circles to allow others to join.
Concentric circles: a model for describing interaction in the community
A consensus was established that this can be used to describe how to work together. Imagine a number of areas/sectors each with its own team. The inner circle is the Steward (it could be one or more persons, it can be community and/or HQ). The closer to the inner circle the more involved one is in setting the scene, contributing, influencing etc.
A set of concentric circles for a number of teams. Currently, we have three such teams consisting of both HQ and community members:
- Documentation team
- Pull Request team
- Packages team
How many circles each team has depends upon the area. But it seems that this model gives us terminologies and ways of describing how one can contribute. Names and terms are yet still to be determined.
Some closing remarks from the attendees
- Good ideas - focus is important
- It will not play
- We have to change in order to stay the same. More is needed. Glad that we have this talk.
- Growing is hard to do. Love being here.
- I need to reflect.
- Umbraco is going through its teenage years. Anarchy vs. structure.
- Good to hear and understand each other. Good to hear about HQ probs. and struggles. Concentric circles are a good model.
- What the others said. Umbraco is now a “Supertanker” that is stable but less energy. Light the fire in people.
- Passion is real. We want this to happen and are committed to investing time and people in making this happen.
- Really good meeting. Create mores speed boats around the SuperTanker. Create your own speedboat.
- The passion is real. From all involved. It doesn't have to be perfect.
- The potential shift in contribution from the core to other areas is important.
- Map out your community member journey as you would do with a customer
Twisting a famous quote: "This is not the end. It is not even the beginning of the end. But it is the beginning of the beginning"
In order to sustain the continuous development of the Umbraco Project and the community, we need to change. We need to organise. We need to engage. We need to lower entry barriers. We need to communicate. We need to listen to each other. We need to trust each other to take the right steps forward. We need to...
As per the summaries above, the input at the discussion in Utrecht and as seen from HQ perspective; this is a beginning. A beginning of doing things differently, but with all the intentions and passion that took us so far, being intact.
The Roundtable discussion provided a window through which to usher a new and improved flow of information between the Community and the HQ. Moving forward together is important and as such, we:
- Will start working on identifying where to lower entry barriers.
- Will try to Identify areas relevant for evaluation e.g. RFC process.
- Will increase our communication on processes, ideas, feedback, etc. and ask for help when and where we need it
- Will establish other teams than Docs, PR and Package where relevant.
- Will schedule another Roundtable discussion for February/March 2020 where we will invite further input from the community
The above is not a comprehensive list, but serve as examples. As mentioned, we want a dialogue so feel free to come forth with any ideas, thoughts and/or comments to Kim; firstname.lastname@example.org or Ilham; Ilham@umbraco.com