-
‹ Home
Contents
-
Categories
-
Tags
-
Archives
- April 2025
- March 2025
- December 2024
- November 2024
- October 2024
- August 2024
- July 2024
- September 2023
- July 2023
- May 2023
- April 2023
- March 2023
- January 2023
- November 2022
- September 2022
- July 2022
- October 2021
- November 2020
- June 2020
- May 2020
- March 2020
- July 2019
- June 2019
- May 2019
- March 2019
- January 2019
- December 2018
- November 2018
- October 2018
- August 2018
- July 2018
- June 2018
- March 2018
- February 2018
- January 2018
- December 2017
- November 2017
- October 2017
- August 2017
- June 2017
- April 2017
- March 2017
- January 2017
- August 2016
- July 2016
- April 2016
- March 2016
- January 2016
- November 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
- January 2015
- December 2014
- November 2014
- October 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- February 2014
- January 2014
- December 2013
- November 2013
- October 2013
- September 2013
- August 2013
- August 2012
- June 2011
- May 2011
-
RSS Feeds
-
Meta
The Buggregator
As you may know, I have a lot of tools for Wikipedia, Wikidata, Commons, etc. A lot of tools means a lot of code, and that means a lot of bugs, things that could work better, feature requests, and so on.
How do I learn about such issues as people encounter them? In a variety of ways. Most of my tools have git repositories, usually on GitHub and BitBucket, where issues and feature requests can be posted. But many people just leave comments on one of my many talk pages (de, en, commons, wikidata, meta, …), on the talk page of a tool (usually for the documentation page), and sometimes I get messages via email, Twitter, Telegram (the app), Signal, etc.
There is just no way for me to keep track of all of these. Some of the talk pages I visit rarely (eg meta), messages on Twitter are forgotten once they scroll out of sight, and so on. I needed a way to aggregate all those bug reports in one place.
Enter The Buggregator .
I started by creating a database of my tools. Yes, all of them. Including the JavaScript ones on the wikis. Including the old, obsolete and unmaintained ones. The sub-tools on my Toolforge amalgamate tools like “wikidata-todo”. Everything.
Then, I wrote import scripts. One for github, one for bitbucket, one for talk pages. (Tweets can be added manually at the moment). These run once a day, for everything I can think of. A heuristic tries to assign tools to (for example) new talk page topics.
I started out with 1795 issues, many of them “historical”, and am now down to 1516. Some way to go, but that has never discouraged me before.
I did this a few months ago and forgot to write about it, as I was busy with some personal issues (not tracked in Buggregator!). The reason I remembered is that Toolhub is now in production, and I think it’s great. But while it is using entries from Hay’s Directory (HD), it does not have all the tools I have in Buggregator.
So I made a script that uses the Buggregator tool list, checks it against the Toolhub list, and (once a day) creates a HD-style tool list, which I just added to the HD sources. That should add the tools to HD, which in turn should add them to Toolhub. There are ~200 of my tools not in HD and (probably) not in Toolhub, though this might create some duplication. But better to have a tool listed twice (until that can be cleaned up) than not having it listed at all, IMHO.
If you find tools of mine I forgot (entirely possible), or see some ways to get that count of open issues down, please let me know!