Since early 2016, Public Lab has worked to make our open source software projects more welcoming and inclusive; to grow our software contributor community in diversity and size. This page collects some of those strategies and initiatives.

Transformation

First, one thing we've learned is that doing good software outreach means acknowledging that your own work must change. Not only in shifting from direct coding work to organizing and cultural work, but also in transforming your own coding style and architecture (see Modularity, below) to make it easier for others to enter into your work and work with you. Good outreach will make you a better coder!

Inspiration

Since 2016, we have learned from and incorporated strategies from other communties like the Hoodie project, SpinachCon, FirstTimersOnly.com, UpForGrabs.net, and Outreachy, and also shared our own ideas, and this session will cover a range of principles and strategies that have emerged across a number of separate efforts in different open source projects.

Read more about this on the Software Outreach blog series:

Code of Conduct

An even more important counterpart to friendliness is to ensure people feel safe by clearly forbidding inappropriate behavior in a Code of Conduct, and by making sure people know the Code of Conduct and follow it.

Friendliness

As highlighted by the Hoodie community and the First-timers only movement, one of the first steps to having a more welcoming and inclusive community is to be really nice.

This can come through in documentation, in discussions, by providing positive and constructive support, and when thanking people for their work. Modeling and talking about welcoming and friendly tone is important to establishing and sustaining a welcoming culture for newcomers and long-time contributors alike.

First-timers-only

As pioneered by the site http://firsttimersonly.com and championed by Hoodie, we provide newcomers a chance to learn how we collaborate by going through a step-by-step guided issue to make their first contribution.

These issues take longer to make than fixing the actual bug, but the purpose is to engage with a new community member and show them how to work with us in an encouraging and supported way.

They are also small enough issues that they can be done in a fairly short period of time, and this encourages modularity (see below) -- complex, layered processes must be broken into smaller, simpler modules in a sequence, or there's "no way for others to enter the work"!

Welcoming page

One key strategy adapted from Rasmus Praestholm of the Terasology project is to have a page specifically for welcoming and supporting newcomers, as shown in the screenshot above (Rasmus developed several Trello pages to help organize the welcoming process). This page is friendly, provides newcomer-specific resources and also features a call to action with #first-timers-only issues (see above).

See our Newcomer Welcoming Page here: http://publiclab.github.io/community-toolbox

See our older version here, and create your own at: https://github.com/publiclab/community-toolbox

(more coming soon)

Social media outreach

(coming soon)

Modularity

(coming soon)

Ladders of participation/leadership

Continuous integration

Friendly Bots

Evaluation

Questions