_articles/2020-11-07-diy-an-offline-bug-tracker-with-text-files-git-and-email.md: Update org-mode to markdown, now with more permalinks

1 files changed, 16 insertions, 11 deletions

diff --git a/_articles/2020-11-07-diy-an-offline-bug-tracker-with-text-files-git-and-email.md b/_articles/2020-11-07-diy-an-offline-bug-tracker-with-text-files-git-and-email.md
index 2bec42b..8f9c421 100644
--- a/_articles/2020-11-07-diy-an-offline-bug-tracker-with-text-files-git-and-email.md
+++ b/_articles/2020-11-07-diy-an-offline-bug-tracker-with-text-files-git-and-email.md
@@ -4,6 +4,8 @@ title: DIY an offline bug tracker with text files, Git and email
 
 date: 2020-11-07
 
+updated_at: 2021-08-14
+
 layout: post
 
 lang: en
@@ -49,9 +51,13 @@ documentation with it.
 
 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.
+`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, but for simple text logs
+[using Git notes] may be just enough, and they would be replicated with the rest
+of the repository.
+
+[using Git notes]: {% link _tils/2020-11-30-storing-ci-data-on-git-notes.md %}
 
 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
@@ -75,11 +81,10 @@ repository itself?
 It requires no extra tool to be installed, and fits right in the already
 existing workflow for source code and documentation.
 
-I like to keep a [`TODOs.org`][todos-org] file at the repository top-level, with
+I like to keep a [`TODOs.md`] 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][org-mode-to-html], and
-[publish][published-todos] it alongside the static website. All that is done on
-the main branch.
+I'll just [generate an HTML file from it], and [publish] it alongside the static
+website. All that is done on the main branch.
 
 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
@@ -92,12 +97,12 @@ For the other 1%, having Fossil's "[tickets][fossil-tickets]" could be an
 alternative, but you may not want to migrate your project to Fossil to get those
 niceties.
 
-Even though I keep a `TODOs.org` file on the main branch, you can have a `tasks`
+Even though I keep a `TODOs.md` 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.
 
 These tools are familiar enough that you can adjust it to fit your workflow.
 
-[todos-org]: https://git.euandreh.xyz/mediator/tree/TODOs.org
-[org-mode-to-html]: https://git.euandreh.xyz/mediator/tree/scripts/build-site.sh?id=db4a727bc24b54b50158827b34502de21dbf8948#n14
-[published-todos]: https://euandreh.xyz/mediator/TODOs.html
+[`TODOs.md`]: https://git.euandreh.xyz/remembering/tree/TODOs.md?id=3f727802cb73ab7aa139ca52e729fd106ea916d0
+[generate an HTML file from it]: https://git.euandreh.xyz/remembering/tree/aux/workflow/TODOs.sh?id=3f727802cb73ab7aa139ca52e729fd106ea916d0
+[publish]: https://euandreh.xyz/remembering/TODOs.html
 [fossil-tickets]: https://fossil-scm.org/home/doc/trunk/www/bugtheory.wiki