Name: Marc Goodson
Job title: Umbraco Architect
(my mum always wanted me to be an ‘Architect’)
Has been working with Umbraco: Since ??... Marc will tell you in a more elaborate way than "just" a number of years. Read on! You're in for a treat.
For how long have you been working with Umbraco?
I like to think that Umbraco is a bit like a High School, with its crazy Headmaster and HQ made up of teachers in different subjects and administrative staff to support and plan the timetable. Each Codegarden marks the start of a ‘new school year’ with first-timers taking that anxious plunge into their new learning environment, not knowing quite what to expect and hearing tales of high jinx from former pupils… the stories passed down through older siblings (well, people from the same company that have been before) … the time there was a pillow fight, the time Umbraco 5 got canned, the time a car got flipped… the list goes on and on - the disbelief, the slight fear, the joy.. Somebody just high fived me and said that I rock? - the faces change each year but the school and its ethos remain largely the same.
It takes about 7-8 years to progress through High School and I think that must mean I’m in the ‘Upper Sixth’ about to sit A-levels and leave to go off to Uni. I’m looking around and seeing people in ‘my year’ and what we’ve been through together, and thinking about people ‘above me’ who have now left and that originally led the way, and thinking back to my first year too, with a wave of nostalgia, if I could go back now and do it all again…
… and well I’m thrilled to have been chosen by the School Board to write this account of my time within the Umbraco Community, my contribution story, not least because it will look good on my University application form, but in all honestly I can’t think of a single thing I’ve meaningfully ‘contributed’, - so this might be the time to check the left hand navigation and choose a different person's awesome story!
What motivates you to contribute?
I think I owe a debt of gratitude...
When I sort of accidentally became a web developer, writing Classic ASP, though it was by no means ‘Classic’ then in 1998 listing out content from an Access 2 db - I mainly found out how to do things from a website called 4GuysfromRolla.com, it was awesome, everything I needed to do, was there, for free. It was at the time in development history when anyone who blogged or published anything about development online had to be called Scott, and well basically these early ‘rock stars’ kept me in several jobs - I had no right - based upon experience or education or multiple purchases of ‘how to learn x in 24 hours’ books - to keep.
In Umbraco terms, I got the same vibe and debt from the people in the ‘years above me’… people like Matt Brailsford, Lee Kelleher, Darren Ferguson, Tim Geyssens, would blog, inspire, share knowledge and release packages, push boundaries. In the early days of Umbraco there was a real feeling of camaraderie, almost rivalry, to be the most awesome.
So this is kind of the debt I’ve been trying to pay back ever since, that I guess is ‘my motivation’. We are all building stuff on the shoulders of what has been built before, and I’m not saying I’ve helped lift anything any higher along the way, but it’s great to have been sort of part of something that has evolved over time, even if it seems I’ve only contributed one or two lame jokes every now and then.
Oh and also, another thing… it really really sucks if you are stuck, I’ve been stuck loads of times, and it can be horrible - so I have tremendous empathy for anyone in that situation, and I’ve found helping people who are stuck become unstuck… is the best feeling ever, and usually it’s something simple, that tired lonely developer eyes cannot spot, you know, the c# class is not marked as public...
Right, and another thing, Guilt, everyone is all really rather lovely in the Umbraco community, but I’ve often been accused of making money out of open source and that makes me tremendously guilty, and uncomfortable, and probably helps fuel some of my efforts to try to recompense and well clear my conscience, as much as possible, in that respect.
And finally, anthropomorphism! - I’m slightly obsessed with examples in technology where a thing, or software, or interface is ascribed human traits and emotion, we’ve all got names for our vacuum cleaner/car/dishwasher, right?
Well Umbraco often feels like one of these entities we ascribe personality to, not necessarily a simple extension of the ‘personality of core individuals’, Niels/Per/Seb/Stephan/Shannon et al, although some kind of autopsy might reveal their DNA influence, it appears, to have a distinct personality in its own right!
What I mean is, people who use Umbraco, Editors, Developers: all do seem to ‘engage’ with it at this anthropomorphic level - so, it ‘feels like a friend’…
...you don’t always approve of what it does or how it behaves, but you're still there to help it move house if it needs you.
How much time do you dedicate to contributing?
I check-in fairly regularly on the forum, GitHub repo, twitter etc, throughout the day - they are all sites that are checked as part of my ritual (along with the Coventry City FC site) of removing distractions and getting into ‘the zone’. (that’s the state of ‘being focussed’ - not ‘The Zone’ nightclub in Cornwall...)
I try to answer at least two questions correctly on the forum each week, (see Karma Suit ya! - for a longer story about forum post answering rationale), and usually I have some documentation ‘always on the go’, several blog posts that I never publish - and half-finished package ideas, notes for future talks I’ll probably never be asked to do and I’m usually working on an idea for fixing or improving something I’ve noticed in the Core, but that I’m not quite sure whether I dare mention for fear of being stupidly in the wrong.
So, I flit between the things ‘on the go’, depending on time and whim. You’ll have noticed my ‘contribution story’ is appearing much later than everyone else's, though I suspect I was asked at the same time.
I try to read everything that is happening on the Core repo, and forum posts that aren’t answered, but that is mainly as it’s part of my job to know what is changing in Umbraco and what problems people are experiencing with those changes, so I can advise Moriyama clients accordingly and the individual development teams and developers that we build alongside, support and mentor.
How do you manage your contribution time?
I’m not sure that I do?
Are there productivity tools that you use and that you can recommend to (new) contributors to the project?
Well, not really a productivity tool but can I say this?
If you are in your first year here at ‘Umbraco High’ (Go Unicorns!), and you are excited, and nervous, and want to ‘get involved’, but don’t know quite where or how to start. Maybe you are a little giddy at the thought that one day ‘your code’ will be churning around in this tumbling open source Umbraco barrel, and being used by people just like yourself, and that is a fine inspiration and aspiration to have but it can be so daunting and it’s completely natural to feel like an imposter! (shsshs, don’t tell anyone, but I don’t know what I’M doing! - or have you already formed that opinion if you have read thus far?).
Anyway, what I think is the best way to get started is to try and test things - installing the latest release candidate for the next version of Umbraco, and testing bits and pieces around any new features, and things related to changes in those features - creating issues on the tracker (there will be issues!) - it lets you know what is upcoming in Umbraco, and helping identify problems before a version is released is in everyone’s interest. It’s also where I feel Umbraco perhaps needs the most help from the community.
There are currently 200+ open PRs with the main Umbraco core repo - try reading some of these, if some catch your interest, why not pull down the branch, get Umbraco to run locally from source (The Core PR team often run webinars and have guidelines of how to do this). Test out the PRs, feedback your thoughts - just knowing that the PR doesn’t break Umbraco, and does what it says, is again a really valuable contribution. This will give you a great insight into how Umbraco works, and before you know it, you’ll find yourself commenting… adding to a PR… sparking ideas for your own PRs…
Final tip: Read the Forum! - The Our Umbraco Forum contains so much valuable knowledge and ideas of how to fix things or set up and extend Umbraco in certain ways to solve common problems. I mean you can’t read the whole thing for the last ten years, but if you set aside some time each week to skim through recent questions and answers, you will find stories of interest, and fantastic nuggets of ideas to add to your Umbraco implementation armoury. Hey, and maybe you’ll find a question without an answer, that you might know the answer to… or have the time to help work out... and you can reply to pay off some of your debt too?
My time-saving tip here is to always have a version of the latest Umbraco ready to spin up on your machine, so you can try things out quickly that people are reporting in the forum - over time then you’ll have an instance for each version to hand...it can be fun to work things out and rewarding to help people… but you’ll learn tons yourself in trying.
Work with the Documentation Curators
How were you able to get started with the team?
Some of us talked at the UK festival hackathon back in 2017, mainly with Seb and Stephan, about the huge number of open PRs in the core Umbraco repo, and how, well, not all of them could be ‘processed’ by HQ. The problem being not all of them were complete ‘ready to pull’ PRs, they needed testing or feedback before they could be progressed, or explanation that the feature was something too big for the core, or the UI was wrong etc etc.
We discussed how it wasn’t possible to scale HQ to handle all of this incoming noise and how a culture of accidentally ignoring PRs had developed because although HQ people wanted to help, it took time away from what the individual was meant to be doing, and it distracted Umbraco from the direction they were trying to move forwards in.
Any kind of communication on an issue or PR kind of made the individual responsible for seeing it through and there was no process in HQ at the time for supporting that, and so PRs were left to stagnate... not maliciously, I had one ignored for over 2 years, and it even had a ’prioritise this’ label added by Niels on it :-P
We all understand why things were the way they were but we wondered whether the community could help in some way? The documentation repo was in an arguably worse state of stagnation and this was suggested as perhaps something to experiment with in terms of community help, and so when Jeavon said the experiment ‘was on’ - I felt it would have been a little disingenuous to say I wasn’t interested.
I’d contributed regularly to the docs repo, and understood a little of the frustration of the experience. What I really wanted to demonstrate though, was how to run the Github repo for contributors in a positive and friendly way.
What I felt contributors needed, based on my own experiences - wasn’t ‘complete resolution’ of any issue within an SLA, but just an acknowledgment and gratitude for their immediate efforts for raising the PR, with some human interaction based on the content of the PR, to indicate the repo has ‘listened’. Contributors are often giving up a chunk of their time to do ‘anything’ - so at a very basic level that effort should be appreciated. The idea is if contributors have a positive experience of contribution they will contribute again.
The initial response just needed to convey thanks, and perhaps ask any questions raised from a quick glancing triage of the change - highlight anything immediately obvious, and lay expectations for how it would be processed, ideally within 2 weeks. Automating this response would completely miss the point, it is the small nugget of human connection and interest that makes the difference.
We set about tackling the backlog of existing PRs (four pages of PRs going back three years).
It was good to have a tangible measurable challenge, to get open PRs down to a single page in Github, and it took up most of our spare time tackling them.
We decided to meet fortnightly (just to confuse people who aren’t sure what fortnight means… once every two weeks). To check in and discuss things that needed a decision
It was fun, working with the other ‘documentation curators’ and writing to people on the repo, and in six months we had tamed the list of open PRs down to a single page. We then identified some of the gaping holes in the documentation, producing some content ourselves, but trying to encourage others to contribute too.
Our secondary aim was to just reduce the number of times people said the ‘documentation is rubbish’ in the forums… and it felt like we turned a bit of a corner before the release of V8, and people were contributing regularly, and we managed to convince HQ to include time in sprint planning for documentation. New features were being documented as they were being released! Huzzah!
It felt like a success, It felt like the community had helped, the experiment was extended to the Core repo, and well that is the origin story for why we have lots of community teams today. However, the story does not end here, the size of the task of retrospectively documenting an ever-changing open source project like Umbraco is huge, it will never be finished, it cannot be resolved by the contribution of one person, things are always changing, only many regularly small contributions from lots of people will prevent it from stagnating again.
But anyway, that’s how I got started.
How are the tasks organized between the team members?
We discuss in each meeting, what has come up recently and needs action now-ish, and what activities tie into longer term objectives, this will vary depending on everyone’s free time and area of speciality, and we’ve slipped into several unofficial, unspoken roles, but generally people volunteer for taking something forward.
How much time do you allocate to the team?
We meet once a fortnight for an hour, outside of that will depend on what else is on, with the tasks I flit between (see above) and if I’m honest, if it’s either interesting or important.
Eg, when V8 was released we made a great effort to try to bridge the knowledge gap in the most important pages of the documentation, I was updating pages daily, cross referencing problems raised in the forums, raising issues for bugs in the main repo etc etc…
… but it’s also possible to go the whole fortnight now without dedicating any time. “Those lazy documentation curators”. :-P
What advice do you have to someone interested in joining a Community Team?
I think it’s a great learning opportunity, I realise I don’t have the qualifications for V8 but I’ve written lots of the documentation and worked with others to curate the PRs of other updates. It’s ‘paid back in spades’ for my day job, consulting and helping companies get started with Umbraco and adapting to using V8.
The main thing is it’s really nice to feel part of a gang of lovely people, with a common purpose who chat regularly. But it also feels like a big commitment as there is no ‘easy way’ to leave a team… which is why we are running experiments with ‘interns’ (possibly the wrong name) in the documentation curators team, so that people can join the team to try out what it’s like for six months, a bit like Jury service, perhaps take on a ‘project’ - Bring some freshness, enthusiasm, and new perspectives on the activities of the team rather than it just being the SAME set of anointed folk doing the SAME old things ‘forever’!
Also I’m aware at the end here I should be tying this narrative back into the High School metaphor I started at the beginning, you know, like how proper writers do - but I’ve gone so far off track with the docs team stuff, it would feel slightly clumsy to do so now and make some kind of elaborate reference to the School Newspaper/Radio/Football Team or reference High School ‘factions’ and all - so yeah, I’m just going to set the Fire Alarm off instead…