This is a checklist of the most important community 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 community asset order will be different for greenfield development.
List of assets
| Priority ID | Short form | Who’s responsible? | Point person |
|---|---|---|---|
| 1 | Use a free license | Others do | Quality |
| 2 | Write documentation in English | Others do | Product |
| 3 | One sentence codebase description for repository platform | We do and others decide | Product |
| 4 | Codebase name | We do and others decide | Product |
| 5 | One paragraph codebase description | We help others do | Product |
| 6 | Publish the objectives in an understandable language | Others do | Product |
| 7 | Organization page on repository platform | We do and others decide | Quality |
| 8 | Publish all source code | Others do | Quality |
| 9 | Have a good README | We help others do | Community |
| 10 | Publiccode yml | We help others do | Quality |
| 11 | The codebase must be reusable | We help others do | Quality |
| 12 | Use a public issue tracker | We help others do | Community |
| 13 | Have a good code of conduct | We do and others decide | Community |
| 14 | The documentation is easy to read | We help others do | Community |
| 15 | Allow pull requests from anyone | We help others do | Community |
| 16 | Have a good CONTRIBUTING | We help others do | Community |
| 17 | Standard assessment file | We do and others decide | Quality |
| 18 | Link to language style guide | We help others do | Quality |
| 19 | Pull request template | We help others do | Quality |
| 20 | Link discussions and issues in commit messages | We help others do | Quality |
| 21 | Link to code engineering guide | We help others do | Quality |
| 22 | Provide examples of key functionality | We help others do | Community |
| 23 | Quickstart deployment guide | We help others do | Quality |
| 24 | Give feedback during review | We help others do | Quality |
| 25 | Review within two business days | We help others do | Quality |
| 26 | Quickstart user guide | We help others do | Support |
| 27 | Make inline comments in the codebase | We help others do | Quality |
| 28 | API documentation | Others do | Product |
| 29 | Codebase brand or logo | We do and others decide | Product |
| 30 | Swag | We help others do | Community |
| 31 | Explain who is involved in the codebase | We help others do | Community |
| 32 | List of replicating public organizations, with links to their deployment | We help others do | Product |
| 33 | Use case story | We help others do | Product |
| 34 | Testimonials | We help others do | Product |
| 35 | Use at least one public communication channel | We do and others decide | Community |
| 36 | Asynchronous communication channel (mailing list/forum) | We help others do | Community |
| 37 | Syncronous communication channel (chat) | We help others do | Community |
| 38 | link to news stories about the codebase | We help others do | Community |
| 39 | Newsletter | We help others do | Community |
| 40 | Benchmark similar communities | We help others do | Community |
| 41 | Regular community calls | We help others do | Community |
| 42 | Organize meetups (less formal events) | We help others do | Community |
| 43 | Static website | We do and others decide | Product |
| 44 | Calendar | We help others do | Community |
| 45 | Podcast | We help others do | Community |
| 46 | Publish and link all relevant policy | We help others do | Quality |
| 47 | Be explicit in how the codebase implements the policy | We help others do | Quality |
| 48 | Provide high level description of the codebase | We help others do | Product |
| 49 | Introduction for new contributors | We help others do | Community/Quality |
| 50 | Have a good GOVERNANCE | We do and others decide | Community |
| 51 | Publish a public roadmap | We help others do | Product |
| 52 | Attending events | We help others do | Community |
| 53 | Use other communities to promote yours | We help others do | Community |
| 54 | Get in contact with people potentially interested in the community (Influencers) | We do and others decide | Community |
| 55 | Explain how the roadmap can be influenced | We help others do | Community/Product |
| 56 | List of experienced vendors | We help others do | Support |
| 57 | List of codebase roles | We help others do | Community |
| 58 | Issue templates | We help others do | Community/Quality |
| 59 | Feed showing recent activity on the codebase | We help others do | Community/Product |
| 60 | Create alternative channels for the community (chats, forums, feeds, etc.) | We help others do | Community |
| 61 | Detailed deployment guide for sysadmins | Others do | Quality |
| 62 | Community stats (size, activity rate) | We help others do | Community |
| 63 | Leaderboard | We help others do | Community |
| 64 | Contributor badges | We help others do | Community |
| 65 | Give presentations | Others do | Community |
| 66 | Organizing events | We help others do | Community |
| 67 | Promote the codebase | We help others do | Product |
| 68 | Press releases | Others do | Product |
| 69 | Provide translations of the documentation | Others do | Quality |
Assumptions to test
This list is based on our experience from working with several codebases.
These include that:
- making clear which responsibilities the Foundation for Public Code has versus other parties is useful
- which other party is responsible differs by codebase
- for some codebases, multiple parties share responsibility for non-Foundation for Public Code 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)