Contributor management practices around the Brigade Network

Contributors (aka volunteers) of various skillsets offer their services all the time to brigade projects. After polling the brigade network (in Slack), there’s some success stories and best practices you might want to employ at your brigade.

Sign up page

Code for South Florida has achieved some success with volunteers signing up via the online volunteering application form.
Learn more from @HiGregory
Also check out how Refresh Miami praises the Code for South Florida efforts

Github: README + issue tags

At Open Oakland, the Open Budget project leverages multiple features inside of Github to accelerate volunteers to contribute and create outcomes. First, is tagging issues that are “light lifts” that can be done by a newcomer as “help wanted”. Second is the README page that lists out the steps needed to get started contributing.

DemocracyLab

Based on research findings, the platform is focused on solving the common issues of volunteer management.
Learn more from @mark

Coming soon

  • Brigade standup volunteer pitches
    The biweekly standups run by @elb are going to create space for volunteer pitches.
  • Code for America Project index
    An index that captures all of the available projects and volunteering opportunities across the Brigade Network.

As all brigades are different and unique, the recommendations above are suggestions to get you started - not steadfast rules. Figuring out the best ways to galvanize volunteering effort might require some exploration and experimentation.

Want to share your thoughts on managing contribution requests?

As a community that builds by collaboration, we’d love to hear your experiences (the good, the bad, and the “never doing that again”) so we can grow together. Feel free to comment on this page or contact @Shaunm44 directly.

3 Likes

I love this post!

Terminology & Language

tl;dr - volunteer management also involves the language we use to speak about it, since language provokes emotion and is the basis of the identity we cultivate within projects/communities. (And without money and strict obligations, emotion and shared identity are much of what holds efforts together!)

Related friendly thoughts to toss into this thread: I feel like there’s a strain of opinion in Toronto that “volunteer” maybe isn’t the most appropriate label. But I’ll just speak for myself here, to be safe: I do cautiously use it to indicate we’re “volunteer-run” (to quickly set expectations in emails, outreach, etc.), but I personally prefer to avoid “volunteer” and instead speak of “contributors”. “Volunteer” feels more like a label from the perspective of the asker (who, admittedly, is often the one we want to center), whereas “contributor” feels more about the person offering and the value/gift they offer – though of course this is very fuzzy and subjective. “Volunteer management/coordinating” as a phrase feels a bit extractive and overly operationalized to my ears – like used for going door-to-door as a set of hands for political campaigns, as opposed to co-creating something together with our most valued skills… i dunno! Just riffing here :smile:

Also, perhaps most importantly, “volunteer” ties itself very strongly to free labour, whereas some projects might wish to experiment with compensation or fundraising models for sustainability :slight_smile:

Anyhow, I really appreciate this thread, nevermind our preferences for lingo! :heart:

A few years ago, I wrote a bit about terminology and labels within Taiwan’s g0v movement, in case anyone is interested:

As one final in-depth example of language aligning with known frameworks of peer production, we can look to the term “nobody”. A “nobody” is essentially a member of the g0v community. It arose in response to questions like “Why has nobody done this thing yet?”. Eventually, the reply became “You are that nobody,” and the question would be converted quite effectively into an offer of help. This relates to group identity and how long it can take for members to self-identify as members. Someone joining a company goes through an official hiring process, and then can unquestionably identify themselves as an employee. But for g0v, it might be unclear when exactly they could self-identify as “member” or “contributor”. The term “nobody” helps disrupt that uncertainty. To be a “nobody”, the word itself disarms the expectation that any onerous process is involved, in a concise and cleverly self-evident way.

There is also something interesting in that titles within most organizations are often linked to activities, which can come to an end and call identity into question. For example, to be an organizer or a member, it might be assumed you need to still be organizing or participating. But to be a g0v nobody, it implies a smaller set of activities. And so it is perhaps easier to maintain the identity across various levels of activity.

The history of this developed slang within g0v is perhaps not surprising, given that, as one of the founding members stated of herself, “the community was co-founded by a writer” who values metaphor and linguistic mechanisms.

[…]

Differences [between Toronto and Taiwan civic tech communities]

Named identity for community members. One prominent distinction is that the g0v community has a clear title for someone who is a member of the community, which is encouraged to apply very liberally: “nobody”. On the other hand, co-organizers in Toronto have no such term. They have periodically struggled with ideas for what to call community members. The term “civic techers” has been suggested, but does not seem to be accepted among co-organizers. Without a specific title, the Toronto community is left with weak, unsentimental terms to express its own identity: “community member”, etc.

1 Like

YES!!! Please do nitpick on the words and terminology! I’m very much someone who understands and values the impacts labels have on us.

Thanks for replying! Your feedback and support is a great addition and greatly appreciated!!! :hugs:

1 Like

Aw thanks Shaun! Heh. Was a little worried I’d sound negative. I’m really grateful for your original post pulling all this stuff together :smiley:

Thinking a little more on things we’ve done in Toronto…

Speakers

Realizing that having weekly speakers is probably for us a “volunteer management” strategy, as it provides the flexibility for the container of the hacknight to hold onto people who don’t currently see something for themselves in the night, or who don’t understand how to contribute yet.

In Toronto, people would sometimes stick around for months before committing to a project or starting their own. And speakers give space to do that in a non-awkward way: people can come, listen, then talk to the speaker or talk to people about stuff they heard, then join a looser discussion group, then come out for drinks after. But the speaker is a big part of what makes that possible imho.

(Of course, the above mostly applies to the before-times. Right now, the presentation is probably one of the few pieces of our hacknights that feels like it still words, and breakout groups are struggling.)

Skills Directories

We’ve tried to catalog skills or past projects, but haven’t felt real success with this. People moving around the space and having conversations with other humans has always felt more useful that an directory or resource we compiled.

I personally maintained an ideas/project directory on Trello, but it was mostly a personal resource that helped me run Civic Tech 101 and/or Dolphin Tank (workshopping project ideas). Others sometimes contributed, but it never really stuck


Anyhow, I’ll come back if anything else comes to mind! Thanks for starting this!

1 Like

One relevant effort to be aware of is the civic tech taxonomy

This will start to go into bigger practice in the next phase of the project index, but was originally begun as a resource that different brigade project management solutions could use to fill their dropdowns to make it easy to start speaking the same language

It’s been seeded with a bunch of initial values, and the idea is that we would publish this database automatically out from GitHub in various formats and accept pull requests to add tags, improve their metadata, add synonyms, etc

After a thorough review of all the tag sets already out there and in use, most of the initial lists were selected from DemocracyLab

1 Like

Thank you for the heads up, Chris!

Do you have a project in mind that exemplifies how this might work?
I think I get it based on the ‘Use Cases’ section of the readme, but I’m unclear on how it would tactically work.

There’s two immediate cases I have in mind for the taxonomy:

Selectable values

The taxonomy could be published in several formats (e.g. API, JSON and SQL) so that the various project CMS-like tools that brigades employ could draw from network-wide data for things like topic/tech selectors on user profiles and project profiles. We might even provide copy->pastable code samples with network-branded rich tag selector UI widgets that brigade organizers could use in their projects

https://codeforphilly.org/ for example has a tagging system for projects and people that is driven just by existing tags + freeform input, and it’s quite a mess and a headache to moderate. We could drop in the network taxonomy instead once it is robust enough, and direct people to submit missing tags there

This would both help brigade organizers build their tools quicker by giving them an outsourced tag set to plug in, and help align project databases between different brigades to use the same tagging

Cross-brigade project indexing

The brigade-project-index scrapes the official project lists of every registered brigade that has one, and publishes an open dataset that is updated hourly. Here is one tool available so far for searching that dataset: https://projects.brigade.network/

The topics list is a mess currently, with various alternate terms and spellings for the same things spreading out projects. This hinders new projects looking for relevant past work from finding everything that has been done before, among others. The taxonomy will offer the ability to list synonyms for each official term, and the index can use that to translate all synonyms to their official tag while building the database. So rather than wait for everyone to use the “right” tags, we can just gradually build up our synonyms in the taxonomy and collapse indexed projects into the official tags over time