From Humble Beginnings

In May of 2018 I attended the annual Codegarden Retreat for the first time. I was as anxious as I was excited. I knew only what I’d heard about the Retreat. It was for folks who had made a massive, often code-shaped, contribution to the CMS over the years. It was a great honour to be invited. It was an opportunity to spend time with Umbraco community legends and rising stars. All in a beautiful setting, with fine food and incredible views. It was intimidating in the build up but once there, there was only word I could use to describe it: galvanising. 

A great many wonderful ideas are borne out of the Cg Retreat. Over the years these have included the Grid and the starter kit to name but a few. That year I was working hard on UX changes to Our. It was satisfying work and we spent our days discussing what we could do and this generally spilled into our evenings too. Around us, other exciting things were happening. The Documentation Curators team were looking at versioning the docs, some were overhauling the grid, a team worked on a Hi-five section for Our. It was about half way in to the retreat that the request appeared in the Slack channel.

Now I am well known among friends for volunteering for things but on this occasion I didn’t bite. I was a new contributor. I had only recently submitted my first pull request. Of what use could I be? After a day or two of radio silence though, I asked, tentatively, if perhaps I could volunteer to be on the team. You know, just until someone properly useful could take the spot?

I was met with a resounding yes. Seb who holds the role now known as ‘Team Steward’ but then just the poor sod who had to manage this new initiative, told me that I could absolutely be of use and that my skill set was aligned with what they had in mind. Everything I didn’t already know how to do, I could work with the team to learn. So it was settled. I was on the team. 

The team grew over the coming days. At Codegarden 18, during the Keynote, we asked for more volunteers. We even tried to poach people and we were fortunate enough to have one person agree to do it: Poornima Nayar. We were delighted.

Most Codegarden attendees will tell you that the period just after it takes place is a really fertile time - enthusiasm is contagious and after spending a handful of days with the fellow attendees, speakers and organisers, you return home with a feeling that you’d like to get involved too. We spent those weeks as a new team building processes, trying things that worked, others that didn’t and getting to know the task we had ahead of us. Our team steward had newly been appointed Head or PR for Umbraco (no, not that kind of PR) and so had time set aside to work with us to create a system that would work and there were a few factors that we had to discover along the way that would make life a little more interesting than we’d realised.

 

What Even Are We?

What was it we did as a team? Well, that itself changed over the years too. At first, our aim was to reply to every pull request that had been raised. We wanted to thank people for their contributions. We tossed around the idea of using a bot to do it - it would sure be quick - but we felt it didn’t feel as ‘friendly’ as we’d like. We wrote to thank people and to reassure them that their work would be looked at in a timely fashion and explained what to expect next. We decided to look at as many pull requests as we could, test the functionality and review the code and approve if it was all good, request changes if not. It was a simple mission statement and we quickly realised we could perhaps do even more. 

At one of our fortnightly meetings, we decided we could look at the issue tracker too and replicate issues to see if they could be closed or labelled up-for-grabs so the community could pick one up and raise a pull request for it. We navigated github permissions and created workflows. These were trying times. We had the willing, the smarts, the people but we needed process. We hadn’t realised a few things.

Our first on-the-job discovery was around the fact that we hadn’t worked together before as people. For some of us it was the first time actually meeting too. We would spend weeks getting to know each other on the job, learning each other's skill sets, likes and dislikes and general approaches to the work. We were all volunteers; volunteers who had full time jobs to do outside of the team work so time we were able to spend on it would fluctuate, often with little warning, because that’s what life looks like. We were in different countries. Poornima and I were the closest, geographically but there were slight differences in timezone and very little chance of us getting together physically.

The thing we hadn’t predicted was that the more work we did, the more work we had. I liked to speak about this discovery around the time by saying that we were victims of our own success. There are numbers and graphs - not my forte so expect none here but if that’s your thing, find some in this series of blog posts - that basically show that after the team formed, we had a huge influx of new and returning contributors. We were formed to address a particular problem: contributors who had given their time to create a pull request were feeling abandoned as many pull requests had not had replies. So while folk from the community and Hq were encouraging people to get involved, there was no strategy for dealing with their contributions. Some pull requests had been sitting there, untouched for over a year. When the team got involved and began to respond, people who had felt discouraged decided to have another go. Those who had never contributed saw us tweeting or talking about how welcome those contributions were and got involved too. It meant that the already high number of pull requests stayed actually pretty high. 

That first year we were asked to attend the first Teams Retreat and I was psyched to say the least. We flew out to Odense (or in Anders Bjerners’ case, drove there) and set about sharing our thoughts on a process across a couple of days. It was the first time since we had formed that we had all been in one place and it was only 6 months down the line. By this time we had so many learnings about what had and hadn’t worked - we knew we were still missing pull requests and that there needed to be a system more reliable than actually reading through all the emails we got from Github. A dashboard was the answer. We decided on the spec as a team and Anders sat down and built it. This new dashboard would give us a list of pull requests that hadn’t had replies and the number of days since it had been submitted. We’d have oversight and we’d be able to reach more people. 

We also came up with an agreed-upon process. Who would reply, what the timescales would be, where we would progress things in a variety of cases. It gave our work shape and it meant we’d have a consistent approach to managing incoming pull requests and issues. We returned home and we carried right on.

 

Getting Along

The feedback we had over that time was immense. We all felt we were really making a difference to the experience of contributors. We spoke at events, we helped out at Hackathons and, at any given opportunity, we reminded people that they too could do the work we did. The work would be welcomed. People listened. They joined in and began to comment on other people’s pull requests. We had so much chat on that Umbraco-CMS repo we almost felt that that was the success in itself. We didn’t have the pull requests number down the 0, the number of issues was going up too but my goodness, we had engagement. It was such a contrast to what had been before. It felt amazing.

2019 was a fab year for us as a team. We built on the successes of 2018. We went to the Codegarden retreat as a team and we worked on github automation around issue labelling, among other things, electing to keep that first reply friendly and human. The numbers were good but we still missed things. We didn’t always say thank you in time and we didn’t always merge within 2 weeks. We were organised but ultimately, we had other commitments and the amount of time we could put in waxed and waned. At times we were a well-oiled machine, others, we all had stressful work projects that ate into our free time, kids that needed parenting or any other thing that life threw at us and in those, we limped along. One of the very best things about being on this team was that the team made no demands. We were asked to give what we could and always thanked for what we gave. We said goodbye to one team member but welcomed another right soon after at the next Teams Retreat. Kenn was a stalwart of the repository and had been creating pull requests at an alarming rate for some time. He was also quick to comment on others to provide support. He was everything we needed, he had fantastic oversight and knew what it meant to be a contributor. We reorganised and we got right back to it. 

We had a presence at as many of the Umbraco hackathons as we could. We ran a few too! We went to Code Cabin and while there, supported old and new contributors, merging as we went. Back when I joined the team I had raised maybe 3 pull requests myself. By the end, I was supporting others to do their first and helping to troubleshoot for those who had run into issues getting set up. 

 

What Now?

Thanks to the work I had been doing on the team I had by now been asked to speak at a number of conferences, meetups and festivals in a bunch of different countries. I loved having the opportunity to travel but actually, the most satisfying thing about that time was the work I did with new contributors. In Poland I took a roomful of people through their first pull request. We chose the issue there and then mob-programmed the solution. Later in the year when a workshop I was going to run at a conference didn’t quite pan out, I gathered some of my favourite experienced contributors and we spent the session talking about how we got started and helping others to begin too. That day we enjoyed ourselves so much, we decided we should talk more and from there, the Candid Contributions podcast was born. 

Before I stopped being a team member proper and became an honorary member, I began to look at ways we could empower community members who did not code, did not wish to code or just fancied another way altogether of being involved to contribute by working on issue triage themselves. While the team continues to pick up reported issues, replicate them and close or progress them, I’d love to see community members given the chance to do this too and for them to be able to earn a contributor badge, and much thanks, for their work. If we could be half as successful raising engagement around the issue tracker as we had been for pull requests, we’d have achieved something wonderful indeed. 

I am immensely excited about the new team. Once again, it is made up of people who are keen to get stuck in and empower contributors. They have the benefit of our learnings, the processes we put in place and both the successes and mistakes we have collected along the way. They also have a group of honorary members who, grateful for their own experiences, have decided to remain committed to assisting the team and their goals in any way we can. These last 2 and a half years have been interesting, to say the least. I can’t wait to see where we are at in 2 more. If you’re interested in joining one of the HQ community teams, I'd urge you to do just that. I wasn't sure that I could be of use and 2 years on, I can't believe how busy the work kept me. If that's you, then make sure you keep an eye out for the Umbraco blogpost for the next round of applications. I couldn't be more grateful that I took that leap.