[gobolinux-users] Summaries of community engagement talks from LCA
michael at gobolinux.org
Sun Jan 31 17:14:31 NZDT 2010
I went to a few community-related talks at LCA last week, and I think
that there were a few points in them that we could benefit from. I've
been planning on writing this since before the other thread began, so it
isn't causally related, but parts will reflect on or be reflected on by
it. Also, this is long. Maybe you want to set aside some time later to
get through it. I'm recounting more or less everything from my notes in
order of appearance.
First up was Matthew Garrett's "Making yourself popular: a guide to
social success in (and for) the Linux community". I don't have notes
from this one, but he summed up the key message as: "Be excellent to
each other". He also stressed being clear about your community
expectations, and being prepared to enforce those norms.
Later, "Mentoring for fun and profit" by Leslie Hawthorn, from Google's
Open Source Projects Office and the person who administers the SOC
programme. This time I have notes. Although it was focused on
contributor mentoring I think a lot of it is more broadly applicable
too. I'm going to gloss over the mentoring-specific parts for the
moment, and focus on the general community- and contributor-engagement
On why it was a worthwhile investment of time and effort to seek out and
encourage new contributors: acknowledging privilege, increasing the "bus
factor", and avoiding burnout. The bus factor is "how many people can be
hit by a bus before your project fails?", but it's also referring to
other events that take people out of the loop; "life just happens". It's
not just about raw numbers but also about redundancy of knowledge: how
many people understand this chunk of code? That is an area where we can
sometimes have a problem. Burnout is another one, and she suggested that
getting new contributors (and mentoring them specifically) was helpful
in avoiding that both in terms of having more hands and the feel-good
Know your trolls, and also know your people who are wrongly helpful
through no fault of their own. The first is pretty clear, but also
encompasses trying to isolate and eliminate them. The second is harder
to deal with and only comes up occasionally here, but it leaves a bad
impression. It can be countered somewhat by documentation (on which,
more, oh-so-much more), but it needs to be addressed when it comes up
too. That means getting the right information out there and making sure
that both the helper and helpee get a hold of it so that things are
better in the future.
Check your tone: that can, ahem, sometimes be an issue, and it can
sometimes put people off. This ties into the last point too; corrections
should be careful. It relates to the content of posts too, even (or
maybe especially) off-topic ones. There have been a couple of incidents
in that vein in the past too. Just try not to put people off by what you
write, other than for solid factual and technical reasons.
Be welcoming, and point people to documentation when they have
questions. Also, have documentation. That's suitable for new users.
Documentation is something we don't really have enough of. Some areas
are better-covered than others, but there often is nothing from either a
user or a code level. That's something I plan to work on. There's also
the wiki, where anybody can help improve the docs. Also, we should make
note of what new users ask and incorporate the answers into the
documentation when they're not there already. Sometimes we'll be able to
get them to write that themselves, which is perfect because it means
it's automatically pitched at the right level for a newcomer.
As far as contributors: let them know their successes, acknowledge them,
and don't set too-high barriers of entry. I think we do all right on
those fronts. When someone is working on something, check in with them
regularly so you both know what's going on, and so they can get any help
they need. Delegate responsibility when they're working on an area, even
if the result isn't the same as you would have done it; also recognise
their skillset and try to direct them towards those areas.
Concrete suggestions for contributors: maintain a list of "easy" tasks
somewhere visible. We don't really have one of those, even on the
bugtracker, and we should. Triaging feature requests or minor bugs into
those classes shouldn't be too difficult or time-consuming. When someone
has fixed something like that, give them recognition and point them
towards something a little tougher.
Finally, "Open Source for Newbies: Attracting and Retaining Talented
People for Your Project" by Cat Allman, also from Google, with Leslie
again. This was focused more on users, but it had a lot of overlap with
the previous one as well. I'm just going to rehash my notes for the bits
First: show you're human; spare your thunderbolts. I think that was
already addressed, but it bears stressing.
All that glitters is not code: testing, documentation (!!), localisation
(which we don't really do at all beyond the installer; perhaps we
should), release engineering, UI, and support are all valuable. The last
of those especially; it's an avenue for recent users to help others, and
it means that response times are better while freeing up time for
development and other things. There are a few people on the lists and on
#gobolinux who routinely answer user questions when they can, and we
should recognise that contribution and encourage more of it.
Documentation is also helpful in that.
Marketing: never underestimate the power of a cute t-shirt. That's
probably a bit beyond us at the moment, but perhaps there are ideas
Community managers: I don't remember what specifically that referred to.
It should be something we can manage, though.
Now an important one: define the project's goals *and non-goals*. I
think that's really valuable, especially given the nature of the project
here. Listing out some specific non-goals especially could be helpful in
avoiding some of the situations that come up every so often. I think
this encompasses setting out a target audience as well, which has been a
little ill-defined and led to some difficulties. I'm not sure what
exactly those goals and non-goals are, but I think we could hash
something out that fit fairly well. Following up to that: beware of
project creep, and stick to the goals at hand.
Some more useful actions:
- Write a "Getting Started" guide. We have one (or a couple, in fact) of
these on the wiki, but it's not very complete and is more like a
post-install guide. We want something that's readable in advance, and
also probably two of them: one for new users and one for people
looking at getting into the code. We don't really cover either of
those cases at the moment.
- Make the source and licence information accessible from the homepage.
I don't know how you'd even find the source code to the tools from
there, other than through the URL to CreateRootlessEnvironment. It
could be more obvious, and licence detail is nowhere at all.
- Document the requirements for contribution. This means code, and it
means putting up-front information about what knowledge you'd need to
get into it in terms of languages and technologies. They also
suggested pointing from there to guides on those languages/etc
themselves to help bootstrap people.
- Encourage participation: call out for volunteers to do particular
tasks or generally, and have a list of "Starter" tasks somewhere.
- Manage the tone: make it welcoming, and make it like something you'd
enjoy contributing to.
- When there are development discussions on IRC or elsewhere, try to
summarise them to the list so they are documented and get a broader
On spotting future stars: that's people in the userbase who will one day
be developers too. A good sign of that is someone who volunteers.
Volunteering with *useful* suggestions is even better; doing actual work
is great. Another source is the people who file bug reports. It's more
effort for them to tell you something sucks than to disappear, so that's
positive involvement. Bonus points for having a patch attached, even if
it's not quite there yet. Getting their hands dirty is a good sign in
itself. Providing avenues for them to move further and for them to
become a part of the team is valuable as well.
On preserving the community and allowing people to accomodate themselves
to its norms: this is the more difficult area to write. There are people
who show up and violate the expectations of the existing community,
often accidentally, and the responses to that can vary. That can be
something as simple as top-posting to a mailing list, because they
haven't yet learned that that's not on, or it can be more complex.
Asking questions that are prominently covered in the FAQ is another.
The suggestion was "I know you didn't know this, but...".
Warning signs of trouble brewing:
- Not understanding the goals of the project. We are, I think, familiar
with this one. It would be helpful to articulate them directly
somewhere fixed though.
- Failure to pick up on the mood. Again, comes up sometimes.
- Asking unnecessary questions repeatedly. That has been especially
common in the forum, but it could happen anywhere.
And a big one: hostility and non-cooperation. That means things like
angrily demanding help, which we are all-too-familiar with, and
deliberately riling people. That last has happend much less frequently
so far, thankfully. We should try to correct that behaviour, but also be
prepared to suggest that they leave eventually. It'd also be helpful if
somebody other than me were willing to make that suggestion when the
situation arises, which hasn't really been the case in the past. It's
not really my forte. That comes back to enforcing the norms you've
To recap some of the most important points that I think we can follow:
- Define the project goals *and non-goals*.
- Compose "getting started" guides.
- Value and encourage non-code contributions.
- Get more people experience in the code, and more into the dev team.
- *Enforce* the community norms to preserve a weloming environment.
- Documentation, both user- and code-level.
- Documentation. Again.
- Be excellent to each other.
(Which isn't to suggest that the rest of the points aren't as or more
valuable, they just didn't jump out at me in scanning it for the
executive summary. I would prefer people read and responded to the body
That's the summary. From the mentoring/contribution point of view they
pointed to <http://en.flossmanuals.net/GSoCMentoringGuide>, which does
cover some material outside the SOC fold too (and is meant to be
becoming more generic as it's improved). Videos of all the talks should
be available in a few weeks, in case anybody wants to watch them in
their entirety. I have my actual notes for the last two electronically
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 835 bytes
Desc: This is a digitally signed message part.
More information about the gobolinux-users