Zone’s principal architect, Andy Butland, describes his time spent as a member of one of Umbraco’s community teams…
Going back to the earlier months of the year, when travelling abroad was a more viable option than it is right now, I took a trip to Odense, Denmark, for the inaugural meeting of the Umbraco .NET Core Transition team (aka the Unicore team). In an effort to improve collaboration between HQ and the community, Umbraco has put together a number of teams — for code collaborators, documentation, packages etc — and one to support the development efforts toward a migration of the content management system (CMS) to .NET Core was the latest of these.
Motivation
I applied to be part of the team for a few reasons. I’ve contributed to the Umbraco code base for some time in the form of various features and bug fixes, and when I heard about the plans to upgrade to the more modern .NET framework considered I would likely do so again. From the outside though, a migration project like this isn’t as easy to contribute to — there are less obvious features and tasks to pick up unless you are more involved with the roadmap, and so I figured being closer to this would help.
It also helps Zone maintain its active involvement with the Umbraco project — not just via financial support as a gold partner, but also as one of the smaller set of contributing gold partners announced earlier this year.
Lastly, and a bit more selfishly, for someone who spends a fair part of their day job working on various .NET CMS projects, all based on the older — dare I say legacy(?) — .NET framework, it’s a good excuse to help keep the CV up to date!
Activities
Having met various HQ staff, Bjarke, who heads up the project, and Shannon, dialling in from Sydney, took us through the plans, roadmap and key challenges of the project. Although I’ve preferred working remotely for years, and it is of course something we’re all getting used to now, these couple of (mostly) face-to-face days were particularly valuable for breaking down the project into manageable chunks, and making it more obvious where we could contribute as a team.
Most obviously, there’s writing code. Probably the largest single contribution was made by Scott and Emma from Rock Solid Knowledge, who, in having experience in this area, took on the migration of the user authentication aspects into ASP.NET Core Identity.
Personally, I’ve made more ‘little and often’ contributions, working on aspects like the clean-up of the solution architecture and code patterns, migrating and refactoring tests and translation of various code components like controllers, filters and attributes into their .NET Core equivalents. And whatever I do in the future in terms of contributions to the Umbraco project, I’ll always have the proud title of being the person who removed the last ASP.NET web form from the project (nonodes.aspx, for those interested)!
As well as directly writing code, another aspect we felt we could get involved with is promoting and supporting other members of the community that might be interested in contributing. Primarily we’ve done this via creating ‘up for grabs’ issues that others have contributed to, and then helping review the pull requests that come in as a result. Although we’ve only identified and created a few such issues, some of them fit the bill nicely by being quite large in scope and best handled via several smaller contributions from one or more individuals — unit test migration being a good example here.
Most of the communication on progress has come from Bjarke, speaking at conferences and blogging on the Umbraco website, which as a team we’ve supported — eg at the recent Candid Contributions’ hackathon and CodePatch virtual festival. On a more ad hoc basis, Steve has stepped up to the plate to handle Twitter PR and we’re lucky to have a TV natural in Benjamin, as seen on various video appearances such as an episode of umbraCoffee.
Progress
Over the past six months we’ve seen, and in a small part helped to make, steady progress. The solution structure itself has been reorganised, looking to better adhere to the clean architecture style. Projects have been migrated to .NET Standard where possible, allowing them to be used both by .NET Framework and .NET Core executables. While in the long run clearly only the latter will be needed, over the course of the migration project, being able to run the amended solution from both has been useful to help verify changes.
Patterns like dependency injection — now provided as part of the framework with .NET Core — have been used more thoroughly in the code base. And what was a monolithic tests project, has been better organised and refactored into two — one for fast, unit tests and one for slower, integration tests — allowing them to be run at different times and situations.
We’ve seen demonstrations of a functioning back-office application running on .NET Core on Linux — one of the benefits of the migration to .NET Core support being its cross-platform nature, opening up the product to a wider range of hosting options and developers. All this should hopefully lead to an “alpha” release in the upcoming months — consisting of the back office, albeit not yet feature complete, running on .NET Core. With that milestone reached we’ll hopefully be at a point to get further contributors involved, as it’ll be easier to find specific tasks to work on, picking off missing features and resolving bugs.
Contribution
I’ve enjoyed my time on the team so far and am looking forward to working with them further as things pick up again after summer breaks. For anyone considering joining an Umbraco community team — either a future formed one or taking a spot on an existing team — I’d recommend it as being worthwhile.
It can be tricky to find those situations when the trinity of time, inclination and “something useful to do” coincide, but — speaking for myself at least — what seems to work well with these teams is that there’s always useful ways to contribute, but without there being particular time pressure on any one person or task. With busy day jobs, families and/or other interests, everyone needs to take care to not overcommit to extracurricular activities, but with the Unicore team that hasn’t been a significant concern. Clearly some contribution is expected, but there’s never been any pressure to deliver or to work on specific tasks. Overall, community teams seem a welcome way of organising and supporting people who are already willing contributors to the open-source project.
