Skip to content
Open {re}Source

    04Creating

    Community From Day One

    You don’t have a community yet. You have a repository and, if you’re lucky, one stranger. Half an hour of setup makes the second stranger’s life easier, and a few things are better left alone until there are ten of them.

    Set up what a stranger looks for#

    A stranger deciding whether to use your project, or to help, looks for four things. None takes more than ten minutes:

    1. A code of conduct that names who to write to. The text matters less than the contact line. The Files That Turn a Repository Into a Project has the smallest version that works.
    2. Discussions, with a pinned welcome post. When you first set up Discussions (Settings, then Features), GitHub proposes a welcome post as a template. Cut it to three lines: what the project is for, where to ask, how to help. Pin it.
    3. Two good first issues. Real ones: a bug you know how to fix, with the file to change and what “done” looks like. Two, because the first one gets taken. “Improve the docs” is not a good first issue.
    4. A way to reach you in the README. Your handle, the Discussions link, and the Sponsor button if you’d accept money (FUNDING.yml).

    Discussions is the one channel worth opening this early. It sits next to the code, costs nothing to keep, and a question asked there is still findable when the second person has it.

    Don’t open what you can’t keep open#

    An empty Discord is worse than none. A newcomer joins, says hello, gets no answer, and leaves thinking the project is dead. Everything on this list looks like a community and needs one to work:

    Not yet Why When
    A chat server Someone has to be there, and an empty room looks abandoned When Discussions has regulars who answer each other
    A newsletter Issue three is where most of them stop When release notes aren’t enough to say what happened
    A governance document “Decisions are made by @you” is the whole of it for now With the second maintainer (Planning Your Project)
    A mentorship program A program with no mentee is a page nobody reads When you can’t answer every first-timer yourself

    The first contributor is the community#

    The first pull request from a stranger is, for now, all the community you have. Treat it that way:

    • Reply within a day, even if it’s only “Thanks, I’ll review it this weekend”.
    • Merge fast. Fix a typo or a naming nit yourself rather than ask for a third round: GitHub lets you push to the contributor’s branch when they tick Allow edits from maintainers on the pull request.
    • Thank them by name in the release notes, with an @mention, so their avatar shows under the release.
    • Point to the next issue in the thank-you.

    If they come back, you have a community. Running a Community Without It Running You picks up from there: channels, credit, a rhythm, and conflicts.

    Do this now#

    • Add a code of conduct that names at least one contact.
    • Set up Discussions, edit the welcome post to three lines, and pin it.
    • Write two good first issues, each with the file to change and what “done” looks like.
    • Say in the README where to ask questions and how to reach you.
    • Decide now that you’ll answer the first pull request within a day.

    Go further#