I was thinking about better intentional outreach and clarity around utilizing volunteers at different commitment levels.
A volunteer with only small time commitment might be a net cost if we invest in training time, and yet they end up not contributing much. Such costs are okay if 1 out of 10 volunteers like that become substantial long-term contributors. But being cautious of the costs and targeting our time well is important. Sometimes, the sort of training we do can be effective at helping us focus and process something, in the sense that teaching others helps us reinforce our own work. But maybe we should explicitly aim for that with the expectation of that sort of process.
Of course, a volunteer with less training needs (because they are familiar with the areas or more self-driven etc) is less costly. And we can also do well with the sort who can provide us useful feedback and energy or who brings useful neutral skills like facilitation help.
For those with medium or higher availability, more training and onboarding might be worth the cost. But we should be cautious about how we invest. We have had cases where someone sincerely intended to put in more time but ended up not contributing much and just moving on.
How can we best plan our outreach around these tensions?
I haven’t searched for the best guides or other resources. Any good links?
My knee-jerk “solution” would be “make the training reusable” so that those that need it can (e.g. watch videos) and less team hours are used on people who may or may not stick around.
+1 for more re-usable onboarding info. Also, we should make it easier to contribute without having to do so much onboarding! We’re not (exclusively) talking about new team members here, just volunteers who want to help out here and there.
You don’t need to know anything about Snowdrift.coop-the-project to answer my css question, just learn a small and isolated part of the code base. But nobody would know that task existed if I hadn’t taken the time[1] to write the post… and even still, I’m not sure how someone who learns about us and wants to help out would get there — it takes quite a few clicks to get from our home page and that post, even if you know the shortest path to get there.[2]
Reflecting on my engagement with the other projects I have contributed to,[3] they all follow the exact same path:
I use the app.
I report a bug or make a feature request on their issue tracker.
Repeat several times, until…
Via the issue tracker, I become familiar enough with the state of the project that I am able to answer other people’s questions, or point out when a newly-filed issue is a duplicate of an existing one.
At some point I care strongly enough about a feature/bugfix to try implementing it myself.
The only, slight deviation is with Snowdrift.coop itself, where steps 1 and 2 were replaced with “read the website/wiki” and “contribute to mailing list discussions” respectively.
If we can figure out how to un-block the path to contributing, then we have a good means to identify long-term contributors — people who already have become involved & contributed.
From this perspective, it’s important to get launched, to increase the number of people who use/care about Snowdrift.coop, and make it easier to engage with our issue tracker & forum. While there is room for improvement, I think the Discourse setup is mostly good enough[4]. On the other hand, the current GitLab setup is confusing even to team members. But I already talked about my thoughts on that in Roadmap format reflection
I don't remember exactly how long I spent on it, but at least an hour ↩︎
Homepage footer -> contact page -> forum homepage -> development category -> that post. But a newcomer wouldn't know to take that path. ↩︎
But the big point here is that curating this list is something to do better, so when we are onboarding someone, we should make an explicit goal of using the opportunity to end up with a better list. As in, “welcome, we have this list but it may need some grooming, so that’s where we’ll start…” etc.
My initial reaction was, “On the home page, before people even know what we’re about? That’s crazy!”
But now I’m wondering if it actually would make sense. Or even further: What about putting it on every page, in the navbar? Something like the “devel” header on the prototype, but modified like this:
There’s more than just CSS or whatever, we could make a rotating message with different emphasis even. The core message is, “this is a volunteer effort, and there’s probably ways for YOU to help” or similar.
I put together the screenshot above in 5 minutes, and it would probably take another 10-15 to get it looking good-enough on screens of various sizes. A changing message introduces many more variables and would take somewhere between 2x and 10x more work. That’s not an efficient use of the limited time of our volunteers with css experience. We can do that after we have more volunteers with css experience
We can use different text, of course. “We can use volunteers, especially those with css experience. Can you help?”
For everyone’s info: this thread is super high priority for me and I keep extending the bookmark, but will definitely get back to it post SeaGL with answers to some of the things that have come up.
