Codebase stewardship is what we call the way we support public code codebase communities as they aim and work to meet the Standard for Public Code. Our approach of relating to the codebase community from the position of being stewards is highly intentional. We have no ambition in claiming ownership of or running a codebase, but rather our goal is to help the community be successful in what they want to achieve. Thus, our approach is more similar to a coach, mentor or advisor rather than a hands-on developer or project manager. Sometimes we act as a neutral party that can arbitrate on issues that the community escalates to us.
You can get an overview of the codebase stewardship process from the lifecycle diagram. If you want to learn more on how to explain stewardship, see this activity for that.
Our main line of work
Understanding the codebase community
In order to be able to help, we must first understand and empathize with the codebase community.
- what is it that they want?
- what are their pain points?
- what can we help them with?
This is important during all stages, but even more prominent when we first meet a new codebase community.
Common and repeating kinds of tasks
As codebase stewards, we aim to support codebase communities in whatever ways we identify would enable better collaboration and codebase improvement. We’ve seen that most codebases communities have similar needs.
Conference calls have become essential for collaboration. Each codebase community will benefit from having a regular (monthly or quarterly) product steering conference call where stakeholders and product managers from each deployment can come together and talk about what their needs are presently and in the future, thus we host a Jitsi video conference server for the communities. Simlilarly, each codebase community will benefit from having a weekly or bi-weekly technical call where the developers can discuss how they should change the codebase. In each of these types of calls we typically coach community members to become the (rotating) chair of the call, although we may chair the calls in the beginning. By being present in the calls, stewards can listen for early signs of friction, and ensure that it is addressed before it grows. Stewards should ensure after any call that a summary is sent to a persistent and searchable primary communication channel for the codebase community, like an email list. These summaries should contain a brief list of topics discussed and any conclusions reached and any follow-up actions agreed to.
Additionally, mailing lists and open text chat platforms are often needed. We can host these:
With the aim to help the communities get more collaborators, we push them to work more in the open.
Clear governance helps a new collaborator participate, thus we help codebase communities draft or improve their GOVERNANCE.md.
Flexibility in our support
We do try to support the codebase communities overcoming their current painpoints. This might lead to developing new processes and methods. Here are a few examples when addressing specific codebase community needs has generated experiences that might be applicable to more communities in the future.
- Creating an open market consultation to get early insight in a possible ecosystem of vendors and users
- Navigating security processes (Common Vulnerabilities and Exposures, CVE)
- Building trust between teams in different organizations by getting them together in a safe environment
- Guiding through license considerations for a codebase and its components
Our most important tool: Standard for Public Code
The Standard for Public Code is our most important tool, and everything we do should be in the spirit of it. The requirements in it are the results of distilling good practices that are essential for enabling collaboration. It is useful even as a handbook when trying to guide a community through any situation they are in.
Related activities
- Codebase auditing - the process we use when auditing a codebase towards the Standard for Public Code
- Explaining what codebase stewardship is - often needed when meeting new communities to help them understand what we do
- Maintenance of the Standard for Public Code - we continuously develop the standard and are tending to incoming issues and have community calls
- Supporting governance - crucially needed for codebase communities that haven’t got their first collaborator yet
- Reviewing codebase incubation progress - important steps
- Workshops - we often help our communities learn and understand their needs through workshops
- Tool guidance - a list of the tools that we currently have at our disposal
Useful resources
- How codebase stewardship works for existing codebases - some guidance when entering exisiting codebase communities
- Community assets check list - with focus on the assets needed to grow the community during early incubation
- Product assets check list - with focus on the assets that help establish the codebase as a product during early incubation
- Tracking codebases in Odoo - guide that explains how the codebase stewards use Odoo to track the work with codebases
- Product development - from a stewardship perspective
- Trainings - we have collected educational resources that are always useful for a codebase steward to master
- Stewardship badge - codebases in stewardship can use this badge to show that it is stewarded by the Foundation for Public Code
Templates
- Standard for Public Code auditing template - this is the template we use when auditing a codebase towards the Standard for Public Code
- User personas templates - template personas that are typical in the type of codebases we work with that can be used as a starting point
- Codebase in Odoo - template to use when we add a new codebase in Odoo
- Stewardship proposal - a template proposal we can send to principal maintainers to get informed consent to steward the codebase