Blog for Public Code

This blogpost

Notes from community call - 20 February 2020

Attendees

Foundation updates since December 2019

Since the start of the new year, we’ve been focused on codebase stewardship, and specifically the assessment phase of the codebase stewardship lifecycle.

We hosted workshops for 3 codebases in January. They focused on:

  • developing a market consultation process to birth an open source ecosystem for a new piece of software. We’re working with a group of municipalities that jointly commissioned the software as a proof of concept. They’d now like to procure it as open source software with multiple vendors.
  • codebase deepdives to explore what the current maintainers think are priority areas, and how we could best work with them. For example, together we identified setting up a technical steering committee, and developing a project plan for launching a marketing website for a codebase.

Building on this, we’ve updated our assessment process explanation and criteria on About - see PR #577 and of course, we’d love your views.

We’ve submitted our first pull request comparing a codebase to the Standard for Public Code yesterday - this is the assessment step that makes incubation possible.

We also went to FOSDEM - read Alba and Jan’s blogposts about it!

Upcoming events we’d love to see you at:

Notes

The Foundation for Public Code’s communication principles define us as an open source organization. The topic for today’s community call was ‘how we approach content strategy as an open-by-default organization’. We ultimately only covered one of the potential content strategy questions.

Creating an open-first culture with a bias towards publication (where people feel safe publishing their earliest usable in-progress work)

We talked about how tools should make it easy to be open by default, to support you in your openness - otherwise it’s too easy to default to staying closed. Using tools that are open also makes the process more open with regard to diversity - when there are no gatekeepers and it’s easier to join, it can expand access for underrepresented communities.

We discussed the agenda for this call as an example. We go out of our way to publish the link everywhere to make it findable. If it were natively on About it would be easier to see how it develops over time, for example by comparing diffs. Having to make a pull request to change the agenda introduces a new hurdle, but it wouldn’t only be a cost for us. Since we would need to start the process a bit earlier in order to be able to merge before a call, it also make us more transparent, and easier for the community to see what is happening.

Another complication we discussed is how we pride ourselves in producing high quality content (in line with our definition of done). Would us having more documents with work in progress status publicly available undermine that? While not being sure on how the world looks upon it, we think most can be mitigated by clearly signal the status of the work. Since no one expects that you start with a finished product, it is natural for it to be iterated upon and evolved over time. A good status notice might also be an invitation for people to add their thoughts before the document is finished.

We also touched upon the problem with information overload. about.publiccode.net has so much content it can be hard to find what you are looking for. If people searching for information cannot find it, it doesn’t really matter if it is open in theory. This led to us bringing up the need for usability research on our website. If we know who wants to use our website and how, we might be able to implement solutions to help them, with search bars or other tools that would serve their needs.

Finally, as a bit of a sidetrack from the topic of who uses our website, the question of the name About was brought up. Does our website contain what you would expect under a link named ‘About us’? We noted that other organizations (like Decidim) use the term ‘meta’, but tabled the discussion without decisions.