Our GitHub Tracking System
Building a distributed governance practice with GitHub
Last updated
Building a distributed governance practice with GitHub
Last updated
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).
The complete content of a software project, its code, is held in collected together under a . Later GitHub introduced where issues could be tracked using or methods. Recently GitHub added the 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 ) and increasingly as a way to store and maintain documentation.
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 "").
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).
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.
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.
A list of all Issues for Catalyst-Swarm / Catalyst-Beehive can be seen here
