This year I was fortunate enough to attend FOSDEM.
Since a project I work on recently made its 1.0 release and is scheduled to be part of the next Debian stable release this means it will plausibly attract more attention.
Being inexperienced in community engagement, I decided to attend various talks on this topic.
Building an accessible community (video)
This is mostly not relevant to Gitano because it is about how to run a conference and handle accessibility.
It was entertaining though, and a useful bit of advice, that little things like using gender neutral pronouns in text can help to foster an inclusive atmosphere.
As a result I will try to proof read my writing in case I unintentionally included non-inclusive language.
Overcoming culture clash (video)
This was a talk about some theory about what kinds of cultural differences there are, and some specific cultural differences that often cause issue.
It started out with a metric by which cultural attitudes about 6 supposed characteristics of culture can be quantified so the difference between cultural attitudes can be measured.
The speaker admitted that they weren't an expert on the topic so I couldn't ask for clarification of how some characteristics differed since my impression was that at least three of them overlapped.
More practical advice included:
- Communities are built one person at a time. So we should try to foster good relations with existing and new users.
- Local support groups should be encouraged, but should be helped to interact with the wider community by inviting members to events and visiting them.
- Get to know the cultural differences of local groups.
- Avoid real-time (face to face or IRC) meetings. Text is better than video calls, and asynchronous is better than synchronous since it is a lot easier to translate.
- Plan events with awareness of religious and national holidays so you're not accidentally excluding someone. For example, FOSDEM is set during Chinese new year, so can be problematic.
- Don't be afraid to ask if people have issues, but be aware that not wanting to impose is also a cultural value, so they may attempt to appease unnecessarily.
Like the ants (Growing communities)
There was a talk from a communities manager from Google talking about how to foster a community without driving it.
The gist is that it should emulate a hive-mind like ants, where rather than dictating direction you would provide feedback mechanisms to encourage what is wanted.
This is not relevant to Gitano since we will be part of any community that happens.
Open source is just about the source, isn't it? (video)
This was a talk from a community manager about a bunch of non-code parts of a project to worry about.
Trademarking
First was trademark handling.
For Gitano we've started well by picking a name that is not already used for a git server and created a logo that resembles no other git server.
We will need to ask anyone who names their git server Gitano to rename though.
Finding users
We need to go out and find potential users, rather than waiting for them to come to us.
Talking about it on social media may help, and getting users to talk about it would help.
As would submitting talks to relevant conferences.
Larger projects can submit an article to a relevant journal since journalists are lazy and will print articles to fill space.
I intend to speak about Gitano at more conferences as a result.
Supporting users
Supporting users is essential, you don't know who might be a valuable contributor so be friendly to everyone.
You can't always expect users to come to you, you need to go where they are, which may mean subscribing to Stack Overflow to see if Gitano is mentioned.
Retaining contributors
Non-coder contributors can be hugely valuable, since they provide support for other users and may be able to provide support in languages you don't understand.
Retaining contributors depends heavily on how responsive you are. If you can provide automated feedback on code style etc. it helps.
If a useful contributor is approaching burn-out, if you can arrange for them to be employed to do so then that's handy, this is not helpful for Gitano since we're not a big foundation.
There isn't much we can do before other contributors turn up or leave for this.
Managing infrastructure
If infrastructure is required for development then upstream must provide it, since contributors are even less likely to be able to provide their own.
If infrastructure is expensive then a tip jar helps.
Try not to spread infrastructure across too many systems, or at least provide a landing page to locate everything.
Have one place for recording canonical decisions, don't split them across mailing lists or wikis.
For Gitano we expect the canonical place for policy to be the wiki, so we're going to have a policy page and link to all the infrastructure from the wiki.
All Gitano's infrastructure is either free or cheap and paid out of the lead developer's pocket, so we don't need to think about a tip jar yet.
Expect to leave
Plan for your own exit from the project. Nothing lasts forever.
It is helpful if you can centralise contact details so they can be changed more easily.
For Gitano we plan to have a contact details page to centralise as much as we can, and avoid giving out the details of any particular person as a contact.
Deciding on communications channels
Given the discussion of various contact channels and the importance of using appropriate ones I asked the speaker if she had any tips on how to evaluate which to use.
I was recommended to decide based on:
- Which is easy for your developers to use.
Which is easy for your contributors to use.
Ideally by asking existing users what they would prefer, but otherwise an educated guess based on what the target users might want.
In Gitano we have opinionated developers who like mailing lists, IRC and RSS feeds, so to widen the support net we're going to add a link to webchat.