Redistributing Distributed Work

I’ve been working on a project recently that aims to make code, tooling, and planning live side by side in git. There are two big problems as I see them today. Code is stored on some centralized service like GitHub, Atlassian, or GitLab tying you in to them due to their tooling around things like tickets and integrations like CI. The other issue is that these things live outside the history of your code, despite being as critical if not more so to understanding why changes were made.

While things like GitHub have made it more accessible than ever for people to join in and code, it has concentrated power around a few companies, abstracting over a tool designed for distributed work and centralizing it. What I’ve been working on is as much a political statement as it is an attempt to simplify today’s workflows to do more work in repo on disk and have history that stores not only code but the plans, tooling, and other critical context that code needs. ICE is bad for a whole host of reasons which includes locking kids in cages and GitHub and it’s CEO Nat Friedman as well as their now parent company Microsoft are absolutely okay with this. Anything we can do to move people off these platforms is an inherently good thing. I also think that the current trend towards centralization is a big mistake that has really killed the vibrancy of the internet. I want to help bring that back.

There’s a trick to doing this and being successful though. It has to be software that’s easy to use and intuitive and needs to have the same value add as GitHub. This means abstracting over the not particularly fun or easy parts git to create a user experience that’s as nice as the services that people use today. I’d like to talk a little bit about the first part of this suite of tools I’ve been working on, what future tools and plans are, as well as some of my reasoning for staying a somewhat private project for now.

Ticket

The first thing I’ve built and done the most work on is Ticket. It’s an in repo ticket manager. Your issues get stored as part of the repo so that not only do you know when a particular issue came up, but when it closed in relation to the code in your repo. I’ve also been working on a TUI to browse the issues as well. It’s fairly bare bones as is all projects when started, but it works and it’s how I’m keeping track of

issues and things that need to get done inside of dev-suite (tentative name for now). My most immediate work has been finishing out the basic TUI browser and switching to using uuids that are generated with timestamps and can be ordered by them, over than a singular id number increasing over time.

Once those are done I’ll be able to move on to doing some of the following:

• Adding comments to issues
• Assigning one or more users to issues
• Commenting from the TUI
• Assigning users via the TUI
• Adding custom configurable states such as "Won't Fix"
• Issue tags
• Search/Filter

and more as it gains better functionality. The designing philosophy around this tool is "Don't be Jira". The less time you need to use this and other tools because you get what you need quickly, the better. It should not take 20 hoops to get what you want.

Hooked

Hooked is the in repo githook manager I've been working on. It sets up all the hooks you might want for your code and symlinks them to .git/hooks for you automatically. No need to remember which way the args for ln -s go! This also means that your hooks live inside the repo and version controlled while there are lots of services you can use to handle linting etc. it's really nice to just enforce it automatically with hooks that are able to travel with your code. Now there's a lot of

teams that might not want that and I get it. For me though it's been great to know that every commit builds and that I can get the same experience across all my machines. The goal of hooked is to make it easy to initialize scripts, in the scripting lang you choose, for the hooks. This can make it easier for teams to enforce styling, but skip with --no-verify if just making one off junk commits and not wanting to run the whole test suite. Really what I hope people use this for is to embrace trunk based development, commiting straight to master, all while following the "not rocket science" rule and making sure master is green before you push. githooks are a tool and how you use them is up to you. This is about creating a suite of tools that work well together, but you should only really use the ones you want to use.

Future Tools

So far that's all I've worked on, so it's fairly early days, but other tools I want to work on or have thought about and not settled on are:

• Easy to do distributed pull requests that stores comments as commits, saves the PR as commits that can be viewed later in time, and only actually merging the changes that were made, not the comments easily
• Project planning tools since tickets the way JIRA and other software does is a bit of an anti-pattern
• git fork, clone a repo locally that sets the upstream automatically and setting the origin as the repo you plan to push your code to.
• Better tooling around emailing and code. Email will be around till I die probably, so finding out how it can be effectively used for communication and maybe even storing it as part of the history. This is one of my more vague ideas
• Changelog generator

There's probably even way more that can be done here, but the main thing for now is recreating that GitHub/GitLab ease of use and experience in repo and further enhancing it. We want to redistribute where code lives and how work is done, but that doesn't mean we need to regress and give up the quality experiences we have today.

Why private?

For now it's a single person project because frankly I'm just not good at maintaining code or working on things due to mental health issues. When it is my job and I'm paid for it it's not as hard cause I like to eat and you know live. For side projects though it's like video games to me. I pick them up and play for awhile put it down and forget about it for some time and then get hyper focused months later. This isn't exactly sustainable, but getting consistent contributors is hard to do as well. For now I just want to work on this alone because I won't feel guilty if I need to put it down for a month or three, and because it's a lot of real small tools working together in one project and not one large monolithic tool I'll feel isn't making progress it really leans into my ability to hyper focus sometimes on interesting things, but there are 50 things to choose from which increases the chances of hyper focusing.

The tl;dr mental health is tough, but as I've begun to understand who I am it's made it easier to build my environment around how I work rather than trying to adapt to the environment. I do think I'll release some initial builds of some tools at some point, but no guarantees right now.

git commit -m "Finish writing the blog post" && git push

All in all it's been fun working on this so far and the reactions to what I've shown on Twitter have been very positive, so I feel like I'm on to something. I'm hoping to post updates on a more frequent basis. I feel like this is a project I might be able to stick with for awhile.