About the Foundation for Public Code

Community assets

This resource

Contents

  1. Assumptions
  2. List of assets
  3. Assumptions to test
  4. Further reading

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 assumptions that we’re testing as we assess 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)

Further reading