by @elb last updated: 2022-02-15T19:21:00Z
These recommendations are for shared Network infrastructure. This post seeks to define what qualifies as shared Network infrastructure, to make immediate and long-term recommendations for tools to adopt, and to provide some initial thoughts on how Network members can get involved and share ownership over these recommendations.
Right now, the best way to give feedback on the recommendation is to comment on this post. I’ll edit this post if and when we have additional ways to get involved in this work.
Shared Network infrastructure are the tools, systems, and processes we use to communicate and organize together across the Network. This recommendation does not seek to be an exclusive or all encompassing guide, but rather to create a starting framework for the Network to continue building on.
The working definition I’m using for these recommendations also includes shared infrastructure as tools, systems, and processes that Network members use and engage with. Tools, systems, and processes that are primarily only used by CFA staff are not included in this memo, but if there’s interest I’m happy to share more.
Current shared Network infrastructure looks like using the following tools:
- Slack for realtime conversation
- Google calendar for events
- Google docs for meeting notes
- Google docs for documentation
- Zoom for hosting meetings
- Discourse for long form conversations & announcements
We do not current have a shared process or tool for project management across the Network or on Network-wide projects.
These recommendations are also informed by the idea of the Digital Trinity as created by TheHum Distributed Organizing course.
DigitalTrinity-200317-145600.pdf (159.5 KB)
This memo seeks to place more emphasis, energy, and attention on platforms that are built for distributed communities like our Network. We also seek to share resources and knowledge more widely. This recommendation seeks to better utilize our best asynchronous, distributed communication platform of Discourse.
Here’s why Discourse is particularly useful for documentation and creating wikis:
- Access: There’s no ownership or document permissions to edit in Discourse. It is also easy to create a freely editable post like a wiki that any member can contribute to.
- Categorization of network-wide resources: By having documentation in a system like Discourse, someone could easily find resources by searching for specific tags. They could easily navigate and link from one project to another. Other documentation systems (Notion, Google Docs, GitHub) do not provide this key functionality.
Timing: This is ready to use! Check out this guide post & video to get started.
We’ve long struggled to create a way for network members to organize their own events, and to have a centralized place to advertise and share meetings, workshops, and other events. In Discourse, any member can create an event and link to it. This allows for a “hands-off” distributed way to share events, without needing staff time to coordinate.
This feature on Discourse is not yet working exactly as we need it. For now, you can see the Upcoming events calendar, and anyone can add to the events. But there are some key features & functionalities that we’re still working out. If you want to help out with this calendar issue & like spelunking on Discourse support forums, reply to this post or reach out to me! This existing Discourse post informed some of this recommendation.
Timing: The upcoming events calendar is live right now, as a demo. We hope to get the technical issues on this fixed by April to adopt Network-wide calendar.
3. Establish GitHub as the place where project milestones, goals, issues, and timelines are tracked.
We have long needed a way to easily identify ways for people to plug in to projects and for volunteers to self organize across the Network.
Adopting GitHub for our projects will require investment of time and resources from staff. We also have ample resources at our disposal to better train people on GitHub. I believe the benefit outweighs the investment of time.
These are Network wide projects that this could apply to:
- National Action Teams like T-911
- Basecamps - a new supportive structure we’re rolling out in 2022 through Network ReVisioning
- Committees like the Brigade Congress content committee
- GitHub issues are an effective way to allow someone to take up a task quickly, without needing to have training or staff time. Here’s an example.
- GitHub milestones can provide the collective sense of progress that these big, distributed projects often lack or are delayed by staff time in sharing. Here’s an example.
- GitHub allows volunteers to see contributors to a project, the number of pull requests and tasks completed, and many other options to both gamify the experience and share success if used properly.
- GitHub can utilize version control. A volunteer could submit code or data that needs to be reviewed. This would help establish quality control.
- Many of our volunteers already use GitHub and have an account.
- Add yours here
Here are some hopes and assumptions built in to this recommendation:
- I hope that by using GitHub for Network-wide projects, we can create high quality, replicable resources that any Network volunteer can reuse and remix as they see fit.
- Given that GitHub is more technical than most tools, but is also highly useful for organizing in a decentralized manner, an assumption I have is that Network members would be excited and interested in helping others better learn and use the platform.
This recommendation was informed by comments & dialogue on this post.
Timing: This would not be immediate and would ideally be rolled out through a series of pilots in 2022. If you’re a volunteer who knows GitHub really well, or if you have a particularly amazing repo to share, please comment on this post or reach out to me to get involved.
Do you have ideas for recommendations we might add to this? Or thoughts on these recommendations? Reply to this post!