Home to all of our staff information, decision-making rules and processes. It is our staff manual that can be developed collaboratively with the community and reused by everyone.
I would suggest finding something that is more natural for use in common language, for instance replacing the comma with the word 'for' in running text, or everywhere.
It would be great if we could create a list of related organisations, and how we can complement them :)
So if you know any other public technology organisations or communities please tell us who they are and how they could relate to the Foundation For Public Code.
I would like GitHub issues to be the place where we can work together with our contributors/advisors in order to solve the problems at the root of this foundation. I'm imagining inviting those who have been willing to advise us to specific issues and asking them to engage with more from there.
I think the goal of individual Issues is to:
Identify what the foundation should be, do and communicate: what the contents of the repository/site should be
Spawn new issues with questions and work that needs to be done
I'm trying to figure out:
how can we ask questions in a way that is conducive to conversation
and that engages our contributors/advisors?
And what should the subject line
and the body text contain?
I've made these issues which can serve as examples to discuss this:
#27 How can we sustainably fund the Foundation so it can be a long-term partner?
Looking for funding and business models. We believe in order for any code in the care of the Foundation to be usable it needs to have a guaranteed stewardship of at least a few years. (but how many)
So far we've been considering 3 major sources of revenue:
City partners
Codebase donators through endowments
Implementation partners
Grant funding
Philanthropic funding
How are others doing this, solving this problem, and how can we?
If someone comes in and wants to edit the home page they need to edit the file index.md.
However, if you don't know about the web, how can you ever know...
Ideally the README.md, which displays as the file that displays on the GitHub repository home page explains what file to edit for the homepage on the website.
Add a mention of the homepage on the about. website is in the file index.md. You could add a sentence under the "Preview, Build and Deploy" heading explaining this.
The lovely folks at OS2 are sending us some of their founding and business model docs so we can use them as reference material as we build our own. They're in Danish, but we'll need them in English (both for us and for other municipalities to learn from.) If you could help with this, please reply here or email us at [email protected].
Keeping with RESTful URLs, as in /people/ben-cerveny. A way to solve this is to make a folder for everyone, with an index.md per person for their profile and a photo.
I propose using front matter in order to add structured data like function and perhaps from and until.
I would include a line or two that a) Foundation stewards codebases to become Public Code, b) all 4 roles work together to deliver this codebase stewardship package, c) do this by supporting development teams and communities who are producing code for public implementation
Given that we are trying to maintain the about repo and thus about.publiccode.net as a "canonical truth" about the organization, does it make sense that more production intensive and harder to update materials live inside, or in another more ephemeral repo like the main site.
Thinking about using reveal.js for presentations using the slides.com editor.
The goal of the README.md is to help people get into the project and ready to contribute (by linking to the guide in CONTRIBUTING.md). In order for people to get in touch with other collaborators we've opened a Riot chatroom at https://riot.im/app/#/room/#publiccodenet:matrix.org, but how will people ever know?
One of the blocking factors in starting projects in the Foundation For Public Code product stewardship programme is that we don't necessarily have a way of pointing at what qualities need to be adhered to.
We need to set standards that can be used inside and outside of the Foundation For Public Code to build high-quality Open Source components for public software.
For this we can build on the great way done by GDS, Team Digitale and DINSIC and USDS/18F, however, we might want to have a version that is under our own control.
We create a viable future for cities and civic operating systems that are highly participatory and drive societal engagement. A public digital infrastructure that is inclusive, usable, adaptive, open and sustainable.
To achieve this we maintain, manage, contribute to and grow an ecosystem of public software and policies that help governments, communities and citizens improve their city.