<?xml version="1.0" encoding="utf-8"?><feed xmlns="http://www.w3.org/2005/Atom" ><generator uri="https://jekyllrb.com/" version="3.9.5">Jekyll</generator><link href="https://blog.publiccode.net/feed.xml" rel="self" type="application/atom+xml" /><link href="https://blog.publiccode.net/" rel="alternate" type="text/html" /><updated>2024-04-28T20:04:47+00:00</updated><id>https://blog.publiccode.net/feed.xml</id><title type="html">Blog for Public Code</title><subtitle>Home to the Blog for Public Code, where blog posts are planned and collectively written.</subtitle><entry><title type="html">Notes from the Standard for Public Code community call - 26 March 2024</title><link href="https://blog.publiccode.net/community%20call/2024/03/27/notes-from-community-call-26-march-2024.html" rel="alternate" type="text/html" title="Notes from the Standard for Public Code community call - 26 March 2024" /><published>2024-03-27T00:00:00+00:00</published><updated>2024-03-27T00:00:00+00:00</updated><id>https://blog.publiccode.net/community%20call/2024/03/27/notes-from-community-call-26-march-2024</id><content type="html" xml:base="https://blog.publiccode.net/community%20call/2024/03/27/notes-from-community-call-26-march-2024.html"><![CDATA[<h1 id="26-march-2024-standard-for-public-code-community-call">26 March 2024 Standard for Public Code community call</h1>

<h2 id="attendees">Attendees</h2>

<ul>
  <li><a href="https://publiccode.net/who-we-are/team/jan-ainali.html">Jan Ainali</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/eric-herman.html">Eric Herman</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/claus-mullie.html">Claus Mullie</a></li>
  <li>Nico Rikken</li>
  <li><a href="https://jgroenen.nl">Johan Groenen</a></li>
  <li>Silona Bonewald, Foundation for Public Code NA, OSPO Alliance, Os-Gov at Eclipse Foundation</li>
  <li>Maria Dalhage, Swedish Public Employment Service and Community manager <a href="https://nosad.se">NOSAD</a></li>
  <li>Ian Forrester</li>
  <li>Boris Baldassari, Eclipse Foundation</li>
  <li>Matti Schneider</li>
  <li>Joakim Verona, Swedish Public Employment Service</li>
  <li><a href="https://publiccode.net/who-we-are/team/max-carlson.html">Max Carlson</a></li>
  <li>Nick Gates</li>
  <li>Jonas Södergren, Swedish Public Employment Service</li>
</ul>

<h2 id="updates-from-the-foundation">Updates from the Foundation</h2>

<ul>
  <li><a href="https://blog.publiccode.net/news/2024/02/28/changes-at-the-europe-office.html">The European office is winding down</a></li>
</ul>

<h2 id="notes">Notes</h2>

<h3 id="background">Background</h3>

<p>We have planned for a long time to evolve the governance of the Standard for Public Code towards a more community maintained codebase.
In light of the European office winding down (see above) we are speeding up that effort.</p>

<h3 id="discussion">Discussion</h3>

<p>The call opened with the question: <em>What would be some important governance aspects for you to feel empowered to continue to use and feel inspired to contribute to and consider to help maintain the Standard for Public Code?</em>
Some values that were mentioned were transparency, openness, meritocracy and neutrality.
It was also mentioned that it would be nice to not have to bootstrap the governance, rather, stepping in to some existing framework would be better.
Another point that was made was that creating, and “staffing”, an executive body from the start, rather than just publishing a GOVERNANCE file, would make a tremendous difference.
Some also expressed it to be essential that people with historical knowledge of maintaining the Standard for Public Code to be part of this executive body.
It was also highlighted that the members of this executive body are funded for their time somehow, possibly by having their organizations making a commitment to help maintain the Standard for Public Code.</p>

<p>As a separate point to raise the importance of active maintainers, that it is utterly important that they exist, it was agreed that: “a dead document is not authoritative”.</p>

<p>Some participants of the meeting expressed interest in becoming co-maintainers of the Standard for Public Code, including the Swedish Public Employment Service.
Obviously, of course, pending final details of the governance.</p>

<p>The OSPO alliance kindly offered to provide infrastructure for the continued work.
Luckily, the existing infrastructure will continue to exist, so there is no urgent need of that to date.</p>

<p>Besides the governance question, it was expressed that continued knowledge sharing between users of the Standard is important.
Partly, the <a href="https://standard-for-public-code.github.io/community-implementation-guide-standard/">Community built companion</a> can solve this already, by being a place to share good ways of implementing the Standard for Public Code.
Similarly, a wish for the community to help disseminating the Standard for Public Code and showing good examples was expressed.
Also there the Community built companion could be a solution, not to mention the <a href="https://standard-compliant.publiccode.net/">list of codebases that are compliant</a>.
For the rest, using <a href="https://lists.publiccode.net/mailman/postorius/lists/standard.lists.publiccode.net/">the mailing list</a> to share knowledge and examples might be a good start.</p>

<p>Quite a lot of the call was spent on ideas for finding funding for the Foundation for Public Code to maintain the Standard for Public Code.
Some of the ideas that was discussed was:</p>

<ul>
  <li>Trainings</li>
  <li>Certification</li>
  <li>Grants</li>
  <li>Consultancy</li>
  <li>Donations (mostly state/towns/users of the standard)</li>
</ul>

<p>There was also some self reflection made: that no public organization is yet using the Standard for Public Code as an internal measurement and thus is not a critical path.
This was not exactly refuted, but one counter point was that as public organizations like standards (“If we don’t create them, they will legislate them.”), it still has value as an argument in discussions.
Also, as there is no blueprint for open projects and the Standard for Public Code shows how it could be done, that is a value in itself.
“The structure may be more important than full compliance.”</p>

<h2 id="next-steps">Next steps</h2>

<p>We will finalize a new GOVERNANCE file based on the feedback from this call and from people giving input beforehand.
Thank you all for your valuable viewpoints.</p>

<p>This will be done together with the organizations that during the meeting and separately have stated the intentions to commit person hours to do this work and be part of an executive body.</p>

<p>In order to empower this executive body to have full control over the repository and the path forward, it will be transferred to a new GitHub repository with these people as owners.</p>]]></content><author><name>Jan Ainali</name><uri>https://publiccode.net/who-we-are/team/jan-ainali.html</uri></author><category term="Community call" /><summary type="html"><![CDATA[Moving the Standard for Public Code towards community governance]]></summary></entry><entry><title type="html">Episode sixteen of Let’s talk about public code! - Liv Marte Nordhaug, Digital Public Goods Alliance</title><link href="https://blog.publiccode.net/news/2024/03/12/episode-sixteen-of-lets-talk-about-public-code.html" rel="alternate" type="text/html" title="Episode sixteen of Let’s talk about public code! - Liv Marte Nordhaug, Digital Public Goods Alliance" /><published>2024-03-12T00:00:00+00:00</published><updated>2024-03-12T00:00:00+00:00</updated><id>https://blog.publiccode.net/news/2024/03/12/episode-sixteen-of-lets-talk-about-public-code</id><content type="html" xml:base="https://blog.publiccode.net/news/2024/03/12/episode-sixteen-of-lets-talk-about-public-code.html"><![CDATA[<h1 id="episode-sixteen-of-lets-talk-about-public-code">Episode sixteen of Let’s talk about public code!</h1>

<p>In this sixteenth episode, we are joined by Liv Mart Nordhaug, the Chief Executive Officer of the Digital Public Goods Alliance. We will delve into the core functions of the Alliance, explain the criteria and process for recognizing digital public goods (DPGs), and explore the profound impact of the open source ethos on digital innovation. From the 50-in-5 initiative to the ambitious goal of making DPGs the norm for addressing urgent global challenges by 2028, this episode promises an enlightening journey into the future of digital innovation and collaboration.</p>

<iframe width="640" height="166" scrolling="no" frameborder="no" src="https://open.audio/embed.html?&amp;type=track&amp;id=415025"></iframe>

<p>Links related to the discussion:</p>

<ul>
  <li><a href="https://digitalpublicgoods.net/">Digital Public Goods Alliance</a></li>
  <li><a href="https://digitalpublicgoods.net/registry/">Digital Public Goods Registry</a></li>
  <li><a href="https://50in5.net/">50-in-5 campaign</a></li>
</ul>

<p>You can subscribe to the podcast at <a href="https://open.audio/@publiccode@open.audio">open.audio</a> or by searching in your favorite podcast app.</p>

<p><a href="https://www.youtube.com/watch?v=CNcuJqgS_UI&amp;list=PL_5ziu2gADmBPPsDlo4sMt1M7Yd8LvOBK&amp;index=16"><img src="https://blog.publiccode.net/assets/screenshot-episode-16.png" alt="Screenshot from the video with Liv, Eric and Jan" /></a>
Above, screenshot from <a href="https://www.youtube.com/watch?v=CNcuJqgS_UI&amp;list=PL_5ziu2gADmBPPsDlo4sMt1M7Yd8LvOBK&amp;index=16">the recording</a>.</p>]]></content><author><name>Jan Ainali</name><uri>https://publiccode.net/who-we-are/team/jan-ainali.html</uri></author><category term="news" /><summary type="html"><![CDATA[All about Digital Public Goods]]></summary></entry><entry><title type="html">Changes at the Foundation for Public Code Europe office</title><link href="https://blog.publiccode.net/news/2024/02/28/changes-at-the-europe-office.html" rel="alternate" type="text/html" title="Changes at the Foundation for Public Code Europe office" /><published>2024-02-28T00:00:00+00:00</published><updated>2024-02-28T00:00:00+00:00</updated><id>https://blog.publiccode.net/news/2024/02/28/changes-at-the-europe-office</id><content type="html" xml:base="https://blog.publiccode.net/news/2024/02/28/changes-at-the-europe-office.html"><![CDATA[<h1 id="changes-at-the-foundation-for-public-code-europe-office">Changes at the Foundation for Public Code Europe office</h1>

<p>We are winding down the current composition of the European office of the Foundation for Public Code, because our existing financial model has not proved to be sustainable.</p>

<p>All of the full-time staff associated with our European office are being laid off.
We are extremely grateful for their contributions and look forward to potentially working with them in other capacities in the future.</p>

<p>The North American chapter of the Foundation for Public Code will continue to move forward with an expanding set of project-based initiatives and collaborations with public administrations.
Additionally, the Foundation will continue to participate in policy conversations around the growing ecosystem of codebase stewardship organizations at the European level.</p>

<h2 id="challenges-along-the-way">Challenges along the way</h2>

<p>We had initially built our organizational structure following a Linux Foundation model, including having the capacity to steward codebases and communities within our organization.
We asked public administrations to become members of our association, becoming part owners of the Foundation which would function as an external entity that worked closely with internal departments to create sustainable codebases through modern software practices and communities of practice.
Thanks specifically to Provincie Zuid-Holland in the Netherlands for becoming our first official member!
And to the public sector codebase communities who were eager to meet the Standard and enter into stewardship with us.
And to everyone we met along the way who told us this was forward-thinking and necessary.</p>

<p>But despite the enthusiasm and support we encountered, that approach has not worked. Our membership model was not viable.
Participation as a member in this type of association was too risky for public administrations.
They could not afford to be part owner of an entity which they did not have sufficient control over.
Additionally, as we began to work internationally, it became clear that non-Dutch public administrations could not legally even join as a member a body governed by rules of a state outside of their own sovereign jurisdiction.
As these limitations became more defined, we attempted to transform our financial and governance models, but we weren’t fast enough to achieve sustainability for our full team.
We also dedicated substantial energy to raising funds via institutional philanthropy, but much of this funding is focused on specific causes, rather than on capacity building and process transformation in the public sector.</p>

<p>Of course the pandemic did not help.
Many of the government technology teams we were initially working with rightly refocused on rapidly developing responses to devastating national public health crises and damaged national economies, without much bandwidth to think about the longer term issues that stewardship practices represent.</p>

<h2 id="maturing-public-sector-open-source-ecosystem">Maturing public sector open source ecosystem</h2>

<p>There are also some quite positive reasons why it makes sense for us to adjust the composition of the Foundation for Public Code.
The perspective in public administrations toward taking active responsibility in procuring and stewarding their own digital projects has evolved faster than we initially anticipated.
There is now a growing movement among European governments toward creating an Open Source Program Office within their organizations, which is a strategy we have long advocated for globally and championed among our members and partners.
We are a proud founding member of the OSPO Alliance and have worked with OSPO++ on projects in the European Commission and the United Nations.
One of our co-founders has even gone on to become the founder of the first OSPO at a Dutch national ministry.
As these initiatives internal to government become more resourced and develop capacity, it is less necessary for the Foundation for Public Code to develop external networks within the open source community on behalf of once insular public organizations.</p>

<h2 id="looking-to-the-future">Looking to the future</h2>

<p>The North American chapter of the Foundation will continue to engage with the multiple projects and communities of practice it is moving forward, and participate in the developing policy discourse there.</p>

<p>In the European policy context, the Foundation will continue to be involved in multiple conversations and working groups at the European level and in multi-stakeholder frameworks focused on the creation and sustainable development of Open Source Program Office capabilities and the creation of non-profit organizational vehicles for collaboration around digital public goods.
We will continue our collaboration with the Digital Public Goods Alliance, Open Futures, and Open Forum Europe, among others.
Our Advisory Board will continue to provide strategic guidance.</p>

<p>Based on potential forthcoming grant-based project awards, the Foundation will continue to collaborate with our network of trusted experts on projects towards building capacity in the public sector and creating codebase governance and stewardship organizational structures for digital public goods.</p>

<p>We’re also working to build a distributed community of practice for the Standard for Public Code.
We hope to support and assist this network of maintainers and other experts in shepherding the Standard to 1.0, in line with the goal agreed in recent community calls.</p>

<p>The Foundation for Public Code’s role in the ecosystem of digital public goods must evolve.
We have worked hard on moving the awareness and practice of codebase stewardship and governance forward and have seen positive results.
There will be more news about this transformation in our future posts, but for now we would like to honor the enormous contributions and efforts of the collection of talented and hard-working individuals that are the outgoing employees of the European office of the Foundation for Public Code.</p>

<p><img src="https://blog.publiccode.net/assets/lessons-learned.png" alt="Europe office in a grid" /></p>

<p>Thank you so much Claus, Elena, Eric, Jan, and Kehinde.</p>

<p>Ben Cerveny,</p>

<p>President</p>]]></content><author><name>Ben Cerveny</name><uri>https://publiccode.net/who-we-are/team/ben-cerveny.html</uri></author><category term="News" /><summary type="html"><![CDATA[Staff are being let go]]></summary></entry><entry><title type="html">Episode fifteen of Let’s talk about public code! - Astor Nummelin, Open Forum Europe</title><link href="https://blog.publiccode.net/news/2024/01/30/episode-fifteen-of-lets-talk-about-public-code.html" rel="alternate" type="text/html" title="Episode fifteen of Let’s talk about public code! - Astor Nummelin, Open Forum Europe" /><published>2024-01-30T00:00:00+00:00</published><updated>2024-01-30T00:00:00+00:00</updated><id>https://blog.publiccode.net/news/2024/01/30/episode-fifteen-of-lets-talk-about-public-code</id><content type="html" xml:base="https://blog.publiccode.net/news/2024/01/30/episode-fifteen-of-lets-talk-about-public-code.html"><![CDATA[<h1 id="episode-fifteen-of-lets-talk-about-public-code">Episode fifteen of Let’s talk about public code!</h1>

<p>In this fifteenth episode, we talked to Astor Nummelin, Executive Director at Open Forum Europe about how software is getting to a point that it is becoming institutionalised and what we can do in light of this.</p>

<iframe title="#15 Astor Nummelin - Open forum Europe" width="640" height="166" scrolling="no" frameborder="no" src="https://open.audio/embed.html?&amp;type=track&amp;id=413838"></iframe>

<p>Links related to the discussion:</p>

<ul>
  <li>Blogpost: <a href="https://openforumeurope.org/some-thoughts-on-the-institutionalisation-of-software/">Some Thoughts on the Institutionalisation of Software</a></li>
  <li><a href="https://openforumeurope.org">Open Forum Europe</a></li>
</ul>

<p>You can subscribe to the podcast at <a href="https://podcast.publiccode.net/e/lets-talk-about-public-code-15-astor-nummelin-open-forum-europe/">podcast.publiccode.net</a> or by searching in your favorite podcast app.</p>

<p><a href="https://www.youtube.com/watch?v=bhw1P4Pl8AQ&amp;list=PL_5ziu2gADmBPPsDlo4sMt1M7Yd8LvOBK&amp;index=15"><img src="https://blog.publiccode.net/assets/screenshot-episode-15.png" alt="Screenshot from the YouTube video with Astor and Jan" /></a>
Above, screenshot from <a href="https://www.youtube.com/watch?v=bhw1P4Pl8AQ&amp;list=PL_5ziu2gADmBPPsDlo4sMt1M7Yd8LvOBK&amp;index=15">YouTube</a>.</p>

<h2 id="whats-next">What’s next?</h2>

<p>We are aiming for the next video within a month.
If you have any suggestions for public coders we should talk to in the future, reach out to us on social media or create <a href="https://github.com/publiccodenet/projects/issues/new">an issue in our Projects repository</a>.</p>]]></content><author><name>Jan Ainali</name><uri>https://publiccode.net/who-we-are/team/jan-ainali.html</uri></author><category term="news" /><summary type="html"><![CDATA[On institutionalisation of software]]></summary></entry><entry><title type="html">Episode fourteen of Let’s talk about public code! - Åsa Jagre and Konstantin Ay, Jitsi Outlook plugin</title><link href="https://blog.publiccode.net/news/2023/12/18/episode-fourteen-of-lets-talk-about-public-code.html" rel="alternate" type="text/html" title="Episode fourteen of Let’s talk about public code! - Åsa Jagre and Konstantin Ay, Jitsi Outlook plugin" /><published>2023-12-18T00:00:00+00:00</published><updated>2023-12-18T00:00:00+00:00</updated><id>https://blog.publiccode.net/news/2023/12/18/episode-fourteen-of-lets-talk-about-public-code</id><content type="html" xml:base="https://blog.publiccode.net/news/2023/12/18/episode-fourteen-of-lets-talk-about-public-code.html"><![CDATA[<h1 id="episode-fourteen-of-lets-talk-about-public-code">Episode fourteen of Let’s talk about public code!</h1>

<p>In this fourteenth episode, we talked to Åsa Jagre at the Swedish Agency for Marine and Water Management and Konstantin Ay from Intunio working on a Jitsi plugin for Outlook. We focused on up-stream first development and code collaboration.</p>

<p>Unfortunately, Åsa had a bad cough, so we are reading her messages from chat in the interview.</p>

<iframe title="#14 - Åsa Jagre and Konstantin Ay, Jitsi Outlook plugin" width="640" height="166" scrolling="no" frameborder="no" src="https://open.audio/embed.html?&amp;type=track&amp;id=413837"></iframe>

<p>Links mentioned in the show:</p>

<ul>
  <li><a href="https://github.com/diggsweden/jitsi-outlook/">Jitsi-Outlook plugin</a></li>
  <li><a href="https://github.com/diggsweden/open-source-project-template">Open Source Project Template</a></li>
  <li><a href="https://github.com/diggsweden/asom-docs">asom collaboration</a></li>
</ul>

<p>You can subscribe to the podcast at <a href="https://podcast.publiccode.net/e/14-asa-jagre-and-konstantin-ay-jitsi-outlook-plugin/">podcast.publiccode.net</a> or by searching in your favorite podcast app.</p>

<p><a href="https://www.youtube.com/watch?v=GK_iQWzsZLM"><img src="https://blog.publiccode.net/assets/screenshot-episode-14.png" alt="Konstantin, Åsa, Eric and Jan chatting in a video chat grid" /></a></p>

<h2 id="where-can-i-find-the-video">Where can I find the video?</h2>

<p>The video is available in a number of places:</p>

<ul>
  <li><a href="https://www.youtube.com/watch?v=GK_iQWzsZLM">YouTube</a></li>
  <li><a href="https://twitter.com/publiccodenet/status/1734951397416911333">Twitter</a></li>
  <li><a href="https://www.facebook.com/publiccodenet/videos/721203043264791">Facebook</a></li>
  <li><a href="https://www.linkedin.com/events/let-stalkaboutpubliccode-14-saj7138479369580146688/theater/">LinkedIn</a></li>
</ul>

<h2 id="whats-next">What’s next?</h2>

<p>We aim to be back early next year year.
If you have any suggestions for public coders we should talk to in the future, reach out to us on social media or create <a href="https://github.com/publiccodenet/projects/issues/new">an issue in our Projects repository</a>.</p>]]></content><author><name>Jan Ainali</name><uri>https://publiccode.net/who-we-are/team/jan-ainali.html</uri></author><category term="news" /><summary type="html"><![CDATA[Upstream-first and collaboration in the newest episode of our podcast]]></summary></entry><entry><title type="html">Notes from the Standard for Public Code community call - 7 December 2023</title><link href="https://blog.publiccode.net/community%20call/2023/12/11/notes-from-community-call-7-december-2023.html" rel="alternate" type="text/html" title="Notes from the Standard for Public Code community call - 7 December 2023" /><published>2023-12-11T00:00:00+00:00</published><updated>2023-12-11T00:00:00+00:00</updated><id>https://blog.publiccode.net/community%20call/2023/12/11/notes-from-community-call-7-december-2023</id><content type="html" xml:base="https://blog.publiccode.net/community%20call/2023/12/11/notes-from-community-call-7-december-2023.html"><![CDATA[<h1 id="7-december-2023-standard-for-public-code-community-call">7 December 2023 Standard for Public Code community call</h1>

<h2 id="attendees">Attendees</h2>

<ul>
  <li><a href="https://publiccode.net/who-we-are/team/jan-ainali.html">Jan Ainali</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/eric-herman.html">Eric Herman</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/elena-findley-de-regt.html">Elena Findley-de Regt</a></li>
  <li>Matti Schneider</li>
</ul>

<h2 id="updates-from-the-foundation">Updates from the Foundation</h2>

<ul>
  <li>We’ll be running <a href="https://blog.publiccode.net/news/2023/11/13/fosdem-2024-public-code-and-digital-public-goods-devroom-call-for-proposal.html">a devroom at FOSDEM 2024</a> together with the <a href="https://digitalpublicgoods.net/">Digital Public Goods Alliance</a></li>
  <li>We completed an assessment of <a href="https://wekan.github.io/standard-for-public-code/">Wekan</a></li>
</ul>

<h2 id="notes">Notes</h2>

<h3 id="background">Background</h3>

<p>In the <a href="https://standard.publiccode.net/">Standard for Public Code</a>, we have <a href="https://standard.publiccode.net/criteria/use-plain-english.html#requirements">a requirement about translations</a> stating “Any translation MUST be up to date with the English version and vice versa.”.
However, many open source projects have community contributed translations, and it is obviously not the intention of the standard to discourage this.</p>

<p>Therefore, we created a <a href="https://github.com/publiccodenet/standard/pull/999">proposal for change</a> to address this.</p>

<p>During the call we discussed this proposal and what it implies.
One important observation was that it may not matter whether it is the maintainers doing the translations or the community.
Rather, it would be better to use terms like authoritative translations - for translations the maintainers have committed to - and courtesy translations, for community contributed or automatic machine translations.
Even during the call, some suggestions to the pull request were made to this effect.</p>

<p>One aspect of it that also was mentioned is a contributor’s expectations around translations.
It was proposed that the documentation should be clear that missing authoritative translations would block a contribution from being merged into a release.
This is essentially the same in practice, but approaches it from a different angle.
In the end, the first angle was favored.</p>

<p>Following from this we should update the ‘what developers need to do’ sections to be clear about which translations are authoritative or courtesy.</p>

<p>While we were on the topic of language, we also discussed the first requirement “All codebase documentation MUST be in English.”.</p>

<p>This does not mean it must be only in English; it can have complementary translations or summaries in other languages (even in the same file).
They can even be leading, but there must be an authoritative version in English.
Making this more clear could make people less hesitant about the standard, both for practical and political reasons.</p>

<p>We also discussed the tricky quesion of how to make clear what version the documentation is for.
However, we thought that there is not enough widespread best practices out there to crystalize it into requirements.
Possibly, we could make an issue on the implementation guide to add those who are doing good work as examples.</p>

<p>We also noted that requirement  “All bundled policy not available in English MUST have an accompanying summary in English.” often takes us time to explain during assessments, so it could possibly be clarified more, but we didn’t immediately have ideas on how to do it.</p>

<p>The next community call for the Standard for Public Code will be 1 February 2024, 14.00 UTC+1.</p>]]></content><author><name>Jan Ainali</name><uri>https://publiccode.net/who-we-are/team/jan-ainali.html</uri></author><category term="Community call" /><summary type="html"><![CDATA[Clarifying about different types of translations]]></summary></entry><entry><title type="html">How to be a good codebase contributor as a public organization</title><link href="https://blog.publiccode.net/codebase%20stewardship/2023/11/20/good-public-contributor.html" rel="alternate" type="text/html" title="How to be a good codebase contributor as a public organization" /><published>2023-11-20T00:00:00+00:00</published><updated>2023-11-20T00:00:00+00:00</updated><id>https://blog.publiccode.net/codebase%20stewardship/2023/11/20/good-public-contributor</id><content type="html" xml:base="https://blog.publiccode.net/codebase%20stewardship/2023/11/20/good-public-contributor.html"><![CDATA[<h1 id="how-to-be-a-good-codebase-contributor-as-a-public-organization">How to be a good codebase contributor as a public organization</h1>

<p>Increasingly, as public organizations mature in their digitization efforts, they tend to adopt policies of preferentually contributing to existing open source codebases rather than creating yet another codebase from scratch.
A while back, we even got a question about what a public organization needs to think about as a contributor to existing open source codebases.
That made us pause for a bit, as previously we had mostly been asked to help public organizations make their own codebases open or ready for collaboration.</p>

<p>The <a href="https://standard.publiccode.net">Standard for Public Code</a> does not cover the aspect of being a contributor explicitly.
Instead, it focuses on the existing community and how they can welcome more contributors.
We realized there might be a knowledge gap to fill.</p>

<p><img src="https://illustrations.publiccode.net/illustrations/service-3.svg" alt="illustration of a purple hand holding holding a heart with containing HTML code symbols, against a peach background" /></p>

<p>There are many contribution guides out there, and the <a href="https://github.com/freeCodeCamp/how-to-contribute-to-open-source">FreeCodeCamp has collected a fairly comprehensive list</a> of them.
This is a good start for anyone that wants to be a helpful contributor.
You’ll see there are a lot on the list, but the one-line descriptions will help select the ones of interest.</p>

<p>Additionally, we find these to be particularly useful if you’re contributing on behalf of a larger organization:</p>

<ul>
  <li><a href="https://todogroup.org/resources/guides/participating-in-open-source-communities/">Participating in Open Source Communities</a> from the TODO Group - shines a light on how to be a good corporate citizen, which is quite similar to what being a good contributor as a public organization involves.</li>
  <li><a href="https://joinup.ec.europa.eu/collection/open-source-observatory-osor/guidelines-creating-sustainable-open-source-communities">Guidelines for creating sustainable open source communities</a> by the Open Source Observatory at the European Commission - helps you understand, and interact with, existing codebase communities.</li>
  <li><a href="https://archive.fosdem.org/2020/schedule/event/enterpriseoss/">Engaging Enterprise consumers of OSS - Enterprise contribution, participation, and support of OSS</a> by Jacob Redding at FOSDEM 2020 - this has poor sound for the first several minutes but also some interesting ideas on how an organization can contribute to a codebase with clarity around its intent.</li>
</ul>

<p>Together, these guides cover most aspects that any large organization should consider when contributing to an open source project, so we thought that writing one more guide wouldn’t be that helpful.
However, for a contributor representing a public organization, it’s even more important to give maintainers the right expectations about the organization’s current and future involvement, including:</p>

<ul>
  <li>Your organization’s current scale of commitment. What is your headcount or budget?</li>
  <li>What is your organization’s ability to participate in the future maintenance of the contribution?</li>
  <li>How formalized is your involvement? Is there specific support from policy and or management? Or are you in a situation such that if the role of one engaged contributor changes, the involvement may dry up?</li>
  <li>What is the expected duration of your contributors? Are the contributors from your organization short term contractors or embedded experts with long term contracts?</li>
  <li>Will your contributors be paid to gain depth and become reviewers over time?</li>
  <li>What policy objectives, if any, are being addressed by your participation or contributions, for example adding GDPR compliance, or accessibility requirements, or a feature that was a political campaign promise?</li>
  <li>The goals and aspirations of your organization. Do you plan further contributions already, and if so, of what kind? How are you using the codebase, and what is your scale of deployment/implementation?</li>
  <li>How is your orgainzation able to contribute? Code and documentation contributions are great, but many open source communities can also benefit from other forms of support, including community management, financing, help with governance, marketing, endorsements, and so on.</li>
</ul>

<p>These points may not really fit in to a pull request, so you might want to consider starting a separate discussion in a place where the community is having their discussions (which might be something like a forum, chat or mailing list).
Naturally, the importance of being clear about these points increases with the size of your contribution - if you just fix a small bug, then of course this would be excessive.</p>

<p>Healthy open source codebases have a great diversity in their communities and public organizations are likely to be seen as valuable contributors by maintainers, especially as they are uniquely positioned to engage on very long time scales.</p>

<p>Good luck contributing!</p>]]></content><author><name>Eric Herman, Jan Ainali</name></author><category term="Codebase stewardship" /><summary type="html"><![CDATA[For contributors representing public organizations, it's even more important to give maintainers the right expectations]]></summary></entry><entry><title type="html">FOSDEM 2024 Public Code and Digital Public Goods devroom Call for Participation</title><link href="https://blog.publiccode.net/news/2023/11/13/fosdem-2024-public-code-and-digital-public-goods-devroom-call-for-proposal.html" rel="alternate" type="text/html" title="FOSDEM 2024 Public Code and Digital Public Goods devroom Call for Participation" /><published>2023-11-13T00:00:00+00:00</published><updated>2023-11-13T00:00:00+00:00</updated><id>https://blog.publiccode.net/news/2023/11/13/fosdem-2024-public-code-and-digital-public-goods-devroom-call-for-proposal</id><content type="html" xml:base="https://blog.publiccode.net/news/2023/11/13/fosdem-2024-public-code-and-digital-public-goods-devroom-call-for-proposal.html"><![CDATA[<h1 id="fosdem-2024-public-code-and-digital-public-goods-devroom-call-for-participation">FOSDEM 2024 Public Code and Digital Public Goods devroom Call for Participation</h1>

<p>We are happy to announce that the call for participation in the <a href="https://fosdem.org/2024/">FOSDEM 2024</a> devroom for Public Code and <a href="https://digitalpublicgoods.net/registry">Digital Public Goods</a> has opened.</p>

<p>It’s a devroom dedicated to everyone developing public code - open source code that implements public policy, used for the public good, and by public organizations like governments, public administrations and state corporations.
Digital public goods (DPGs) are open-source software, open standards, open data, open AI systems, and open content collections that help meet the Sustainable Development Goals.</p>

<p>The devroom will take place on Saturday, 3 February 2024 in Brussels.</p>

<p>We’re looking for contributions that fit within the main theme of the devroom. Below are some questions to inspire your proposal:</p>

<ul>
  <li>have you tried to replicate or co-develop a codebase with another public organization? what did you learn along the way?</li>
  <li>do you have any procurement or governance models (or hacks!) that helped you use, reuse or co-develop public code or a digital public good?</li>
  <li>are you working on or using an amazing DPG or public code project with strong reuse potential that everyone should know about?</li>
</ul>

<p>If you have another idea for a talk that you think would fit, please don’t hesitate to let us know!
We hope that this will be an opportunity for everyone to meet and exchange ideas about public code and digital public goods around the world.</p>

<p>We offer two types of talk slots:</p>

<ul>
  <li>30 minutes (20 minutes presentation + 10 minutes Q&amp;A)</li>
  <li>5 minute lightning talks, perfect for presenting your project, but other lightning talk topics are also welcome!</li>
</ul>

<p>Please specify in the Submission notes field which type you’re applying for.</p>

<p>We welcome submissions from projects that have never been to FOSDEM before, as well as from ‘old timers’.</p>

<h2 id="submission-process">Submission process</h2>

<p>Please <a href="https://pretalx.fosdem.org/fosdem-2024/cfp">submit your proposals</a> before <strong>1 December 2023</strong>.</p>

<ul>
  <li>Head to the FOSDEM 2024 pretalx website. This has replaced Pentabarf!</li>
  <li>Follow the instructions to create an account.</li>
  <li>Once logged in, select “submit a CFP”.</li>
  <li>Your submission must include the following information:
    <ul>
      <li>Proposal title</li>
      <li>Track - Select Public Code and Digital Public Goods from the drop down list</li>
      <li>Abstract (will appear on the FOSDEM schedule)</li>
      <li>Description  (will appear on the FOSDEM schedule)</li>
      <li>Submission notes - Write if you want to give a Lightning talk or Presentation here. Add any other details as needed.</li>
      <li>Session Image (optional new feature): Use this if you want an illustration to go with your proposal. Please do not upload files larger than 10.0 MB!</li>
      <li>Additional speaker</li>
      <li>Click Continue or you can save and come back to it</li>
      <li>About your proposal: Which open source license do you use?
        <ul>
          <li>FOSDEM is an open-source software conference, please specify which OSI approved license your proposal uses.</li>
        </ul>
      </li>
      <li>Extra review material, only shown to reviewers (not published when scheduled)</li>
      <li>Extra Contact details (optional)</li>
      <li>Click Continue or you can save and come back to it</li>
      <li>Finally, tell us your name</li>
      <li>Biography</li>
      <li>Availability</li>
    </ul>
  </li>
</ul>

<h2 id="important-dates">Important dates</h2>

<ul>
  <li>1 December 2023: deadline for submission of proposals</li>
  <li>15 December 2023 or before: announcement of final schedule</li>
  <li>3 February 2024: devroom day - You must be available in person to present your talk</li>
</ul>

<h2 id="recordings">Recordings</h2>

<p>The talks are usually recorded on-site. Any recordings will be published under the same license as all FOSDEM content (CC-BY). By agreeing to present in the Public Code and Digital Public Goods devroom, you automatically give permission to be recorded.</p>

<p><img src="https://brand.publiccode.net/logo/mark.svg" alt="Foundation for Public Code logo" height="100px" />     
<img src="https://blog.publiccode.net/assets/DPGA.png" alt="DPGA logo" height="100px" /></p>

<p>/ Foundation for Public Code and <a href="https://digitalpublicgoods.net/">Digital Public Goods Alliance</a>, co-organizers of the devroom</p>]]></content><author><name>Jan Ainali</name><uri>https://publiccode.net/who-we-are/team/jan-ainali.html</uri></author><category term="News" /><summary type="html"><![CDATA[Come talk at our FOSDEM track!]]></summary></entry><entry><title type="html">Notes from the Standard for Public Code community call - 2 November 2023</title><link href="https://blog.publiccode.net/community%20call/2023/11/06/notes-from-community-call-2-november-2023.html" rel="alternate" type="text/html" title="Notes from the Standard for Public Code community call - 2 November 2023" /><published>2023-11-06T00:00:00+00:00</published><updated>2023-11-06T00:00:00+00:00</updated><id>https://blog.publiccode.net/community%20call/2023/11/06/notes-from-community-call-2-november-2023</id><content type="html" xml:base="https://blog.publiccode.net/community%20call/2023/11/06/notes-from-community-call-2-november-2023.html"><![CDATA[<h1 id="2-november-2022-standard-for-public-code-community-call">2 November 2022 Standard for Public Code community call</h1>

<h2 id="attendees">Attendees</h2>

<ul>
  <li><a href="https://publiccode.net/who-we-are/team/jan-ainali.html">Jan Ainali</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/eric-herman.html">Eric Herman</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/elena-findley-de-regt.html">Elena Findley-de Regt</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/ben-cerveny.html">Ben Cerveny</a></li>
  <li>Rachel Lawson</li>
  <li>Matti Schneider</li>
  <li>Abhijay Jain</li>
  <li>Marco</li>
</ul>

<h2 id="updates-from-the-foundation">Updates from the Foundation</h2>

<ul>
  <li>We now have a <a href="https://github.com/standard-for-public-code/standard-for-public-code/releases/download/0.7.1/standard-checklist-folded-0.7.1.pdf">folded one-page checklist</a> in the Standard with all 111 requirements.</li>
  <li>The Open Source Project Template is <a href="https://publiccode.net/codebases/open-source-project-template.html">now in incubation</a>.</li>
</ul>

<h2 id="notes">Notes</h2>

<h3 id="background">Background</h3>

<p>We have long thought that to be able to say that the Standard for Public Code is production ready, it should be in use for at least a couple of codebases that meet all the criteria. This would validate that the requirements are proven in practice to be good.
We have talked about this in a <a href="/community%20call/2022/07/07/notes-from-community-call-7-july-2022.html">previous community call</a> and made a <a href="https://github.com/publiccodenet/standard/blob/develop/docs/roadmap.md">note in the roadmap</a> about it.
When talking about applying to become an ISO standard in <a href="/community%20call/2023/10/09/notes-from-community-call-5-october-2023.html">last month’s community call</a>, this naturally became worth reviewing again.</p>

<h3 id="notes-1">Notes</h3>

<p>First we talked a bit about what maturity might mean for a standard and when it could be too early to call it production ready.
As mentioned in the background, we aimed for it to be used by at few codebases first, and formalizing that in an ambition might radiate proper intent to others.
It was also suggested that, ideally, one would even leave some time after the codebases fully comply without requirements being changed or revoked to ensure that they were formulated well enough .</p>

<p>Secondly, we came in to a meta question of why even aim for a version 1.0 release.
While the number is not critical per se, it is a strong signal, especially when adhering to semantic versioning, that a product is ready to be used.
So there is no external pressure, but more of a wish from the community to be clear about what stage the Standard for Public Code is at.
This also led into a subdiscussion about how to apply semantic versioning for a standard in terms of defining what its public API is.
We think this aspect is already addressed, but may follow up with more documentation on our thoughts about that, and if it seems to have some general value, also publish a blog post.</p>

<p>Another aspect we discussed was more technical thresholds for moving it into 1.0.
For example, it might be useful to look at a 1.0 release in terms of what we <em>don’t</em> want in there.
By that we meant listing criteria like ‘the standard should have no critical issues’, or ‘there should be no requirements conflicting with each other’, etc.
That way, we can almost get a “countdown” to a release that is objective rather than subjective.
However, we feel quite confident that our last year’s issue pruning sessions, and the four years of development of the standard, to the best of our knowledge, have already addressed the examples that we could come up with.</p>

<p>For general information, we also brought up a few other items on the roadmap that are more related to the form than function of the standard, and thus we don’t consider them to be blocking a version 1.0 but are rather something that would be nice to have before that release.
These are the two things that we would like to add.</p>

<ol>
  <li>The ability to “deep link” directly to a requirement. We work on that in <a href="https://github.com/publiccodenet/standard/issues/327">issue 327</a> but also got a tip to look at legislative linking standards like the <a href="https://en.wikipedia.org/wiki/European_Legislation_Identifier">European Legislation Identifier</a> (ELI) and the blog post <a href="https://hamish.dev/a-love-letter-to-the-parliamentary-counsel-of-the-world">A love letter to the Parliamentary Counsel of the world</a> which has some extensive writing on the topic. Our aim for now is that deep links like these should be stable over time so that we can avoid breaking links even if requirements are reordered or deleted.</li>
  <li>The ability to find older versions on the website. Currently, older versions are available on GitHub, but they are not easy to read or to link to. Later, when we have several versions after 1.0 and especially if some of them are ISO standards, it will be more important to be able to refer to a criterion of a specific version of the standard.</li>
</ol>

<p>Finally, we briefly discussed if the benefits of getting the standard to become an ISO standard outweigh the added overhead.
Obviously, we don’t really know the answer to that question, but as we have been working with a standard for more than four years now, we have seen what weight the ISO label has and gives to the standards under their umbrella.
We are also confident just becoming an ISO standard will turn a big spotlight on it.</p>]]></content><author><name>Jan Ainali</name><uri>https://publiccode.net/who-we-are/team/jan-ainali.html</uri></author><category term="Community call" /><summary type="html"><![CDATA[Thoughts about when to release version 1.0]]></summary></entry><entry><title type="html">Notes from the Standard for Public Code community call - 5 October 2023</title><link href="https://blog.publiccode.net/community%20call/2023/10/09/notes-from-community-call-5-october-2023.html" rel="alternate" type="text/html" title="Notes from the Standard for Public Code community call - 5 October 2023" /><published>2023-10-09T00:00:00+00:00</published><updated>2023-10-09T00:00:00+00:00</updated><id>https://blog.publiccode.net/community%20call/2023/10/09/notes-from-community-call-5-october-2023</id><content type="html" xml:base="https://blog.publiccode.net/community%20call/2023/10/09/notes-from-community-call-5-october-2023.html"><![CDATA[<h1 id="5-october-2023-standard-for-public-code-community-call">5 October 2023 Standard for Public Code community call</h1>

<h2 id="attendees">Attendees</h2>

<ul>
  <li><a href="https://publiccode.net/who-we-are/team/jan-ainali.html">Jan Ainali</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/eric-herman.html">Eric Herman</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/elena-findley-de-regt.html">Elena Findley-de Regt</a></li>
  <li><a href="https://publiccode.net/who-we-are/team/ben-cerveny.html">Ben Cerveny</a></li>
  <li><a href="https://floss.social/@harishpillay">Harish Pillay</a>, JTC1</li>
  <li>Ian Forrester, BBC R&amp;D</li>
  <li><a href="https://fosstodon.org/@bzg">Bastien Guerry</a></li>
  <li>Matti Schneider</li>
  <li>Sidney Richards</li>
  <li><a href="https://www.os2.eu/om-os2">Jan Maack Kjerbye</a>, OS2</li>
</ul>

<h2 id="updates-from-the-foundation">Updates from the Foundation</h2>

<ul>
  <li>The Standard for Pubic Code is a finalist in the <a href="https://joinup.ec.europa.eu/collection/open-source-observatory-osor/osor-community-award-2023-voting">OSOR Community Awards</a></li>
</ul>

<h2 id="notes">Notes</h2>

<p>Harish Pillay gave a presentation on how a standard can get an ISO status. (<a href="https://files.publiccode.net/nextcloud/index.php/s/RCyKg4GSLaSHnsM">slides</a>)</p>

<p>Some good takeaways were:</p>

<ul>
  <li>There is a <a href="https://jtc1info.org/">Joint Technical Committee</a> with mentors that help organizations through the process.</li>
  <li>As the Standard for Public Code is not starting from scratch, it can jump a few steps in the process so that it will likely take 6-9 months.</li>
  <li>The biggest effort will be in converting the standard to the required formats (for example, ISO doesn’t use  <a href="https://tools.ietf.org/html/rfc2119">IETF RFC 2119</a>), but there are templates and guidance to make this easier. This work is done by the standard’s existing community.</li>
  <li>Standards need to be submitted in PDF and Word formats (<a href="https://iso.org/drafting-standards.html">templates</a>).</li>
  <li>The review is mostly for formatting.</li>
  <li>The process is free of charge.</li>
  <li>When a standard is released in a new version, it needs to go through a review process again.</li>
  <li>If a standard was open, it can stay open and does not need to be paywalled.</li>
</ul>

<p>In the discussion that followed we noted that the Standard for Public Code is not at version 1.0.0 yet, and we should wait until then to start the process.
While some uncertainty still remains on exactly when that will be, it is likely this is within a year.
We also noted that it is not unlikely that the release of 1.0.0 will draw attention, to the point that there might be a couple of more releases shortly after.</p>

<p>For formatting, it should be possible to build workflows that create properly formatted versions on release.
For example, a <a href="https://github.com/tkottke90/markdown-to-docx">tool to create DOCX files from MarkDown</a> was shared which demonstrates that Pandoc is capable of this.</p>

<p>We also talked about the release cadence and it was clear that not many ISO standards release often.
We could not think of any that have several releases per year.
While talking about that, it was also noted that not each release has to be submitted for ISO status - it would be possible to only do that for major versions or even selected versions.</p>

<p>There was quite some excitement during the call as it seemed possible for the Standard for Public Code to achieve that status and that the biggest remaining question is about when to start the process.</p>]]></content><author><name>Jan Ainali</name><uri>https://publiccode.net/who-we-are/team/jan-ainali.html</uri></author><category term="Community call" /><summary type="html"><![CDATA[What does the path to becoming an ISO standard look like?]]></summary></entry></feed>