6 August 2020 Standard for Public Code community call

Update from the Foundation

• Changes to the Standard for Public Code: the requirement for a codebase being in use by multiple parties was changed from MUST to SHOULD.
• The Standard gap analysis for OpenZaak has been turned into a to-do list.
• The Signalen project now has a roadmap/workboard for product marketing with several tasks related to Standard requirements.

Attendees

• Alba Roza (chair)
• Jan Ainali
• Eric Herman
• Boris van Hoytema
• Elena Findley-de Regt
• Laura Scheske
• Jonas Claesson (JobTech Swedish Public Employment Office)
• Joeri Bekker (Maykin Media)
• Olaf-Gerd Gemein (SmartCitiesLab)
• Antti Kutas (LUT University)
• Marc van Andel (Kadaster - The Netherlands’ Cadastre, Land Registry and Mapping Agency)

Notes

Question about the requirement change

A question was raised about why we “downgraded” the requirement from MUST to SHOULD. Eric explained that the primary cause was to make it possible for vendors to be able to offer Standard compliant codebases from day 1. This will make it possible to offer work that is Standard compliant without first needing to get other people to use the codebase, allowing a focus on quality. Eric also noted that the SHOULD, as described in IETF RFC 2119, is a “strong” SHOULD and is not to be confused with a weaker MAY.

Translating the Standard into multiple languages

After a brief introduction, we opened the floor to thoughts on the usefulness of translated versions. The first discussion pointed out that a reduced cognitive load when reading the Standard in your native language can make it easier to understand its technical content and resulting benefits. Having to focus on understanding the English version might therefore take away some of the utility that developers/civil servants can gain from working with the Standard. This was echoed by several participants of the call.

Boris highlighted that providing translations comes with a cost, and that the cost increases if they are to be seen as official in some way.

The participants agreed widely that there only needed to be one official version, in English, and that any translations should only be provided as a non-binding helpful service. Machine translations and community crowdsourced translations were suggested as satisfactory solutions.

An important aspect about the traceablility of the translations was raised. Participants discussed that there needs to be clarity on the exact version of the Standard a translation is based on. It was deemed crucial that there should be no confusion about that. There was general agreement that the English version should be the canonical version. Including disclaimers in translated versions that point to the repository of the original English version was proposed as a straightforward solution.

One possible positive side effect of the translations is that they can be a way to create local communities. People who invest in translating will become familiar with the Standard and be more likely to become ambassadors for it. Local community members will increase not only the reach, but also the trustworthiness of the Standard.

Summary

The community call was clear: there is a need for translations but they do not need to be “official”.

The Foundation for Public Code will look into tools that can fit our workflow that will make it possible to provide community translated versions of the Standard for Public Code.