Opensource.guide: [RFC] Marketing > Building a Community

[nayafia]

Hey open source maintainers! We would love your feedback on the Marketing > Building a Community article. We will leave this open for comments until Sep 1, 2016.

Does anything seem inconsistent with your experience? What is missing? Are there any other helpful resources on this topic?

Feel free to comment and discuss here, or even open a pull request to suggest changes.

View | Edit

[MikeMcQuaid]

One way to think about your project’s community is what @MikeMcQuaid calls the contributor funnel.

😊 There was video recorded for this at CodeConf that we could probably link to at some point? Don't think it's been uploaded anywhere yet, though.

Particularly like this article 👍

[MikeMcQuaid]

Particularly like this article 👍

And not just because it mentioned me 😆

[benbalter]

Any time you feel the urge to write something down about your project, ask yourself whether you can make it public.

I might go a step further and talk about memorializing out-of-band or meatspace discussions (especially for those coming from a corporate background where information imbalance risk is high)

For casual or first-time contributors, be open-minded about the types of contributions you’ll accept. Many casual contributors start with a small fix.

One idea I like to talk about here, is to try to expand the audience's concept of potential contributors from developers to a much larger group of stakeholders. For many their first contribution is opening an issue or commenting on an existing issue. A non-developer user filing a bug is still a contribution if constructive (and can then very easily lead to "are you able to submit a pull request..."). _See generally_ Everyone Contributes.

[benbalter]

Not sure if it's better here, or in #54, but I think it's worth talking about how effective maintaining an internal, private fork is at killing an open source community. Case in point, I spend a week working on my first pull request to fix a bug that's I'm affected by. Upon receiving you say "thanks, but we've got a fix already merged internally, we just haven't published our changes yet". You can be pretty sure I'm never going to contribute again. See Minimize information imbalance for the internal side.

More broadly, there may be some other opportunities here to help large organizations make the conceptual shift to open source. Specifically, the concepts of:

• Not being a single choke point/point of failure
• Minimizing contributor friction
• Decentralizing project governance (both internally and externally)
• Actively and explicitly encouraging external contributions

[lee-dohm]

For many their first contribution is opening an issue or commenting on an existing issue.

My first contributions to Atom were doc fixes :grinning:

[nayafia]

@jlord: would love your feedback on this one!

[joshsimmons]

Feedback for something to add either under "Make it easy for people to use and contribute" or "Document everything":

It seems useful to note that contributions can be more than code, not just docs, but also design/UX/community building, and those contributions may not fit into the typical code/doc contrib process... so it may be worth documenting those contrib processes as well.

[jlord]

This looks great! One thing that I thought about was the 'help wanted' type of labels. I'm not sure if there will another place in this handbook that will be a better fit, but it's a nice way to encourage people to pick up a task, show that it's up for grabs, and especially if it's on an issue that's non-code related.

[nayafia]

Closed per #99.