Small configuration changes

2 files changed, 56 insertions, 1 deletions

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'