This list is awesome, thank you 
Rust Berlin has a surprisingly high yield by actively writing a special invitiation to groups like Rails Girls, PyLadies, Unicorns in Tech etc. that mentions our goal to open in a direct way. The invitation letter for the Rust 1.0 Party can be found here: Rust party invitation Ā· GitHub
5 Likes
FYI: Iāve carved off a separate thread to focus on the creation of a community subteam. I want to make sure we donāt lose momentum here, so please head on over and give your ideas!
I've actually been tempted to suggest the use of Slack for Rust. The big barrier here is that free Slack teams don't have full logging (they only preserve the last 10k messages), and paid Slack teams require paying per team member, without the option to have unlimited guests. I've actually already mentioned to some Slack engineers that I wish they had a plan that was appropriate for a community group (i.e. unlimited guests) that still needed full message archiving.
Of course, someone could write a bot that archives all messages, just like how IRC conversations are logged today (I'm actually mildly surprised botbot.me hasn't already done this). And that would make free teams quite usable.
2 Likes
Is logging even necessary for a Q&A channel? It's important for a project channel and some logging is needed in case of issues, but I know many people that prefer non-persistent places.
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.
8 Likes
The fact that Slack is not an open protocol with free implementation bums me out and I would be unhappy to see a lot of Rust community stuff move there. It doesnāt even look like you can self-host the server?
Thatās a very good reason not to use it as a main place - still, an offer is an offer. Itās similar to Windows in that regard: itās closed, itās proprietary, but if you want to reach people, you have to deal with it.
1 Like
Scrollback is a pretty neat IRC-like thing with a refreshed interface.
It can also connect channels with IRC channels (Iāve tried this out; itās pretty neat, but a bit fiddly to set up) so that they effectively mirror a channel.
Itās also open source, and I believe free to use for most purposes
Full disclosure: I am acquainted with some of the people who work on it (though I donāt work on it myself)
I took a look at scrollback for a similar purpose (a non-technical fandom community) and itās lack of private messages (or private group messages) might be a blocker? it also doesnāt seem to allow guests to change names.
Considering that open-sourceness seems to be an important thing, Iād like to add that onruby is a very neat open source project.
Iām always a bit split: meetup is awesome at dragging people in, but bad in all other aspects (including spammers being able to pose as UG organisers and similar).
I also think that there is merit in having community offers done with projects that we can actually change and that hold the same spirit. Still, effectiveness is an important part of the equation. Scrollback indeed looks nice!
Iād like to note that we are a moving further and further away from the spark of the issue (lack of Diversity, Communication problems) to purely technical things like tooling. Iām very much for moral discussion (e.g. do we want to officially support a commercial non-OSS vendor with blessing them by running our communities through them), though. I mean, everyone is still allowed to open up a Slack or Meetup group or whatever and there is no need to get everything blessed by ācommunityā.
Still, there hasnāt been much talk about the structure, actual formulation of goals and what happens if those goals are missed. What happens if Mozilla works against those goals? What is this teams actual power? Can it overrule other decisions (e.g. other teams just donāt care)? What kind of message do we want to send?
If we donāt do that, weāll have the same anger again in 6 months again.
Sorry, I'm not sure which topic specifically you're referencing here -- do you mean with the proposed community subteam in particular? I've started a dedicated thread for that which at least sketches some of the potential roles, but agree that they need further elaboration. (And I would like more people to speak up on that thread :))
In general the structure of the teams is laid out in the governance RFC; each one (except moderation) is led by a core team member. The core team (not Mozilla) is ultimately steering the project, and any cross-team disputes would be handled at that level. I would hope that the community team's primary role with respect to diversity would be a more positive one: things like establishing a standard meetup and conference code of conduct, leading/organizing outreach work in various guises (many of which have been covered in some concrete detail already), and being a place for people doing local community work to share notes with one another. It would also be responsible for maintaining visibility and lines of communication between e.g. the core team and various community organizations at different scales.
Anyway, not sure if that addresses the concerns you were getting at, but it's the primary structured/formal way I currently have in mind for enshrining community building/support and inclusiveness in a first-class way for the project.
2 Likes
Meandering will happen in any discussion like this.
The core team put up a good start on a proposal for a community team on the other thread. This thread is about events and plenty of links and advice has already been shared.
The other teams except the mod team make purely technical decisions. I don't think it should be able to overrule the mod team (though they are of course free to question a decision and bring it to the light of the others), but I do think that once formed it should work closely with the mod team and we should probably consult them in cases which they may have interest in. Moderation and community go hand in hand so I expect we'll be working together on more than just that, in both ways.
I believe the goals will be decided by the team once formed; though it would be nice to have a list of goals to work off of. The ideas in the other thread do give some rough goals. Pushing for more concrete goals there is something you should do if you feel it is important (I personally feel that these goals should be decided and published by the team once formed -- the moderation team is working on a similar set of stuff to publish)
I don't think Mozilla can anymore. Rust is no longer a Mozilla project; though there are employees working full time on Rust (just like some Intel folks work full time on Linux), and there is still a large representation of Mozilla in the core team. The new governance structure splits out responsibility and decision making power. I don't expect the core team (stand-in for Mozilla since that's the closest we have) to suddenly go off on a tangent in such a case.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.