This is a checklist of the most important product assets needed to put an existing codebase on its path to incubation, roughly organized by when they’re needed.
Assumptions
We assume that the chronological goals during incubation are to:
- make sure the codebase is deliberately designed and documented to be reusable
- create everything needed to enable and support a contributing community
- focus on collecting evidence and marketing to attract more replicators and contributors
- improve an active codebase based on performance metrics, user research or new feature requests
We assume each codebase will have different individual needs.
We assume the product asset order will be different for greenfield development.
Product assets
| Timeline | Product asset | Foundation’s role | Foundation point of contact |
|---|---|---|---|
| 1 | Decide to open source | Confirms | Quality |
| 2 | Plain English | Confirms | Product |
| 3 | Organization page on Github | Responsible | CEO |
| 4 | Disable merge to main | Responsible | Quality |
| 5 | One paragraph codebase description | Provides assistance | Product |
| 6 | Document codebase objectives | Confirms | Product |
| 7 | Configuration options | Confirms | Quality |
| 8 | One sentence codebase description for Github | Creates proposal | Product |
| 9 | Issue tracker (or link if hosted elsewhere) | Creates proposal | Community, Quality |
| 10 | CONTRIBUTING file | Responsible | Community |
| 11 | Explanation of how codebase decisions get made | Creates proposal | Community |
| 12 | Codebase name | Creates proposal | Product |
| 13 | Contextual explainer (including policy explanation, users and process owners) | Provides assistance | Product |
| 14 | High level overview of what’s in the codebase | Confirms | Product, Quality |
| 15 | README file | Provides assistance | Product: is this findable and usable? Quality: is all the right information included? |
| 16 | Codebase maturity label | Responsible | Quality (release management) |
| 17 | Codebase brand or logo | Creates proposal | Product |
| 18 | List of codebase stakeholders with their role (real people) | Provides assistance | Community |
| 19 | List of experienced vendors | Responsible | Community, Support |
| 20 | Simple architectural model | Confirms | Quality |
| 21 | Community fora (or links if hosted elsewhere) | Responsible | Community |
| 22 | Reports from user research into how codebase is working or could be improved | Provides assistance | Community |
| 23 | Quickstart deployment guide | Confirms | Support |
| 24 | Quickstart user guide | Provides assistance | Support |
| 25 | Choose license | Provides assistance | Support |
| 26 | A publiccode.yml file | Creates proposal | Product |
Assumptions to test
This list is based on our experience from working with several codebases.
These include that:
- making clear which responsibilities the Foundation has versus other parties is useful
- which other party is responsible differs by codebase
- for some codebases, multiple parties share responsibility for non-Foundation tasks (for example, a codebase’s current maintainers and a replicator working together)
- the size of each task depends on codebase size and complexity
- this list can be used as a checklist or plan of work during incubation
- it would be helpful to add user needs, user stories or jobs to be done to the list items (as we discussed user needs when we created the list)