Communityaufbau und -zusammenhalt

Communityaufbau, Organisation, Entscheidungen, Communities und OSS, Umgangston und Soziales

📖 How to manage and engage with large communities - A Checklist by Lorin Camargo and Mar Marín of Code for All

Code-for-all-cropped.jpg

Code for All is an international network of civic tech organizations. Our mission is to connect these organizations so they can learn from each other, share resources, and scale projects together, leading to greater impact in their local communities. 

Lorin: I started off my civic tech journey volunteering for Code for America’s Brigade, Code for San José, and am currently one of Code for All’s Co-Directors. As a Co-Director, I help shape communication, team, organizational, and fundraising strategy for the Network.

Mar: I began my journey doing professional practices with Codeando México. Following my interest to understand the intersecting relationship between political sciences and technologies, while implementing storytelling techniques, I got the opportunity to join Code for All as their Communications Assistant.


How do you manage to bring all participants together in such a large community?

  1. Have a central place for your community to meet asynchronously to share their work, discuss challenges, promote opportunities, and to connect about non-work stuff (it’s always good to have some fun channels 😉). Slack is our central meeting hub; it allows space for Code for All community members to connect with each other on their own time, and it’s also a place to find ample civic tech news, events and opportunities.
  2. Bring people together in at least one consistent, recurring way. We host an annual Summit, which aims to bring the global community together and allow space for showcasing projects, sharing knowledge and workshopping ideas. Along with all the other events we host, I find the Summit to be very important because it’s consistent. It’s something the community can rely on each year as a way to connect and share work. 
  3. Be aware of and accommodating to diverse needs. We spend a lot of time thinking about inclusivity and accessibility and always strive to create welcoming, safe spaces to bring people together. We often ask for feedback after events, or when we design just about anything, to make sure we are taking our community’s needs into consideration. It’s important to us that accessibility is something that’s built into the things we do, versus being an afterthought. We’re nowhere near perfect in this realm, but it’s a priority for us to always be improving. 
  4. Be aware of and accommodating to different time zones. Being a global network, we spend a good deal of time working around time zones and trying to accommodate everyone. We aren’t always able to make events work for everyone, but we often host multiple sessions of the same event in order to account for different time zones. We also record some events for post-watching, and like to create documents with concise, key take-away points so folks who miss sessions can quickly catch up without having to pour through notes that haven’t been edited down. 
  5. Use what you have. Our member organizations all have extensive communities and networks of their own. When we have something we want to spread throughout the global civic tech community, we always share the information with our members and ask them to pass it along to their communities. For each of our member organizations, we have at least one representative who acts as a point of contact between us and the organization. Having this point of contact makes it easy for us to share information and promote opportunities with entire communities in just one quick step. 

What are useful methods when engaging with a large community?

The Code for All community is both large and international, so one big thing we keep in mind is the language we use. We haven’t yet had the resources to offer all of our materials in several languages, and we primarily use English for communication, however we try to avoid using complicated jargon, so that our articles, opportunities, and resources are as easy-to-understand as possible for a varied audience. Similarly, we’ve heard from our member organization g0v, that in order to engage their large community, they often create multiple versions of communication material for any given event or opportunity, each version targeted to a different type of community member (for example, different age groups or professions, or reaching out to a student, or parents of students). You can find some brief key take-aways from a discussion around this here

How do you deal with conflicts within the community?

We have a Code of Conduct which explains what is expected from network activities, events, and digital forums. Luckily, we haven’t had many conflicts within the community, but depending on the severity of the conflict it is something we would either deal with as the Core Team, or would consult Governing Members of the network. In many cases, it would be important for us to try to understand all perspectives involved before solving the conflict. 

How do you do outreach? What are your methods when acquiring new community members?

  1. Annual Summit: Our annual summit is an amazing opportunity to showcase what our member organizations, volunteers and civic tech organizations around the world are doing and draw attention towards Civic Tech and the amazing projects around the world. The themes are always voted in, and are based on the interests of the community. The event has proven to be an occasion for organizations to gain interest in joining the Network.
  2. Communities of Practice (CoPs): These groups are about bringing network members, and organizations beyond the network, together to form groups and discuss common topics relevant to the civic tech ecosystem. This has proven to be an amazing opportunity for experts and people interested in connecting with other organizations working on similar topics to discuss best practices around civic tech projects.
  3. Events: This year we have been working on developing strong relations with key stakeholders that can draw attention to the intersection between Civic Tech and other relevant fields. We began the Civic Tech & SDG Webinar Series, an initiative that was born as our members have been advocating for data-driven development for years. To voice their work and collaborations that put the power of data behind delivering the Sustainable Development Goals, we have designed and organized the webinar series with key stakeholders in international and regional organizations. 
  4. Social Media Strategy: We have noticed people like to know what’s going on with our member organizations and also want to know more about civic tech in general. We try to share updates from the global civic tech community in engaging, fun and easy-to-understand formats. Understanding our audience is an important step in forming our social media strategies. For example, as a generalization, many civic techies are fans of certain branches of popular culture, and have fun interacting in conversations that use engaging themes such as Star Wars (here’s a quick example).

Do you recommend specific tools that help the community in collaborating (online and offline)?

Do you have advice for the cooperation between volunteers and paid staff?

We don’t have a lot of advice on this front from our team, but we recently held a small group discussion around this in one of our Support Squad meetings, where a volunteer from Code for Romania shared their thoughts. You can watch the recording of that discussion here (in English). 

How much self-determination do individual community members have (or how much is controlled centrally?)

Code for All is here to help connect civic tech organizations and individuals, and provide resources and opportunities to help their work. Our member organizations work completely independently from us, and have absolute self-determination in their work. We do not influence or control any aspect of their independent work, but act as a source of support to help advance, scale or replicate their projects. 

You also work on the fundraising side of things - are there any insights from that part of your work that could help other people who try and build a sustainable civic tech/public interest tech project?

We have an article that covers some highlights around this: Challenges & Tips for Funding Civic TechWe also held a sustainability workshop recently for some of our members, and the insights they learned are shared here

📖 Software for and by communities - interview with Dark Crystal Social Key Recovery System / CoBox

Mu and Peg worked on the projects Dark Crystal Social Key Recovery System and CoBox. In these and other projects they are working with a unique collaborative approach and a strong focus on community topics. They are sharing their knowledge and experiences on the topic in this interview.

In your projects - CoBox and Dark Crystal Social Key Recovery System - one can observe two different approaches towards the topic of community, a) the way the software is functioning because both projects are distributed software, i. e. they rely on a group of people using them; b) the developers form a collective/cooperative. Therefore, it seems like community is very important to you. How did you come up with the community approach for your software? Do you feel like distributed backups and collaborative clouds are more secure and otherwise advantageous - or is there even more to it?

There's a lot to it! Of course we are organised as a collective - which is a big part of it - but we will share more about that below. In terms of the software itself, the community approach isn't valuable to us along a single vector - there are multiple dimensions to it.

For Dark Crystal, the project has its roots in the needs of a very concrete community, around the 'Secure Scuttlebutt' social network. Many 'peers' (as they are called within the community, to reflect the p2p architecture of the protocol) had expressed frustration when losing access to their account. So we designed a social recovery system through open discussion on that platform. Even at the very early design stages there was a lot of input from the people who would later use it.

In terms of whether the decentralised architecture of the recovery system made it more secure, yes we would argue that distributing responsibility across a trusted group has security advantages over the traditional consumer-provider model. But we think the co-design / community-centered approach to software can be very useful regardless of what architecture you decide on.

For CoBox, the community aspects were multiple and resulted from a coincidence of threads coming together around an architectural idea. All members of the team involved in developing the project idea had long histories in the European cooperative and collective action movements and had experienced first-hand the frustration of there being few values-aligned digital tools available, forcing groups to rely on infrastructure that was in contradiction with their lived values.

At the time of its conception there was also increasing public awareness around surveillance capitalism and the personal, political and environmental dangers of massive centralised digital infrastructure, and therefore more tech funding was being directed towards supporting the underlying protocols on top of which such an alternative digital infrastructure could be built. Having stumbled across DAT, which was one of these underlying protocols, we decided to build on top of it to create the infrastructure we felt was missing from the communities we participated in. To do so, we deliberately set out to engage this community in the process of collaborative design.

So as we have come to understand it, 'community' can manifest in a few different ways. It can manifest infrastructurally in the software, socially in the team, and also in the input that spans these two components, so that both Dark Crystal and CoBox were developed in collaboration with the people they were being built for.

A fourth manifestation of community that we haven't discussed above, but will do below, is the community of developers who are building complementary digital infrastructures, to address parallel needs and based upon similar values. This has been where Dark Crystal ultimately found the most traction, as while the UX for distributed key backup came directly from the participation of end-users, it is other tech projects, needing to integrate a key-backup feature into their applications, who have become the primary consumers of this tool.

For a lot of users your approach might be unusual, too. How do those get involved, how do you “target” them? Is there for instance some sort of critical mass of users that you need in order for the community to grow from within, i.e. without you having to actively acquire new people?

We are acutely aware of the difference between the information available to big corporations for determining preferences and the tools they have to collect usage-data vs the capacities that small community projects have to do so. It is therefore significantly easier for a big corporation to create an 'ideal' product without requiring much conscious participation from any of their users (through, for example, mass A/B testing and the like). As a small team working on a project and attempting to use tools and practices that align with a particular set of values, it is much more important to speak with people directly, to find out what they want and need, and often these interviews and testing sessions reveal ideas and perspectives that had never occurred to us before.

In terms of finding users to help us design the product, in the case of CoBox (in which we more actively had to 'target' people) we used the channels that the cooperative movements we were involved with had already set-up. We posted on forums, spoke at a community event and contacted people we personally knew from within that milieu. However, we are aware that unlike the data that corporates are able to amass, our process requires a commitment of time from end-users, who are all busy with their own projects and work and community building activities. We have until now always managed to compensate users for their participation, and we make an effort to plan the sessions with an eye towards efficiency and respect.

If the tools being built accurately identify a need and solve the problem in an effective way then what we have seen is that a kind of network effect develops off the back of that. Because of the open-source nature of development, projects are able to tap into each others' work, rather than a particular feature being siloed into a single application as a 'USP' over the offer of a competing app. This is what happened with Dark Crystal, where we are still being approached by projects that have heard about the key backup tool through word of mouth or shared communication channels and would like to integrate it into their application for the benefit of their users.

So yes, there comes a point when the community around a project exists without needing much active publicity. But rather than a critical number of users, it is probably a critical level of interest - you can have a small number of people who are very enthusiastic or actively involved, and it is enough to build a project around.

How do you organize your work as a cooperative/collective? Is it very different from a traditional firm? How did you come up with it and why did  you decide to organize your group in that way?

Our decision to work this way is rooted in our belief that work can and should be fulfilling, rather than alienating and exploitative. And in our understanding (which is ever adapting and developing) this derives from a feeling of shared ownership, agency, belonging and mutual respect between individuals who are standing on level ground.

Workplace dynamics can be really debilitating when there is no possibility to feel heard and engaged in your work, or when that work conflicts too sharply with your personal values and with what you would like to see exist in the world. At least one aspect of which is the case, as far as we know, in many workplaces, technical or not. Of course we recognise that especially among tech workers there can be some appeal to forgoing the above for work that is extremely well compensated. But such work can often also conflict with other personal and social values, making the compromise even less appealing in sum.

Internally, we try to organise in a way that there are not big power imbalances in terms of making decisions or accessing resources like servers or the bank account. There are, of course, many complexities to working this way. One challenge for a group that works like this is the process by which someone joins or leaves the group. When someone who is helping on a particular project becomes more involved, there needs to be some formal process which makes it clear at what point they become a member.

Maybe you could also tell us a bit about your approach to design and what your decision process looks like in that area. E. g., on the CoBox website you write about the peer-design process - what is that?

Big corporations can do massive and continuous user-testing, unbeknownst to the user. Sometimes this is ugly and manipulative (for example, Facebook's psychological impact testing), but it doesn't have to be. When you do not have the capacity to do this kind of research, you have to rely on smaller and more personal processes. This is emphasised in the start-up community as well, where the available resources are still grand in comparison to what we have access to, but much smaller than what established companies have access to. The co-design process has a lot of benefits. It not only allows you to design and create a product that the people you are building for actually want - taking into account their more subtle and difficult to identify needs, but it also allows you to very consciously choose to prioritise particular communities who may be underserved by other products available.

There are of course also challenges with co-design and user-testing. For example, when you are developing a new architecture, and developing a UX for it, the fact that it is quite far removed from what is already familiar, comfortable to and expected by people can be a challenge. The UX-design coaching that Dark Crystal received from Simply Secure as part of our funding was really helpful towards addressing this challenge, because distributed key backup or recovery involves some concepts which are quite unconventional. It was therefore difficult for us to find terminology and UI patterns that were not too confusing and the design coaching helped a lot with that.

Another challenge that we faced is that sometimes what users want doesn't align at all with what you want, or what you thought they would want. This happened to us during the second development phase of CoBox. After our first release, we had a clear roadmap that we thought prioritised what users would need, in order to begin using the tool. Our co-design interviews revealed that this was not the main or most important barrier to usage at all, and an issue that we had completely overlooked was far more prominent in their decision-making process about when or whether to begin using the app. Fortunately we were able to pivot in this instance, to prioritise addressing the issue that they raised.

📖 Interview mit Tobias Zwick (OpenStreetMap)

Tobias Zwick ist der Autor von StreetComplete, einer Android App, mit der man ohne weitere Kenntnisse direkt etwas zur OpenStreetMap (OSM) beitragen kann. Dank der Förderung durch den Prototype Fund (Runde 8) konnte er die Entwicklung 2020/2021 intensivieren. Mittlerweile wird die App von mehr als 22.000 Menschen genutzt, was sie nach Anzahl der Nutzer*innen zurzeit zum zweitbeliebtesten Editor für OpenStreetMap überhaupt macht. Auch erhält das Projekt schon von Beginn an (seit 2017) zahlreiche Beiträge von Mitwirkenden.

Was, denkst du, zieht Leute in die OSM Community? Und warst du vorher selbst in der OSM Community aktiv?

Was den Zugang zu freier Information angeht, ist OpenStreetMap sicherlich ähnlich wie Wikipedia. Allein der Gedanke, hoffentlich hilfreiche Informationen für andere Menschen frei zur Verfügung zu stellen, ist sicherlich für viele Motivation genug.

Mir macht es zudem Freude, die weißen Flecken auf der Karte zu füllen. Insbesondere wenn man vor Ort ist, fühlt man sich dabei regelrecht wie ein Entdecker. Gleichzeitig ist es motivierend, das Resultat meiner Arbeit hinterher direkt auf der Karte zu sehen - man hat etwas geschafft! Ich hatte darüber 2013 in meinem damaligen Reiseblog geschrieben.

Letztlich ist es auch ein netter und zumeist wenig fordernder Zeitvertreib, denn um zur OpenStreetMap beizutragen muss man kein*e Expert*in sein.

Wie bist du bei der Einbindung der Community vorgegangen? Reicht der Anschluss an OSM oder bist du selbst darüber hinaus aktiv geworden, um Menschen zu erreichen?

Vor-Ort Informationen beizutragen war schon immer recht aufwändig und benötigt technisches Verständnis zu OSM. Die App ändert das. Das heißt, der initiale Erfolg der App, überhaupt wesentlich genutzt zu werden, ist mir dadurch, dass ich zufällig den richtigen Riecher hatte, was dem Ökosystem fehlt, quasi in den Schoß gefallen.

Dieses Projekt ist insofern speziell, als dass es nicht für sich allein steht oder stehen will, sondern sich in eine größere Community integriert. Potenzielle Nutzer*innen gibt es also viele. Das schränkt jedoch ein, was man machen kann - und was nicht. Die App muss sich der bestehenden Community unterordnen, um akzeptiert zu werden und nicht auf den Prüfstand zu kommen. Das musste ich von Anfang an beachten.

Damit die App und die Beitragenden in der Community nicht als Fremdkörper aufgefasst werden, war es allein schon wichtig, die OpenStreetMap-Community von Anfang an einzubinden. Dazu gehört unter anderem eine Präsenz in verschiedenen Community-Channels, eine ausführliche Beschreibung der App im Wiki mit Unterseiten, damit auch für Leute, die die App nicht nutzen, nachvollziehbar bleibt, was mit dieser App getan wird.

Die Einbindung in die Entwicklung, die meiner Erfahrung nach am besten und als erstes funktioniert, ist Crowdsourcing der Übersetzung. Dank einem dezenten Hinweis auf der Projektseite und der verlinkten Wikiseite wurde die App bisher in 46 Sprachen übersetzt - zu 100 % von Beitragenden.

Letztlich hat die App aber auch neue Zielgruppen erreicht, die bisher noch wenig mit OpenStreetMap am Hut hatten: Leute, denen das Beitragen bisher zu technisch oder zu aufwändig erschien oder auch Leute, die sonst eventuell eher Pokemon Go oder Geocaching als Zeitvertreib betrieben hätten.

Diese neuen Gruppen zukünftig (mehr) in die OpenStreetMap-Community im Ganzen zu integrieren, würde sowohl die OpenStreetMap Community bereichern als auch die Akzeptanz für die App und ihren Anwendungsfall weiter steigern.

Hast du Tipps für Leute, die mit ihrem Projekt eine Community erreichen wollen?

Ja, habe ich. Aber ein Disclaimer: Was für mich funktioniert hat, funktioniert vielleicht nicht für Andere. Also, Ratschläge immer mit Vorsicht genießen!

Wie schon erwähnt ist StreetComplete etwas speziell, weil es sich in eine größere Community integriert. Dadurch wurden gleich zu Anfang viele Leute erreicht. Sich einer bestehenden Community anzuschließen oder daraus hervorzugehen ist möglicherweise auch für andere Projekte ein hilfreicher Ansatz.

Die erste und größte Hürde ist natürlich aber erst einmal, ein Produkt zu entwickeln, das auch wirklich genutzt wird. Eine Idee kann ein Hit oder ein Miss sein. Generell hat ein Projekt, das ein bestehendes erfolgreiches Produkt erweitert oder ergänzt, natürlich bessere Chancen, genutzt zu werden.

Daher - ganz im Sinne des Prototype Funds - ist es wichtig zuerst ein Minimum-Viable-Produkt (MVP) zu erstellen und dieses publik zu machen. Nur wenn das auf positives Feedback stößt, lohnt es sich, die Idee weiterzuverfolgen. Wichtig ist, dass der Umfang (Scope) des Produkts ganz klar auf das Minimum abgegrenzt ist und in sich geschlossen ist. Ein Produkt, das unfertig wirkt, will niemand benutzen.

Deswegen dokumentiere öffentlich, was Ziel des Projekts ist, was zum Scope gehört - und was nicht, sodass potenzielle Beitragende wissen, woran sie sind (Beispiel in StreetComplete). Was ist erwünscht und was nicht? Eine öffentliche Dokumentation hilft auch, selbst in den selbst gesetzten Schranken zu bleiben, also Feature-Creep und mehrere gleichzeitige Baustellen zu vermeiden. Meiner Erfahrung nach ist es am besten, wenn das Projekt immer in sich geschlossen und "fertig" wirkt. Baustellen wirken auf Dauer abschreckend für Nutzende und auch Mitwirkende.

Wenn es konkrete Dinge gibt, die Beitragende tun können um dem Projekt zu helfen, dann schreibe auch das auf. Die Energie von (potenziellen) Beitragenden muss gelenkt werden: Sie müssen wissen, was sie konkret tun können (als Beispiel CONTRIBUTING.md in StreetComplete). Sonst ist die Hürde viel zu hoch.

Wenn es in deinem Projekt einen öffentlichen Issue-Tracker (z. B. GitHub) gibt, könntest du auch Labels einführen, mit denen du bestimmte Tickets markieren kannst, z. B. "needs PR", "help wanted", "good first contribution" usw.

Das ist alles, was mir an konkreten Tipps einfällt. Es gibt noch einige weitere Richtlinien, an die ich mich halte, wie zum Beispiel leicht lesbaren aber modernen und gut dokumentierten Code zu schreiben, damit mögliche Beitragende einen einfacheren Einstieg haben. Aber ob das nun wirklich entscheidend ist, weiß ich auch nicht.

Die oben genannte Dokumentation auf der anderen Seite hat garantiert einen Unterschied gemacht (am Anfang des Projektes fehlte diese nämlich und das hat sich bemerkbar gemacht). Es ist eben wichtig, dass die Entscheidungen, die man als Leiter in einem öffentlichen Projekt fällt, transparent und nachvollziehbar bleiben. Man kann nicht allen alles recht machen, aber versuchen zu erreichen, dass sich niemand verprellt fühlt und alle, die etwas beitragen, ein gutes Gefühl dabei haben.

Ist die Einbindung in die Community ausreichend, um StreetComplete langfristig zu halten oder braucht es noch mehr Ressourcen?

Tja, das langfristige Warten von reinen FOSS-Projekten ohne Geschäftsmodell ist natürlich immer so eine Sache. Es hilft, bei der Entwicklung darauf zu achten, dass das Projekt möglichst wartungsfrei durch Automatisierung und Nutzung von stabilen Frameworks überleben kann. Wenn das Projekt genug genutzt wird, finden sich mit der Zeit ggf. auch Mitstreiter*innen, die dabei helfen, das Projekt aktuell zu halten.

Letzteres ist bei StreetComplete der Fall, allerdings nützt das eher der Erweiterung des Projektes um weitere Features als der Wartung an sich.

Außerdem sind sowohl OpenStreetMap als auch Android als Ökosystem sehr instabile Plattformen, sodass der Wartungsaufwand sehr hoch ausfällt. Instabil ist Android in dem Sinne, dass sich u. a. die empfohlenen Frameworks ändern, sie teilweise ganz und gar als veraltet markiert werden, weil sich das Verhalten von Android von Version zu Version ändert und weil die App den sich stetig ändernden (und immer strenger) ausgelegten Richtlinien des Play Stores entsprechen muss.

OpenStreetMap ist außerdem instabil in dem Sinne, dass der Konsens darüber, wie etwas richtig einzutragen ist, sich ständig wandelt und erweitert, weswegen die Logik entsprechend ständig angepasst oder zumindest in Diskussionen verteidigt werden muss.

Dennoch würde ich sagen, rein die Wartung der App ist dank der vielen Spenden die ich über Liberapay, Patreon und Github Sponsors bekomme, gesichert, selbst wenn ich keine Freizeit mehr in dieses Projekt stecken kann.


📖 Linksammlung Communityaufbau und -pflege

🎧 Maxi Richt und Benjamin Seibel zu Förderung, Communities und digitalem Ehrenamt

In der dritten Episode des Public Interest Podcast geht es um die strukturelle Seite der Public-Interest-Tech-Entwicklung, also um Förderung, Communities und digitales Ehrenamt.

Neben einem Input zum Thema sprechen wir mit Maxi Richt aus der Code-for-Germany-Community über seine Erfahrungen in der digitalen Zivilgesellschaft. Außerdem reden wir mit Benjamin Seibel vom CityLAB Berlin darüber, was nachhaltige Förderung und eine größere Akzeptanz von Open Source bewirken können.