|
From: | Dmitry Gutov |
Subject: | Re: Choice of bug tracker |
Date: | Thu, 31 Aug 2023 23:55:47 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 |
On 31/08/2023 23:44, Stefan Kangas wrote:
Ihor Radchenko<yantar92@posteo.net> writes:It isn't trivial when people respond to several threads in the same message. You can see examples of this on this list, just look at the recent large threads.I can see how that is a problem. So, is it a +1 for "modern trackers" and -1 for "mailing lists"?Perhaps, yes. I'd definitely be much happier if we had a bug tracker that made it possible to split threads after the fact. If that's something you can do with a "modern tracker", then it would certainly help. We are more disciplined these days, but I have seen many old, sprawling bug threads with dozens upon dozens of replies, more than half of which are about something else entirely. Coming back to such threads after N years, as I've often done, it does take a long time to find some signal in there: to figure out what is fixed, what is not, what is a separate issue, and so on.
That would be nice to be able to do, but is that feasible?If the main interface for interacting with discussions for many people remains their mail client, whatever we try to split after the fact (BTW, I know of such features in "forum software" similar to Discourse, but probably not in Gitlab's issues) wouldn't be reflected in everybody's existing mail archives.
This would only work if we/they used an Emacs client that worked off Gitlab's programmatic API instead, showing the most recent views. But that would take a fair amount of work to create, and wouldn't support the existing mail rules/filters/etc, at the very least.
A "modern tracker" could encourage us to use more structured threads going forward, though.
[Prev in Thread] | Current Thread | [Next in Thread] |