#0036: Introduction of a website changelog
Preamble
I initially launched this website in 2020-02, with nothing but the default wordpress “coming soon” page to show for itself. Then after some months (2020-06) I finally managed to get round to actually publishing content onto it. And ever since then, I have been in a continual (albeit sporadic and intermittent) process of revision and iterative improvement.
So after about a year and a half of having this website online and functioning as intended: I now see the potential need for a master changelog here. A public facing log that will record all notable changes made to the website.
Utility of a public facing website changelog
Although this changelog will record all noteworthy changes made to the website as a whole. I specifically see the utility of this website changelog, with regards to noting changes made to the content of this blog’s articles themselves; rather than the website at large.
What I mean by this, is that it is more important to note post publication changes made to the content of articles. Than it is noting change in the wider website as a whole. This is because most changes made to the wider website outside of the articles hosted here will likely be concerned with aesthetics. Such as an addition/subtraction of a decorative graphic.
Simply put: they are less substantially important changes in terms of affecting the value proposition of the website itself. Although I do intend to note these types of things as well. At least for the most part. Although very minor website changes of this kind are unlikely to be noted.
That being said: I should restate the main function of this changelog. It is to note changes made to article content. This is because this blog’s articles (or blog posts) is where it’s primary (or most substantive) value is as a website. I.e. the primary reason a person may visit this site is to read the articles. This logging will allow readers to avoid confusion when/if they visit an article that they have already read, only to find that the content has to some degree changed within the interim.
My M.O. regarding editing published articles
Once an article has completed the development process and is finally published, I tend to have a habit of coming back to tweak and change things after the fact. This tends to happen some time time after the article is published when I have had sufficient time to rest and cool off on the topic. At this point I am usually more fresh minded, and hence I am more apt to find better methods to get my point across, as well as to spot any residual errors previously missed.
I am of the mind that I should also chronicle these changes as I make them. This is in order to avoid a sense of revisionist history. One caused by the absolute erasure of any mistakes such as: erroneous calculations, half-witted conclusions, or simple misinformation. I admit I am prone to getting it wrong a lot of the time. Especially when it comes to speculations made with limited observations, or ones unfortunately coloured with personal biases.
With that in mind, I should take a moment to state clearly the nature of this website in order to eliminate any misunderstandings or confusion as to the nature of this publication. As the name should suggest; this website is literally “a tinkerer’s blog”. The articles held therein are presented not as an authoritative source of information, but rather my (and only my) best understanding of any particular subject at the time. Complete with grammatical mistakes, spelling arrows, personal experience, and biases; as well as good ol’fashioned human ignorance and incompetence.
Although I (think I) do my due diligence in researching for articles; as well as re-reading my work several times over before publishing. This is in order to (give myself the opportunity to) catch any and all errors that I can. Unfortunately, often at that time: my mind can become exhausted with the subject matter, and would rather move onto to something else. Anything else! (Maybe even a refreshing punch to the testicles.) Add to that time pressures such as work and scheduled commitments. Well. They all add up; pushing me to hit the publish button perhaps earlier than I otherwise should.
Hence in an article’s final proofreading and finishing edits stage – I tend to find myself skimming sentences; or simply unconsciously mentally correcting the text grammatically and/or semantically. I.e. I knew what I meant by what I wrote, although I left the text in a state where it’s messaging is either ambiguous, nonsensical, and/or open to multiple unintended interpretations. Often I miss mistakes because of this and only really find them after I had some time to ‘cool off’ on the subject, as it were.
So that’s what normally happens with any given article. Post publish edits and refinements seem like a standard protocol for me. I even have a small to-do list regarding edits I need to make to past articles.
For example: my review of the video game “Princess Remedy: In a world of hurt”, has no critic of the game’s soundtrack. I somehow just completely forgot to mention it at all. I just blotted the concept of it out of my mind at the time of writing. So at this point: I intend to go back and insert this into it at a later date.
The thing is: I don’t like the idea of this additional content to suddenly one day appear within that article apropos of nothing, and masquerade like it has always been there from the beginning. I’ll leave that revisionist M.O. to the articles on political/activists news websites.
Hence, I need some way to communicate across to the audience that it is an add-on edit. In the past I solely used what I call an “update tag”. I’d insert a set of square brackets featuring the date before the add-on segment. Basically this: “[UPDATE: 2022-0X-XX] The music is …”. In the future I think I will use either the changelog alone to note smaller changes, and both the changelog as well as an in-article update tag for larger updates. Such as an entire additional segment to an article.
RSS
Just as an aside: if for whatever reason you want the raw undoctored initial publications. Free of my post publish meddling that is. Then please subscribe to my RSS feed. As it sends you the articles as they are published, and doesn’t update the content after that initial data transfer.
To do this, copy the below link into your RSS aggregator of choice:
https://www.tinkerersblog.net/rss
Closing thoughts
Although as stated the main reason for a changelog is for logging post publication article edits, it will also be good for keeping track of more general activity around the website. Things such as when new manual scans are added, or which pages have been recently edited. It’ll give the readership insight into where my attention regarding the website has been recently. Allowing them a sense of the frequency and general trajectory of my activities here. Which would be useful / hold value to anyone interested. (If there really is anyone interested … that is.)
I think it’ll add real utilitarian value to the website. But we’ll see exactly how much once it is actually implemented, and had some time to operate. Theoretically there is no reason as to why a website shouldn’t have a changelog. I mean it is a software product with ongoing development just like any other. However, I do wonder why so few other websites actually do have a public facing changelog.
It could be something as simple as a public changelog not truly being a necessity. Or it could be the fact that it would bring a level of perhaps unwanted transparency to their website. I mean it’s hard to simply vanish things, if you have a policy of documenting changes. I guess you could just not document the vanishing of the undesirable content, but still document the more mundane changes made. Although that does undermine the utility of the tool.
If I were pushed to give an answer: I’d say that most people just don’t want the work of it. For example: with for-profit websites tending to streamline their overheads (i.e. cut costs wherever they can), coupled with the continual communication and co-ordination between multiple levels of staff required for implementing and routinely updating a changelog: they most likely wouldn’t want to bother with one. Especially since there is little in the way of returns in terms of profit for the work necessary.
Even single owner general hobbyist websites probably wouldn’t bother with one either. As the single operator likely focuses their efforts on documenting their actual hobby activities. Rather than developing the website itself. I’d imagine that this is especially true in cases where the subject of their hobby or activity is unrelated to technology.
So unlike with this website, there’d be no on-topic value to discussing website development as a subject. Such as a website documenting: a homestead, hobby farm, painting miniatures, religious education, or bodybuilding to name a few. Basically any website where discussing the website itself is unrelated to the core subjects of the website… Website.
That’s all really. Changelog incoming. (Actually its already here, this article is a month late. :D)
Thank you for reading.
Term Glossary
RSS – Really Simple Syndication
M.O. – Modus Operandi (mode of operation)
Links, references, and further reading
https://en.wikipedia.org/wiki/Rss
https://en.wikipedia.org/wiki/Changelog