This is something I miss so much from Bugzilla times, where the number of people cc’ed into a bug was an accepted measure of the importance/impact/popularity of the bug, and the more duplicates a bug had, the more people was added from those duplicates to the original bug.
Now that’s gone in gitlab, when I mark an issue to be a duplicate, the people subscribe to that duplicate is not added to the original issue, thus loosing people along the way which would give more prominence to the original bug as it showed how many people was affected by it. Also those people not added from the duplicates will not receive an update when the original bug gets fixed.
What do people think about this? and is it possible to create a bot that will do that?
Venting here to test this Discourse thing
People from the duplicate still subscribed to the exiting bug, don’t they? So they still get notifications of changes, but they don’t appear in the participants list?
To be fair, I personally never used the subscribers or duplicate counts as metrics on the popularity of an issue; people tend to brigade bugs for random reasons—for instance, somebody linked to it on reddit—and duplicates are usually the result of people not searching before filing bugs. That has been my experience in GLib/GTK, to be honest, so it may vary from other components.
Ideally, the number of reactions—like leaving a emoji—should be a measure of that, more than the people subscribing to an issue. We never enabled voting on Bugzilla because it communicated a false expectation on what people would work on; the emoji reaction is, ideally, less stressful on the maintainers.
Thank you for your opinion/experience on this.
This topic was automatically closed 5 days after the last reply. New replies are no longer allowed.