Blog for Public Code

This blogpost

Date:8 June 2022
Author:Jan Ainali

Feed

Subscription feed

Contribute on GitHub

2 June 2022 Standard for Public Code community call notes

Attendees

Updates from the Foundation

Notes

We started by revisiting issue 264 from 2019, which started with a question about discoverability. There was agreement that this aspect is essential, but that it extends to more than just the name. When someone is searching online, they are most likely not using the product name (unless they just came back from a conference or similar where they heard about the codebase). Instead, they’re probably describing the problem they’re trying to solve or the problem space. This may be expressed differently depending on the role of the person searching.

Besides a unique name and basic discoverability, an at least minimal web page would be a good requirement for any codebase that has the ambition to meet the Standard for Public Code and be reused.

Beyond that, it was unclear if any further MUSTs or SHOULDs are needed. MAY requirements could be more encouraging than just guidance since that would give civil servants more justification to do it and also a reward in terms of an additional ticked box.

Many other aspects were discussed, like contact persons, use of metadata standards, software catalogs, social media and domain names. Most of these could be MAY requirements, though we didn’t have sharp suggestions of phrasing during the call, whereas others should probably not be requirements at all. For example, we think that social media may be a suboptimal strategy for communication for a public code codebase.

The similarities to the development of open data were also noted. It has been shown that only creating good metadata was not enough. For it to really be reused, more proactivity is needed and we should be inspired by the open data movement’s experiences.

Taking all this together, there seems to be a need for a new criterion for marketing, which would also make it easier to write guidance for the requirements compared to slotting these into the existing criteria. Having detailed guidance for the different roles (policymakers, managers, developers and designers) was deemed to be essential for success. Some existing requirements may also fit more naturally under the new criterion.

The next step will be to create a draft for a full criterion to move the discussion forward.