Treading water in big pool

GovCMS and the upstream challenge


Si Hobbs


As a landmark open source platform, GovCMS has a lot of disruptive potential, but it can improve on how it interfaces with vendors and the open source community.

Working with the new GovCMS platform, I've already noticed an increase in developer engagement, and the benefits of open sourcing the platform are already apparent. It's a fledgling GovCMS developer community, but I'm enjoying being a part of it.

This article looks at some issues I see with how govCMS engages with upstream issues and the vendors who could solve them. 

Closing the loop on SaaS upstream patches

One of the key issues working with GovCMS SaaS is that it disrupts the normal flow of "bug fixing Drupal with Composer patches". A typical best-practice Drupal 8 workflow might be:

  1. Find a bug
  2. Curse in Slack
  3. Track it down to
  4. Post a celebratory gif in Slack
  5. Write/improve/re-roll the patch on
  6. Put the patch in your composer.json
  7. Test now, deploy, test over time
  8. Move onto next task (patch process continues upstream)

SaaS doesn't support this model. In SaaS the upstream is disrupted. The SaaS equivalent is:

  1. Find a bug
  2. Curse in Slack
  3. Track it down to
  4. Realise it's solved (celebratory gif)
  5. Realise it's not going to be in a release for months (y u no gif)
  6. Start investigating how to work-around the issue

The outcome is that there is no patch, no upstream fix.

You can of course solve the problem, but this takes time, and right now this is time you need to be spending working around the issue. And working around complex admin UI issues can be very time-consuming, especially if you want to maintain a clean content model and editor usability.

Solution: Curated patches

GovCMS could start maintaining a set of curated patches, especially small ones that don't effect the database, or which just effect the admin UI. GovCMS team could include minor patches in the SaaS build (they have the technology), but they have been burned in the past by patching modules and then having no upgrade path when the module changes direction. But I have hope that this policy will change for minor patches.

Bounties (paid or unpaid)

There are features that I alone want GovCMS-the-platform to have, but I'm weird. However something I've noticed is that there are a lot of features that the GovCMS team wants, but don't yet have the resources to deliver. These include:

  • Features for SaaS that users (ie. other government departments) desperately want but no vendors are working on.
  • Bug fixes and improvements in ahoy and docker.
  • Improvements in the audit processes (eg Drutiny).

My thinking is this: If GovCMS wants it, vendors want GovCMS to have it, but it's not easy to know the priorities, or the acceptance criteria, for issues that are spoken about in passing ("oh you can't do this yet, but it's on the roadmap"). 

Solution: Curated bounty list

I think there is an opportunity for the GovCMS team to curate a list of issues that have clear acceptance criteria, and are clearly solvable through merge requests from vendor-land. There is already a milestone list on Github, but randomly picking off that list doesn't yield actionable items. My offer to the GovCMS team is: tell us what you want ... as a user story with acceptance criteria!

Bonus: Known issues

Known issues of the platform, and how to solve them, are very loosely managed. Usually they can be solved by asking in one of the developer channels. If you are lucky, you get someone who has encountered the issue, but that can be hit and miss, and it's definitely not googlable!

For example, developers on my projects are hitting issues with the standard README (which cannot be edited on SaaS), but not being directed to any sort of known issues as part of that process.

Another example is where we work around a problem on SaaS (unable to use an upstream patch). In this case we are not passing on knowledge to other vendors and developers, at least not in a formal way.

I think we need to somehow centralise and formalise how we manage known issues. It will emerge from vendor-land eventually, but in the meantime it would be great for the GovCMS team to point and say "Oh this is where we track known issues and it's community curated."

Edit: I've now created this ticket for crowd-sourcing GovCMS triage.


There might be more things I'll think of, but I think the above is a pretty good summary of where I hope to see GovCMS grow in the next year.

Please leave a comment below if you have any ideas about how GovCMS can improve its open source practice. 

Need training? We specialise in GovCMS and have trained it since it was is daipers.

Get GovCMS Training


Chris Burgess

On curated patches: We have multiple teams working on Drupal projects and sharing the knowledge of "you'll want this and this patch to run X alongside Y" is important to reduce duplicated effort. We have some manual process to gather this knowledge and I'm hopeful that we'll formalised this into workflow process that harvests "popular" patches from composer.json

On a bounty list: worthwhile, but would that make it GovCMS project owners task to decide what goes on the list? Could the GovCMS user community direct that conversation as well, which might give more insight into what people want (rather than what the governing project decided people should collab on)? (I'm ignorant of GovCMS process here, so I may have it backwards.)

Good thoughts, thanks for sharing and challenging the community to find better ways to work together Sime.

I'm hopeful that we'll…

I'm hopeful that we'll formalised this into workflow process that harvests "popular" patches.

Yes I think this is a very powerful mechanism that was enabled when composer came along, and managing patches because less taboo. Short of any formal mechanism, it would be amazing for PaaS users to donate their links here

Could the GovCMS user community direct that conversation as well?

In my experience, the GovCMS team seek feedback from vendors and departments to determine what things are needed and how urgent they are. So they're in a good position to curate a list, and know which things they (or have bandwidth to review. (Technically a curated list doesn't prevent anyone creating a merge request.)


Centralise and formalise how we manage known issues
michael goss

‘I think we need to somehow centralise and formalise how we manage known issues’

This is the key point from the article for me, the fact that people are having to solve the same problems over and over again and there is no knowledge base of known problems and fixes is something that has been on my mind. I’ve wondered if the GovCMS support desk have some kind of knowledge base they use internally that could be used as the basis for a public one that then anyone could contribute to. I find myself searching my own notes / slack / the community forums and wishing there was just one central list of issues and solutions. - Tim Cox, OPC Developer

Add new comment

The content of this field is kept private and will not be shown publicly.

Plain text

  • No HTML tags allowed.
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.


  • Allowed HTML tags: <em> <strong> <cite> <blockquote cite> <ul type> <ol start type> <li> <dl> <dt> <dd> <p>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
  • Use [gist:#####] where ##### is your gist number to embed the gist
    You may also include a specific file within a multi-file gist with [gist:####:my_file].

Spread the word