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:
- Find a bug
- Curse in Slack
- Track it down to drupal.org
- Post a celebratory gif in Slack
- Write/improve/re-roll the patch on drupal.org
- Put the patch in your composer.json
- Test now, deploy, test over time
- Move onto next task (patch process continues upstream)
SaaS doesn't support this model. In SaaS the upstream is disrupted. The SaaS equivalent is:
- Find a bug
- Curse in Slack
- Track it down to drupal.org
- Realise it's solved (celebratory gif)
- Realise it's not going to be in a release for months (y u no gif)
- 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.
Conclusion
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.
Comments
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.
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 https://www.drupal.org/project/govcms8/issues/3047291
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 Amazee.io) have bandwidth to review. (Technically a curated list doesn't prevent anyone creating a merge request.)
‘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