---
description: Building a distributed governance practice with GitHub
---

# Our GitHub Tracking System

## Adapting the GitHub Issue Management System

[GitHub ](https://github.com/)has been predominately oriented towards software development where issues are typically recorded stages in a software development lifecycle (e.g.bugs, improvements or feature requests).&#x20;

The complete content of a software project, its code, is held in [repositories ](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/creating-a-repository-on-github/about-repositories)collected together under a [GitHub Organization](https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/about-organizations). Later GitHub introduced [Project Boards](https://docs.github.com/en/issues/organizing-your-work-with-project-boards/managing-project-boards/about-project-boards) where issues could be tracked using [Agile ](https://en.wikipedia.org/wiki/Agile_software_development)or [Kanban ](https://en.wikipedia.org/wiki/Kanban_\(development\))methods. Recently GitHub added the [Discussions ](https://docs.github.com/en/discussions)feature to their repositories - allowing for un-tracked informal threaded discussion.

GitHub repositories do not only hold code but often also act as data sources, or as a means to vet data formats (such as the [Cardano Token Repository](https://github.com/cardano-foundation/cardano-token-registry)) and increasingly as a way to store and maintain documentation.

## Emerging collectives

In an emerging collective there will often be an immediate need to record who is working and at what time, what they are working on, what decisions they are making, the status of those decisions (e.g. to do, in progress, done) and where they store their information (data and documentation).

Lack of a structure is a governance choice and will result in issues being forgotten or dismissed arbitrarily, in repetition and duplication of work and those with most persistence leading (might is right) (see "[Decentralized Governance](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3782214)").

Using a software platform to track the collective's immediate governance needs presents challenges of accessibility, risks of specialized knowledge (gatekeepers) and differences of opinion over methodology (informal versus formal) and platform (favored tools).

## A GitHub Issue as the record of a day

In order to meet the immediate and minimum requirements of an emerging collective I propose a basic GitHub Issue as the record of the day's work for that collective.

![A GitHub Issue as the record of a day](https://user-images.githubusercontent.com/25156451/125092811-9f43c880-e0c9-11eb-8bda-cbbafd9ad322.png)

At a minimum this Issue records who is working in the collective that day, the major tasks completed, decision made and collects together any associated documentation.

![Major tasks completed](https://user-images.githubusercontent.com/25156451/125093649-6b1cd780-e0ca-11eb-9c33-722b4091c37c.png)

## Catalyst Swarm Weekly Tasks Project Board

![Catalyst Swarm Weekly Tasks Project Board](https://user-images.githubusercontent.com/25156451/125321466-9e629f00-e334-11eb-97d3-51e7accb6025.png)

## Issues

A list of all Issues for Catalyst-Swarm / Catalyst-Beehive can be seen here

{% embed url="https://github.com/Catalyst-Swarm/Catalyst-Beehive/issues" %}

### The Issue list interface

![The Issue list interface](https://1185095066-files.gitbook.io/~/files/v0/b/gitbook-legacy-files/o/assets%2F-MdDgmKMydq6uV_DpXLe%2F-Mf7FK-rKS5tT08oZO-i%2F-Mf7Gr0RMekIBH9CBPG-%2F2021-07-21.png?alt=media\&token=ade2a385-aa46-4563-99c9-d5ea3511fc3e)

