PublicLab.org and PL's other open source software is written, maintained, and dreamed up by community contributors, just like the techniques you see on PublicLab.org itself. While you can read about our software development projects at https://publiclab.org/wiki/developers, we know not everyone can jump into being a code contributor -- but we also know there are lots of other ways you can help out, even without taking on a coding task.

And with our recent work in recruiting first-timer code contributors generating exciting growth in our software contributor group, we're looking to define clear ways others can get involved in more of a supportive role.

Types of support

I've looked at some of the ways people have played a valuable supportive (or mentoring) role -- like in our #gsoc program each summer -- and found that some don't take a huge amount of time or commitment, but can really make a difference. Here are a range of different types of involvement -- and keep in mind that many people do a combination of these:

• Problem solvers: swoop in when someone is really stuck and help crack the nut!
• Reviewers: check in on a pre-defined schedule to look over submitted code and comment on style, structure, etc
• Connectors: greet, provide support, regular friendly check-ins, links to resources, and encouragement to newcomers
• Community reps: be the voice of the broader Public Lab community in shaping new features

(forgive my slightly corny naming system!)

Different capacities

The key here is that:

• there are ways to help that can fit your schedule
• we need help with non-coding support as well

For example -- a Reviewer might do a lot of good just by checking in once a week to look over current pull requests, to see if they're missing anything, or make any obvious mistakes. This could be just a calendar reminder at the 15-20m you know you'll have free each Friday, say.

A Connector might check in once daily but only for 10 minutes, just to thank new people for their involvement, or to encourage them to open a pull request with their latest code if they get stuck (so others can check on their work and offer help).

A Community rep can offer their knowledge of how the PL community works (or doesn't!) without having to know anything about coding. They context to a bug or purpose for a feature request.

And so on. What's helpful for me, to match you with a role, is to know:

• how much time you've got (even 5-10m per week can be helpful!)
• what your interests or background are
• what your GitHub username is!

And keep in mind, this is a bit of an experiment! We'd love to better connect the PL community with our quickly-growing software contributor community, and this is just one way we're hoping to help.

Read on to learn more about each role, and volunteer in the comments if you'd like to get plugged in!

Choose a role

We'll be creating a "team" for each of these on GitHub (https://github.com/orgs/publiclab/teams); on there, you can notify each by typing @publiclab/teamname in a comment. So please share your GitHub username with us in the comments to sign up!

(Illustrations/mascots sought for each these, haha)

Problem solvers

@publiclab/solvers - Everyone gets stuck sometimes, and some people are just good at teasing out what went wrong. If you're particularly familiar with Ruby on Rails, or with a specific portion of our codebase, this could be you! No obligation to actually fix problems, but just to take a look and suggest a way forward, or a way to test assumptions and debug. We especially think writing tests is a great way to debug!

Availability: we'll ping you with a @publiclab/solvers mention, or you can just look at recent pull requests; maybe once every week or two. Unsubscribe from project-wide notifications!

Variation: Pre-schedule time each week or month to check in on recent pull requests and review code for problems and style/structure. We've told contributors that reviews happen on Tuesdays and Fridays, so these are good times to check i, and look specifically at the "Files changed" tab of each PR to read through submitted code. You can:

• request changes for code cleanliness or commenting
• ask people to specify what issue their PR fixes, especially using the text "fixes #1234" so that the PR actually auto-closes the issue once accepted
• ask for clarifications or suggest tests

For pre-scheduled solving, consider setting your project notifications (see below) to Ignore so that you don't get any emails, and just check in on your own schedule!

Connectors

@publiclab/connectors - Often, it makes a big difference to newcomers to simply hear some encouragement and thanks, both in response to comments like "Can I try to fix this one?" and after a fix is completed, say, in a tweeted thank-you. To do this, look for newcomers in recently updated issues or subscribe to notifications for the whole project and look out for people asking to get involved. Even if you're just saying hello to people, and offering encouragement, that's a lot of help -- you don't need to code to do this!

If you can help people find documentation, tutorials, or Stack Overflow pages to guide them, that's really helpful too! We've also heard from some contributors that it's really helpful to have a real live person (via chat, for example) there to say hello, even if all they do is be friendly and point people at the right resources.

Availability: this is the most day-to-day kind of work -- it's helpful to reply quickly to newcomers with a welcoming hello -- though the message can be "saved reply" to make this quick (see below). And beware -- the project-wide notifications can be high-volume. You shouldn't have to actually spend lots of time with anyone in particular, but it'd be great if folks already on IRC could just keep an eye out for newcomers asking questions.

Community reps

@publiclab/community-reps - It's difficult for newcomers to really understand the complexities and context for different site features, so we'd love to have some people just explain why features or systems are important, and how they're used. You don't need to know anything about software for this one -- it's just helpful to link to where on the site a feature would show up, and help new coders understand what their contribution will mean.

Availability: Once a week or so, we'll mention @publiclab/community-reps to notify you of where you could be of assistance. Unsubscribe from project-wide notifications!

Resources

There are some important tools available to help you be a good code mentor or helper:

• Ask for help! Mention another team from above to trigger a notification (@publiclab/reviewers,@publiclab/solvers,@publiclab/@designers`) or just ask me (@jywarren on GitHub)
• Saved replies are a GREAT GitHub feature to streamline your most common responses with standard text; copy mine here: https://gist.github.com/jywarren/c9a80e0e53f42208974683aa01c623c8
• Calendar reminders (check in once weekly? Once monthly?)
• Email notifications -- mostly, I'd say turn these off as soon as you're added to a team! If you get too many, you'll start ignoring them. Tweak them here: https://github.com/settings/notifications and on the project GitHub page: https://github.com/publiclab/plots2, but for most teams listed above, you can just set it to "Not watching" and listen only for when you're specifically mentioned by @name, when you'll get an email notice.

Sign up now!

So, again, just leave a comment below with your GitHub name to join a team, and feel free to ask questions or make suggestions!

And finally, if you find it's too much, please don't hesitate to take a break or withdraw! We definitely don't want to overload people and we very much understand that everyone's got a lot going on in their lives!