Adding first droft of issue tracker article

2 files changed, 104 insertions, 29 deletions

diff --git a/content/blog/xxx_autonomous_tech.md b/content/blog/xxx_autonomous_tech.md
new file mode 100644
index 0000000..a4c3acb
--- /dev/null
+++ b/content/blog/xxx_autonomous_tech.md
@@ -0,0 +1,12 @@
+Title: A movement for autonomous technology
+Category: Blog
+Date: 2019-12-12
+Tags: culture, politics
+Status: Draft
+
+I was recently at an art event of sorts, called T/H\X and met a bunch
+of cool people working on interesting things, relating philosophy with
+technology and thinking about the implications of the things we create
+in the wider context of the world.
+
+During 
diff --git a/content/blog/xxx_issue_trackers.md b/content/blog/xxx_issue_trackers.md
index 2383ab7..06f8967 100644
--- a/content/blog/xxx_issue_trackers.md
+++ b/content/blog/xxx_issue_trackers.md
@@ -1,9 +1,23 @@
 Title: Issue trackers are garbage (and here's why)
 Category: Blog
 Tags: /dev/diary, dev culture,
-Date: 2019-10-10
+Date: 2019-13-12
 Status: Draft
 
+(Outline)
+
+- Tracking what needs to be done/ progress
+- Giving newcomers a place to be onboarded
+- Let people ask questions and report bugs
+  - Build a knowledge base with answers that can be searched over time
+  
+- Tracking issues don't get updated or suck up a lot of time being maintained
+  - Don't actually make it easy to write updates about what people are doing
+- Discussions can easily be derailed
+  - "chat" like discussions take over spaces easily
+  - editing comments can be massively misleading
+- How to discuss things that might be two issues at once?
+
 > We don’t know who struck first, us or them. But we know that it was
 > us that invented **issue trackers**. At the time development was very
 > chaotic and it was believed that they would bring **order into the
@@ -11,45 +25,94 @@ Status: Draft
 
 Whenever I talk to people about making FOSS projects more
 approachable, one thing that always comes up is issue trackers. "Label
-your issues", they say, "Mark them as 'good first issue'", they
-say. This is, of course, to make it easier for newcomers to see what
+your issues", they say, "Mark them as 'good first issue' and
+such". This is, of course, to make it easier for newcomers to see what
 needs to be done, where they can help, or even just have a place to
 ping for mentoring.
 
 So far so good.
 
-I will now prove that this is the only area where issue trackers are
-good. And in fact, how this same workflow can be entirely implemented
-in either a shared edit pad, or a mailing list.
+In this post I want to talk about how issue trackers are flawed and
+why. Many people still insist that issue trackers are a neccessity in
+the development space. This especially comes up whet discussing
+decentralisation efforts for development. Many people reject the idea
+that git is inherently decentralised, citing the need for an issue
+tracker as a reason why.
+
+I want to go through some examples and show why issue trackers don't
+work, why they can't work, and also highlight some alternatives.
+
+## Onboarding
+
+I wanna talk about onboarding first because it feels like the biggest
+reason people insist on having issue trackers, and might be the one
+place where they're not entirly terrible.
+
+The idea of publishing a list of things that need to be worked on,
+tailored to newcomers, is a good one.  It gives people an easy way to
+ask for help, and getting in the mood to submit their first patches to
+a project.  A "generic list of things that should be done" list can
+also in general be usefol to project maintainers, to prevent someone
+from keeping too much state in their head at all times.
+
+I think that any project should have something like this, but it
+doesn't require an issue tracker to implement.  I will talk about the
+alternatives later in this post, but the same described mechanism can
+be implemented using a shared collaboration pad or a mailing list.
+
+## Tracking issues
+
+Many people keep tracking issues in their projects to give external
+people and maintainers a nice way of seeing what is being worked on
+and what things need to be finished before a release can happen or a
+feature is fully implemented.  It also gives people the ability to
+discuss things under the issue, coordinate, etc.  So far so good.
 
-## Bloat
+The problems here are both that tracking issues are a lot of work to
+maintain, and that discussions on these issues tend to derail.
+Information that's posted on an issue might not be relevant anymore in
+2 weeks, yet it is presented to anyone coming into the space as "what
+to read next".
 
-The central problem of issue trackers, like with most things in life,
-is people. People who create new issues, without searching for one
-that already exists. People who forget about updating or closing their
-issues or just fail to add relevant tags and write a descriptive
-text. Who needs more than the title?
+Some platforms will compress some comments down, but it's still
+requiring someone new to the issue to read a _lot_ of stuff before
+they understand the current state of affairs.  And this doesn't even
+address everyone using a different client or e-mail notifications.
 
-This results in many issue trackers accumilating so much information
-that it becomes impossible for anyone to understand it anymore. It's
-common for larger, long-running projects to purge their issue trackers
-from time to time, hinting that there might be a problem in the
-accumilation of bloat. 
+Also, a badly maintained tracking issue is worse than useless.
+Sometimes issues only link to other issues, at which point the
+conversation can get split between mustiple places, making it slightly
+les jaring to read.  But the fact remains: long-living entities
+ultimately attract bloat.  Your tracking issues are informative now,
+but what about in 3 months?  Or 6 months?
 
-Another approach is to do "triage" regularly, meaning that the
-update-purge cycle gets done on a smaller scale, but more
-regularly. Other projects ignore their issue trackers, letting
-thousands of them build up and embracing that information will be
-duplicated.
+## Asking questions/ report bugs
 
-Interestingly enough, vey often the people doing the most work have
-the least interaction with issue trackers. PRs and reviews, yes, those
-are somewhat useful tools. But issue trackers, very much not so.
+"What about reporting issues," I hear you say.  "That's literally what
+an issue is!" and...granted, sometimes they can be good this way.  But
+there's something to consider here.  While I lumped both "reporting
+issues" and "asking questions" into the same category, they are
+actually wildely different things from a maintainers perspective.
+They are sometimes considered one and the same, because the workflow
+for a user is the same: open an issue and post some logs.
 
-In the end, issues become a kind of forum where people can discuss
-their problems or ideas. Do you know what else is kinda like a forum?
-A mailing list.
+Answering questions from a maintainers perspective usually, after the
+problem has been resolved, doesn't result in other issues.  Sometimes
+a project might want to imprve their documentation to make this
+particular use-case easier to understand, but usually the software is
+left unchanged.
 
-## Onboarding? ONBOARDING?!
+However if a bug was found that needs to be fixed, the issue now
+describing it is written from the perspective of an outsider.  Even
+the most detailed bug reports are not going to capture enough internal
+state to easily communicate to a project maintainer why something has
+happened.  The logs will be a guiding first principle, yes, but there
+is a lot of work required for anyone looking at the issue in the
+future.
 
+A much better approach would be to repost the issue, describing what
+is so far know about it, from the perspective of a maintainer.  This
+might link to the ininal report, maybe adding them to CC.  This would
+be aimed at other contributors, and future-contributors, making it
+easier for someone to pick up work on the issue in the future.