2 July 2020 Standard for Public Code community call
Update from the Foundation
- The first Standard compliance analysis has been merged!
- There’s a mailing list for the Standard for Public Code.
Attendees
- Jan Ainali (chair)
- Eric Herman
- Boris van Hoytema
- Alba Roza
- Elena Findley-de Regt
- Laura Scheske
- Jonathan Pichot
- Peter Kuhn
Notes
Introductions
Jonathan and Peter were given an introduction to the Foundation for Public Code and an explanation of codebase stewardship. Rather than attempt to go into details of the Standard for Public Code, they each decided to come back to a Foundation for Public Code community call in the future.
Splitting the Standard for Public Code’s Welcome contributions criterion
Eric explained the background which is mostly captured in the notes from our last community call. Then the draft was shown to everybody and a few minutes were given to just read it through. As a quick improvment the name for the new criterion Supporting easy contributions was changed to Make contributing easy.
We discussed the way the draft had split up the criterion and how governance played in with that. Jan and Elena explained that the thinking behind it was that Welcome Contributions is what you need to build trust, pique interest, provide legibility of leadership and the community goals. In contrast, Make contributing easy is supposed to cover the tools and processes that allows for contributors to find a way into the codebase.
We also agreed on that having a separate governance criterion could be somewhat of a trap. People will tend to build governance in the way that they know how to build governance structures, which is closed. Governance should not be a goal - there shouldn’t be more governance than needed - and since we do recognize some is needed, those requirements should remain but not be given more weight.
With the explaination of the way the criterion was split the group found the requirement about the roadmap to fit better under Welcome contributions.
After changing the header and moving that requirement the consensus was that this was ready to become a pull request.
Create reusable and portable code
With a few minutes left on the call Eric raised the question that the requirement about reuse in the criterion Create reusable and portable code might be hard to meet by codebases developed for state and suprastate purposes. He suggested “The codebase MUST be in use by multiple parties.” should be changed to a SHOULD. Unfortunately there was no time for a deeper discussion during the call so it was decided to continue it in a pull request.