Skip to main content

Building Block 6: Making Groups of Actors Visible to the Community and Keeping Them Continuously in View

Whereas Building Block 5 was about taking stock, this Building Block is about creating visibility ("community visualisation") and continuity.

The first task of community development is to present the current state of the community in all its diversity,

  • to get and keep an overview yourself,
  • to make this representation permanently present in the community, and
  • to open up access between groups of actors and members within the community.

A visual representation of the entire community or one that can be experienced with other senses helps to balance virtuality and decentralisation. If the community has a representation of itself in front of its eyes, it is easier for it to understand itself as a community and to build and deepen relationships within the community. It is important that this representation is constantly updated to reflect new affiliations, among other things. For new community members, integration into the community representation is a clear sign of "onboarding", and they can also be welcomed appropriately by other community members.

For community representation, choose practical and descriptive tools or media, e.g. databases, tables, mind maps, profiles (e.g. of stakeholder groups), maps, murals, infographics, publications, social media platforms and community logbooks. Here, the value generated by the overview is crucial; this must be balanced against potential overload from complexity, which is then no longer useful for community development. Here, too, it is important to choose forms of presentation that are as attractive as possible and to ensure that they are accessible to all groups of actors.

In this context, the task of Community Development is to maintain the community overview and its presentation, i.e. to find ways and tools for ongoing "community monitoring". Due to the complexity and data protection law, it may make sense to make certain extensive data collections accessible only to the community development team or parts of the community. For these collections, the costs and benefits should always be weighed up and a "mini-NSA" should be avoided. The careful handling of internal community data is an important trust-building part of community development. A related code of conduct could also be discussed and agreed upon within the community. If there is a good basis of trust, individual data releases can also generate affiliation.

ACCESS

For the ACCESS context, the following questions arise:

  • What visualisations and other overview representations already exist that clarify the interrelationship of all stakeholder groups? Are these representations common throughout the ACCESS context? How up-to-date are these representations?
  • Which visualisations are particularly suitable and attractive for representing the ACCESS community?
  • How can it be ensured that these community representations are permanently present and accessible to all relevant groups of actors?
  • Are there already approaches to "community monitoring" in the ACCESS context?
  • Are there currently uniform standards for handling internal community data in the ACCESS context?
No Comments
Back to top