New post: Git Workflow, part 0

Thanks to my IRC buds for initial feedback

content/posts/git-workflow-0.gmi

@@ -0,0 +1,37 @@
+Recently, GitHub re-instated the youtube-dl git repository after following a takedown request by the RIAA under the DMCA.
+
+=> https://github.com/ytdl-org/youtube-dl https://github.com/ytdl-org/youtube-dl
+
+Shortly after the takedown, many members of the community showed great interest in "decentralizing git" and setting up a more resilient forge. What many of these people fail to understand is that the Git-based project setup is designed to support decentralization by being fully distributed.
+
+Following the drama, I'm putting together a multi-part guide on how to leverage the decentralized, distributed nature of git and its ecosystem. I made every effort to include all parts of a typical project.
+
+I'll update this post as I add articles to the series. At the moment, I've planned to write the following articles:
+
+1. Repository hosting
+2. Community feedback (issues, support, etc.)
+3. Community contributions (patches)
+4. CI/CD
+5. Distribution
+
+The result of the workflows this series covers will be minimal dependence on outside parties; all members of the community will easily be able to get a copy of the software, its code, development history, issues, and patches offline on their machines. With the exception of CI/CD, the offline content will follow implementation-neutral open standards. Following open standards is the killer feature: nothing in this workflow depends on a specific platform (GitHub, GitLab, Gitea, Bitbucket, Docker, Nix, Jenkins, et cetera), almost eliminating your project's "bus factor".
+
+Providing a way to get everything offline, in a format that won't go obsolete if a project dies, is the key to a resilient git workflow.
+
+## Before we start: FAQ
+
+Q: What level of experience does this series expect?
+
+A: Basic knowledge of git, and a very basic understanding of email. If you have a few repos and can use a third-party email client, you're good.
+
+Q: Do you think you can get hundreds and thousands of people to drop Git{Hub,Lab,tea} and use a different workflow?
+
+A: No, but that would be nice. If only five people who read this series give this workflow a spin and two of them like it and keep using it, I'd be happy.
+
+Q: Is this workflow more difficult than my current one?
+
+A: "Difficult" is subjective. I recommend TRYING this before jumping to conclusions (or worse, sharing those conclusions with others before they have a chance to try it).
+
+Q: I'm not interested in trying anything new, no matter what the benefits are.
+
+A: Ok, first of all, that wasn't a question. Second, this series isn't for you. You should not read this. I recommend doing literally anything else.

content/posts/git-workflow-0.md

@@ -0,0 +1,66 @@
+---
+date: "2020-11-17T13:13:03-08:00"
+outputs:
+- html
+- gemtext
+tags:
+- git
+- foss
+title: "Resilient Git, Part 0: Introduction"
+---
+
+Recently, GitHub re-instated the [youtube-dl git
+repository](https://github.com/ytdl-org/youtube-dl) after following a takedown
+request by the RIAA under the DMCA. Shortly after the takedown, many members of the
+community showed great interest in "decentralizing git" and setting up a more
+resilient forge. What many of these people fail to understand is that the Git-based
+project setup is designed to support decentralization by being fully distributed.
+
+Following the drama, I'm putting together a multi-part guide on how to leverage the
+decentralized, distributed nature of git and its ecosystem. I made every effort to
+include all parts of a typical project.
+
+I'll update this post as I add articles to the series. At the moment, I've planned to
+write the following articles:
+
+1.  Repository hosting
+2.  Community feedback (issues, support, etc.)
+3.  Community contributions (patches)
+4.  CI/CD
+5.  Distribution
+
+The result of the workflows this series covers will be minimal dependence on outside
+parties; all members of the community will easily be able to get a copy of the
+software, its code, development history, issues, and patches offline on their
+machines. With the exception of CI/CD, the offline content will follow
+implementation-neutral open standards. Following open standards is the killer
+feature: nothing in this workflow depends on a specific platform (GitHub, GitLab,
+Gitea, Bitbucket, Docker, Nix, Jenkins, et cetera), almost eliminating your project's
+"bus factor".
+
+Providing a way to get everything offline, in a format that won't go obsolete if a
+project dies, is the key to a resilient git workflow.
+
+## Before we start: FAQ
+
+Q: What level of experience does this series expect?
+
+A: Basic knowledge of git, and a very basic understanding of email. If you have a few
+repos and can use a third-party email client, you're good.
+
+Q: Do you think you can get hundreds and thousands of people to drop Git{Hub,Lab,tea}
+and use a different workflow?
+
+A: No, but that would be nice. If only five people who read this series give this
+workflow a spin and two of them like it and keep using it, I'd be happy.
+
+Q: Is this workflow more difficult than my current one?
+
+A: "Difficult" is subjective. I recommend TRYING this before jumping to conclusions
+(or worse, sharing those conclusions with others before they have a chance to try
+it).
+
+Q: I'm not interested in trying anything new, no matter what the benefits are.
+
+A: Ok, first of all, that wasn't a question. Second, this series isn't for you. You
+should not read this. I recommend doing literally anything else.