Updates on Open Source Community Tools

All hail the Guidance (and Attribution) Tree!

The guidance tree is a concept that grew out of my days on the OpenWorm Community Committee. I have implemented a guidance tree for the Rokwire Community, and is available in Beta version for other communities to implement (HTML, Markdown) under a CC-BY license. Check out this 19-minute tour of a guidance tree based on the Rokwire Community.

A guidance tree allows new community members to find a starting point in your community easily, while optimally leveraging their skills. This is something I am calling Community Wayfinding. Community managers who want to adopt the guidance tree have to analyze their own set of community resources (Github repositories, web resources, and documentation) to see where members might fit in. Adopting a guidance tree of your own also requires a definition of community roles, which will be unique to different communities. In the Beta version, a user encounters a set of binary choices that bifurcate towards a specific contribution path. Future versions might map this possibility space to a VR (virtual) world where the options are presented as 3-D objects or as activity rooms.

Would you be interested in a system for tracing attribution or authorship on an open-source (or open science) project? When the formal release version of guidance tree is released, it will be accompanied by the Authorship Tree, an idea I worked on circa 2017 in the Orthogonal Research and Education Lab. The Authorship (or attribution tree) solves the problem of authorship order by showing the relative contributions of each individual in the form of a tree structure. This not only allows for primary contributions to be visualized, but also for deeper contributions (informal conversations, data sources, stakeholders) to be recognized. This is particularly good for publicly recognizing different types of contributors and whose who have been active at various levels of contribution.

Recombining your Technical Stack

During the month of March 2021, we considered how we might strive for a Full Stack community. The basic idea was that depending on the task one wants to carry out, there exist a series of possible technologies to achieve your goals. The challenge is to pick the best set of tools, for all aspects of your open source project. These tools should be compatible with one another, easy to learn/use, and provide accessibility to future contributors. 

But tools are constantly changing. Sometimes you outgrow your current set of tools. Some platforms are okay for small numbers of users, but become unmanageable as you community scales up. This is the nature of the constant tradeoffs one makes in managing a dynamic community. In other cases, tools simply cease to exist, forcing you to migrate to another solution. And sometimes a tool becomes unaffordable as your user needs change. So the question becomes: how do you go about changing out your stack? 

My personal preference is to stick to open source tools whenever possible. There are two reasons for this: it eliminates the cost constraint, and it allows for open source solutions to emerge from the user community. Your open source community might also be able to develop customized tools for such platforms, thus helping you keep your technology stack consistent. The Jitsi platform is a good example of this. Jitsi instances can be started through a web browser or mobile app, and Jitsi servers can be customized by specific organizations. 

When you do need to change out elements in your stack, the first step is to make sure that the solution works well with your other tools. For example, if you change your video conferencing tool, be sure to make sure your whiteboard (Jamboard) and file sharing (Ignite RealTime) tools also work well with this shift. Doing a series of contingency tests based on common use cases may help. Adopting OBS for screen recordings and streaming is an example of this. Once you know your tool runs stably and provides the desired output, then you will have fewer glitches down the road. 

Secondly, make sure that you community leaders (people most likely to run a community meeting) can use the new tool. You might offer a primer or training session to get people up to speed on the new tool, in addition to how it connects with other tools in the stack. This primer should then be available in the form of video and written documentation to the community, as your meeting and discussion leaders may change over time. Tools that visualize Github tasks and milestones (ZenHub) is one example of a tool with multiple dependencies.

A third step is to do an audit of how the tool is actually being used, to ensure that there is a match between desired functionality and the functionality that is available to everyday users. Perhaps your community is really interested in sharing files during their video meetings. This may require the addition of a new tool, or an addition to an existing tool. Only a post-implementation audit (or a quarterly solicitation of use cases) will reveal an actionable path.