From acd986f023d9cd3c6b943b542e92b38220a21561 Mon Sep 17 00:00:00 2001 From: Katharina Fey Date: Sun, 3 Nov 2019 17:39:22 +0100 Subject: Small configuration changes --- content/blog/xxx_issue_trackers.md | 55 ++++++++++++++++++++++++++++++++++++++ pelicanconf.py | 2 +- 2 files changed, 56 insertions(+), 1 deletion(-) create mode 100644 content/blog/xxx_issue_trackers.md diff --git a/content/blog/xxx_issue_trackers.md b/content/blog/xxx_issue_trackers.md new file mode 100644 index 0000000..2383ab7 --- /dev/null +++ b/content/blog/xxx_issue_trackers.md @@ -0,0 +1,55 @@ +Title: Issue trackers are garbage (and here's why) +Category: Blog +Tags: /dev/diary, dev culture, +Date: 2019-10-10 +Status: Draft + +> 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 +> chaos**. + +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 +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. + +## Bloat + +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? + +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. + +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. + +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. + +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. + +## Onboarding? ONBOARDING?! + + diff --git a/pelicanconf.py b/pelicanconf.py index 4004d7c..a115ef0 100755 --- a/pelicanconf.py +++ b/pelicanconf.py @@ -3,7 +3,7 @@ from __future__ import unicode_literals AUTHOR = 'Katharina Fey' -SITENAME = 'Fun Memory Violations' +SITENAME = 'fun memory violations' SITEURL = '' THEME = 'crumbs' -- cgit v1.2.3