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](http://hood.ie/), SpinachCon, [FirstTimersOnly.com](http://firsttimersonly.com), [UpForGrabs.net](http://up-for-grabs.net), and [Outreachy](http://outreachy.org), 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:** ## The complete series (so far) [notes:series:software-outreach] **** ## 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](/conduct), and by making sure people know the Code of Conduct and follow it. [notes:code-of-conduct] ## Friendliness As highlighted by [the Hoodie community](http://hood.ie/about/) and the [First-timers only movement](http://www.firsttimersonly.com/), 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. **Read more in this post: https://publiclab.org/notes/warren/12-12-2017/software-outreach-codes-of-conduct-and-friendliness** ## First-timers-only As pioneered by the site http://firsttimersonly.com and championed by [Hoodie](http://hood.ie/about/), 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"! [notes:first-timers-only-blog] ![welcoming page](https://publiclab.org/system/images/photos/000/022/004/large/Screenshot_2017-10-23_at_12.03.37_PM.png) ## Welcoming pages One key strategy adapted from [Rasmus Praestholm](https://github.com/Cervator) of the [Terasology project](http://terasology.org/) 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#r=all See our [older version here](https://github.com/publiclab/plots2/projects/2), and create your own at: https://github.com/publiclab/community-toolbox (more coming soon) ## Modularity Modularity may sound kind of boring as a topic -- and it's relationship to outreach and onboarding not immediately apparent. The basic idea is to isolate functionality in smaller chunks of code which are easier to reuse, understand, and maintain. But this is exactly what newcomers need -- to not have to know a much larger whole system to be able to get your bearings, and to know what a chunk of code will receive as input, and should generate as output. It also makes for very test-able code, and code which has a minimal "entanglement" with other parts of a complex system. I encourage ANYONE doing open source work to think hard about how their project can be better modularized -- along with the various other strategies on this page, it can lead to a major influx of new contributors! **Read more here: https://publiclab.org/notes/warren/12-12-2017/software-outreach-codes-of-conduct-and-friendliness** ## Evaluation How can we understand what's working and not working in our efforts to welcome a broader and more diverse group of contributors into our community? Evaluation techniques are critical to understanding what we're doing poorly and what's working. Read some about our work in evaluation [on this page](/evaluation), and read about [our Software Community Survey here](https://publiclab.org/questions/warren/10-25-2017/help-with-a-standard-mini-evaluation-for-assessing-software-outreach-efforts) (more coming soon) ## Social media outreach (coming soon) ## Ladders of participation/leadership (coming soon) ## Continuous integration (coming soon) ## Friendly Bots (coming soon) **** ## Questions [questions:software-outreach] **** For a list of many features we've implemented for outreach efforts on the PublicLab.org website, see: https://publiclab.org/wiki/community-development