Hi. Some (like @erickt) have asked me to document our current efforts and approaches with @rustberlin. This thread is probably the best for that. Note that this is mostly local groups only.
First of all, as a bit of context: RustBerlin should be considered an offshoot of other efforts: Johann and me both come from other projects, Nodeschool and the Berlin Ruby Community. I am board member of Ruby Berlin e.V. and used to be core member of eurucamp and some other conferences.
I am also one of the persons maintaining the Berlin Code of Conduct and translated the Conference Code of Conduct to german. I prefer the first now, although it’s certainly not without issues and more specialized ones are sometimes better.
We’re a young group, so direct learnings are small, but there are some.
I recommend having a CoC. Especially I recommend to have read it and played through a few things that could happen in your head. This makes sure you are steady and fast when it actually happens. It’s also an external statement of morals as much as it is a list of rules. It also helps to have all organisers on the same page.
Also: if diversity and a welcoming environment is of any interest to you, take extra care about your outward communication: it’s the only thing people see. That also means that you should always have it in your head when planning action and not try to bolt it on later.
Walk a lot: speaking to people in person is the best way to grow your community. This includes giving talks, but much more: go to other events and speak to people over a drink. Especially if you want to practice outreach, a personal impression is much better then anything else. If you don’t feel good doing that, try to find a person who likes doing that as fast as possible.
Recruiting people works best if you are open about your intentions and have a unique role for them to fill. Why not come up with a big idea first and then find someone to do it? It’s often easier then the other way around. When recruiting, try to work against your biases and try to gravitate for people that you run danger to ignore. Finding team members that are not like you is gold. The more people you have on your project, the more regular things you can do, obviously.
Research you local community: why are people attending your group? More importantly: why not? Give the last question more thought then the first. It’s also the harder one: you have to find people that don’t attend willing to tell you why. Get a reputation to listen to that feedback. A diverse team is important here: members can reach to other groups better and see problems you don’t see.
And with all that feedback: get creative! For example, we got the feedback that multiple people couldn’t attend because they have family or other commitments every wednesday, where we wanted to run our training group: so we started to change the days of the week. That means that some people can’t always attend: but others can. That was all that was necessary. Other things are regularly forgotten by organisers and promote a global sense of exclusion: for example, many meetups don’t document if they are wheelchair accessible and many don’t care if they are. Communicate such things directly - in those cases, you might pay for the sins of others. Appreciate that and work against, don’t be all “well, we ensured, but no one came” if you didn’t propagate it. That might still happen.
When it comes to outreach, make sure that you have a serious stance on that first. Then, propagate that to other, more specialized groups and see that they can help you out. In our case, those are the local Rails Girls groups, PyLadies, but also things like Unicorns in Tech, a local LGBT community. Similar groups can be found for almost everything. Also, if you know someone local active in that sector, ask if they would like to meet you and explain you things a little and maybe refer you. Don’t feel entitled for it and be prepared that some will ask for something in return. That’s perfectly fair - consulting is consulting.
Also: are there groups similar to yours? If you are running a training group in a room that is half-empty, fill the rest with another group. For example, we have an offer to do our learners group together with OpenTech School, which means that we regularly have a room and some more people that help with desks and everything.
Local groups don’t need to be the classic meetup style with 2 talks, pizza and drinks. Small training groups, hack rounds and similar are also very appreciated and easier to join for beginners. We run the classic meetup style less often then the training group. Those are low-effort, but more often. They cost you less time, but can be set up by acquiring a key to a room. If you revolve around some kind of technology, I recommend you work on training groups first.
Beginner-friendlyness is often ignored: assume that most talks of interest to your regulars are well above the level of anyone just dropping by. You can still integrate them - the Elasticsearch Usergroup Berlin for example runs a beginners cours on the side while the talks run. That means that beginners can skip the talks and still interact with the rest later.
And finally: Go to other events. If you are a small group, form joint ventures. For example, we will run a tent village at Chaos Communication Camp together with NodeSchool and Ruby Berlin. This also allows their reputation to reflect you a little once you are still trying to build it.
Be aware that local groups in internet communities are often ignored/forgotten. You really have to like doing that ;).
You might have noticed that I lost no word about how fancy the room has to be or how good the food/coffee: that’s really secondary. But still, try to find what people love.
