# msgid "" msgstr "" msgid "title: DIY an offline bug tracker with text files, Git and email" msgstr "" msgid "date: 2020-11-07" msgstr "" msgid "layout: post" msgstr "" msgid "lang: en" msgstr "" msgid "ref: diy-an-offline-bug-tracker-with-text-files-git-and-email" msgstr "" msgid "" "When [push comes to " "shove](https://github.com/github/dmca/blob/master/2020/10/2020-10-23-RIAA.md)," " the operational aspects of governance of a software project matter a lot. " "And everybody likes to chime in with their alternative of how to avoid " "single points of failure in project governance, just like I'm doing right " "now." msgstr "" msgid "The most valuable assets of a project are:" msgstr "" msgid "source code" msgstr "" msgid "discussions" msgstr "" msgid "documentation" msgstr "" msgid "builds" msgstr "" msgid "tasks and bugs" msgstr "" msgid "" "For **source code**, Git and other DVCS solve that already: everybody gets a" " full copy of the entire source code." msgstr "" msgid "" "If your code forge is compromised, moving it to a new one takes a couple of " "minutes, if there isn't a secondary remote serving as mirror already. In " "this case, no action is required." msgstr "" msgid "" "If you're having your **discussions** by email, \"[taking this archive " "somewhere else and carrying on is " "effortless](https://sourcehut.org/blog/2020-10-29-how-mailing-lists-prevent-" "censorship/)\"." msgstr "" msgid "" "Besides, make sure to backup archives of past discussions so that the " "history is also preserved when this migration happens." msgstr "" msgid "" "The **documentation** should [live inside the repository " "itself](https://podcast.writethedocs.org/2017/01/25/episode-3-trends/)[^writethedocs-" "in-repo], so that not only it gets first class treatment, but also gets " "distributed to everybody too. Migrating the code to a new forge already " "migrates the documentation with it." msgstr "" msgid "" "[^writethedocs-in-repo]: Described as \"the ultimate marriage of the two\". " "Starts at time 31:50." msgstr "" msgid "" "As long as you keep the **builds** vendor neutral, the migration should only" " involve adapting how you call your `tests.sh` from the format of " "`provider-1.yml` uses to the format that `provider-2.yml` accepts. It isn't " "valuable to carry the build history with the project, as this data quickly " "decays in value as weeks and months go by." msgstr "" msgid "" "But for **tasks and bugs** many rely on a vendor-specific service, where you" " register and manage those issues via a web browser. Some provide an " "[interface for interacting via email](https://man.sr.ht/todo.sr.ht/#email-" "access) or an API for [bridging local bugs with vendor-specific " "services](https://github.com/MichaelMure/git-bug#bridges). But they're all " "layers around the service, that disguises it as being a central point of " "failure, which when compromised would lead to data loss. When push comes to " "shove, you'd loose data." msgstr "" msgid "Alternative: text files, Git and email" msgstr "" msgid "" "Why not do the same as documentation, and move tasks and bugs into the " "repository itself?" msgstr "" msgid "" "It requires no extra tool to be installed, and fits right in the already " "existing workflow for source code and documentation." msgstr "" msgid "" "Any issues discussions are done in the mailing list, and a reference to a " "discussion could be added to the ticket itself later on. External " "contributors can file tickets by sending a patch." msgstr "" msgid "" "The good thing about this solution is that it works for 99% of projects out " "there." msgstr "" msgid "" "For the other 1%, having Fossil's \"[tickets](https://fossil-" "scm.org/home/doc/trunk/www/bugtheory.wiki)\" could be an alternative, but " "you may not want to migrate your project to Fossil to get those niceties." msgstr "" msgid "" "Even though I keep a `TODOs.org` file on the main branch, you can have a " "`tasks` branch with a `task-n.md` file for each task, or any other way you " "like." msgstr "" msgid "" "These tools are familiar enough that you can adjust it to fit your workflow." msgstr "" msgid "" "I like to keep a " "[`TODOs.org`](https://euandreh.xyz/mediator.git/tree/TODOs.org) file at the " "repository top-level, with two relevant sections: \"tasks\" and \"bugs\". " "Then when building the documentation I'll just [generate an HTML file from " "it](https://euandreh.xyz/mediator.git/tree/scripts/build-" "site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14), and " "[publish](https://euandreh.xyz/mediator/TODOs.html) it alongside the static " "website. All that is done on the main branch." msgstr "" #~ msgid "" #~ "I like to keep a " #~ "[`TODOs.org`](https://euandreh.xyz/mediator.git/tree/TODOs.org) file at the " #~ "repository top-level, with two relevant sections: \"tasks\" and \"bugs\". " #~ "Then when building the documentation I'll just [generate an HTML file from " #~ "it](https://euandreh.xyz/mediator.git/tree/scripts/build-" #~ "site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14), and " #~ "[publish](https://mediator.euandreh.xyz/tasks-and-bugs.html) it alongside " #~ "the static website. All that is done on the main branch." #~ msgstr "" #~ msgid "" #~ "I like to keep a " #~ "[`TODOs.org`](https://euandreh.xyz/mediator.git/tree/TODOs.org?id=110c0af4ef53faf6e1ebe87905ce16766548607e)" #~ " file at the repository top-level, with two relevant sections: \"tasks\" and" #~ " \"bugs\". Then when building the documentation I'll just [generate an HTML " #~ "file from it](https://euandreh.xyz/mediator.git/tree/scripts/build-" #~ "site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14), and " #~ "[publish](https://mediator.euandreh.xyz/tasks-and-bugs.html) it alongside " #~ "the static website. All that is done on the main branch." #~ msgstr ""