Blog for Public Code

This blogpost

Date:16 March 2021
Author:Jan Ainali

Feed

Subscription feed

Contribute on GitHub

4 March 2021 Standard for Public Code community call

Attendees

Updates from the Foundation

Proposed for this call

We’ve had requests to review codebases against the Standard from codebases that at the time were not on a path towards full stewardship. We need to prioritize our work, but we also want the Standard for Public Code to be widely used.

We’ve already created an introduction course and briefly floated an idea of vendor training.

Let’s have an open discussion now on how to grow a community that’s confident in applying the Standard for Public Code to a codebase.

Notes

The discussion had a lot of different angles and ideas. The ones below sparked the most discussion.

The standard as a help in procurement

We discussed if the standard could help a public organization about to procure development services. Right now the confidence of both buyer and the seller are too low for either of them to go that way. In theory, the standard should be able to be part of a procurement, much like a set of functional requirements. What might help are more codebases showing how they are compliant, and guides to get there.

“Flavors” of the standard

Another idea that was discussed was “flavors” of the standard that certain solutions and practices are prescribed in a stronger sense than the standard does today. The openess of it now gives so many choices for the implementing party that it doesn’t really give much direction at all. If there were some framework specific flavors that prescribed certain styles, tools and methods, it would be easier to start developing and spend less time choosing among these. These flavors could be created by codebase communities themselves to be distributed in the teams working with the codebase and be reused by anyone who finds the flavor useful.

Generic codebase template

Related to this, but also different in the approach, one could imagine a very generic codebase (which in itself doesn’t do much) that meets the standard that could be used as a reference point and inspiration. This could have the most preferred of all methods and good practices in it. But it might not be the Foundation for Public Code’s role to maintain it or decide what goes in it. Instead, it could be a community curated resource.

Guides

More guides like the one on how to start a Standard compliant GitHub repository were also requested. This would make it easier for public organizations and vendors to use the standard right from the start.

Vendors checking compliance

Could checking standard compliance be done by vendors? Yes, that should be possible. However, only the Foundation for Public Code can certify a codebase, but as a pre-check that should be doable. Vendors might be interested in selling this service if there is large enough demand for it.

Marketing and outreach

To get more people over the first threshold, and to establish the Standard for Public Code as a well known concept, there were suggestions to market it more proactively. Unfortunately we didn’t have time to discuss how to do this in detail, though this might be topic for a separate community call in the future.

Does using the standard create a lot of overhead?

Lastly there was a question if complying with the Standard would slow down the work in a codebase. Our experience is that it’s a bit of an investment when starting, but that it enables collaboration and increases quality in such a way that over even a short time it will be beneficial. Doing a gap analysis is also not a huge amount of work, and the earlier it is done, the quicker it goes.

It might also be useful for civil servants to have material they could add to internal business cases to justify use of the Standard. If an organization has previous experience of standards being costly to implement, this could show that this might not be the case for this one.