Open Source Launch Checklist: Prepare the Repository Before You Announce It

Why does the repository come before any announcement?

When you announce an open source project, nearly every click ends on the repository, and the first screen of that page does the work a landing page does for a product. Visitors scan the description, the README and the file list, and decide within moments whether to try it or to go elsewhere. Anyone who opens an issue the same day is also deciding whether you are the kind of maintainer who answers.

So the order is repository, then release, then announcement. Doing it backwards means sending your best audience to a page that still says “TODO”. The fuller strategy, such as whether to look for users or contributors first, is in the launch playbook for open-source maintainers and the open source launch playbook. This page is the pass-or-fail list for the repository itself.

Which files does GitHub’s own checklist look for?

GitHub’s documentation on community profiles, read on 13 November 2026, says the community profile checklist looks for recommended health files, such as a README, a code of conduct, a license and contributing guidelines, in a supported location. It also says issue templates earn a checkmark only when they live in the .github/ISSUE_TEMPLATE folder and carry valid name: and about: keys in the front matter of a Markdown template, or name: and description: keys in a YAML issue form. You can read the community profile documentation yourself.

To add a license, GitHub’s guide describes creating a file named LICENSE and choosing from its templates. If you are unsure which license fits, read the text of the ones you are considering before you pick; a license is a legal choice about how others may use your work, and a launch is a bad moment to change it later.

Does a stranger get a result in five minutes?

1. Open the repository as a logged-out visitor and read only the first screen of the README; if you cannot say what the project does from that screen, rewrite it.
2. Put the install command and a first working example near the top, because people copy before they read.
3. On a clean machine or a fresh container, follow your own README exactly and write down every place it breaks. Your laptop has hidden dependencies that a stranger does not.
4. Pin or state the versions you support, so “works on my machine” has a defined meaning.
5. Add a screenshot or a short recording if the project has any visual output; a still of the result beats a paragraph describing it.
6. Show a badge for passing tests only if the tests run on every change, because a red or missing badge is worse than none.
7. Link the documentation from the top, even if it is one extra page, so beginners know where to go after the example.

For the layout of the README itself, the README template for a launch offers a skeleton, and the changelog template helps with release notes.

How will anyone find the repository?

• Write a one-line description in the repository’s About box that says what the project is, since visitors read it before they reach the README.
• Add topics. GitHub’s docs say you can add up to 20, and that topics help people find projects by purpose, subject area, community or language.
• Upload a social preview image. The docs say it should be a PNG, JPG or GIF under 1 MB, at least 640 by 320 pixels, with 1280 by 640 best, and that links otherwise show basic details and the owner’s avatar. The OG image specs cover the same idea for your own site.
• Tag a release with notes, so there is something concrete to link and to install, and not only a moving main branch.
• Publish to the package registry your users already use if there is one, since many people install first and look at the repository later.

How do you protect your time once people arrive?

Open source attention arrives as work: issues, questions and pull requests, often from people you do not know. Decide your boundaries before the first message, and write them down where contributors will see them. A sentence in the README such as “I review issues on weekends and may take a few days to reply” sets an honest expectation and stops people reading silence as rejection.

• Seed three to five issues labelled for newcomers, each with a short description of what to change and where, so a first contribution is possible without a guided tour.
• Write down what you will not accept, such as large rewrites without a prior issue, in the contributing file.
• Turn off or ignore anything that will pull you into daily chat; a chat server with nobody in it looks abandoned.
• Reply to the first issues quickly, even if the reply is “thanks, I will look at it on Saturday”.

Title: [Small, specific change, for example: Add a --quiet flag to the export command]

What is wrong or missing
[Two sentences. Link to the file and line where the change belongs.]

What a good fix looks like
- [One observable behaviour]
- [One test to add or update]

How to run it locally
1. [clone and install command]
2. [test command]

I am happy to answer questions in this thread. First-time contributors are welcome.

What does the two weeks around launch look like?

When the repository is ready, launch your product free on this board with a link to it, and see the open source project places for others. If you want to see what builders are describing right now, the developer tool ideas page lists some.

What can you skip, and which mistakes cost the most?

• Skip a governance document until you have more than one regular contributor.
• Skip a sponsor button before the project has users; it reads as a request before you have given anything.
• Skip a website if the README and docs answer the questions; a second place to maintain is a second place to rot.
• Mistake: no license. Adopters often cannot use code without one, and the problem surfaces in the worst week.
• Mistake: an install that only works on your machine. It is the fastest way to lose a first visitor.
• Mistake: announcing before the first release exists. The announcement then points at a moving target.