On Tue, 17 Jun 2025 23:15:55 +0300, Otto Kekäläinen <o...@debian.org> wrote: >I've seen some of this same sentiment in discussions about >bugs.debian.org. People think that having a hard-to-use bug tracker >will keep the "noobs" away and maintain a higher quality of bug >reports and discussions among the people who do pass the bar of >figuring out how to use it. I think this is a very elitist attitude.
The "hard to use" bugtracker is also easier to use for those people. I'd rather say that those people are lazy because they are not willing to ditch their ease of use to make things easier for others. I am one of those. That being said, I also detest web forums and still spend considerable time on Usenet. Because it's easier to use that any webforum. For me. I think I am as entitled to have a low barrier to use a medium as a newbie. >I just merged a first-time contributor MR in >https://salsa.debian.org/salsa-ci-team/pipeline/-/merge_requests/614, >and I think it was good quality. I don't think that people who use MRs >are noobs and their quality is in general bad, I don't think anybody ever said that. >and I don't think this >barrier of e-mail-only really helps drive up contribution quality. >When I compare my experiences of top-tier developers who I have seen >doing both e-mail reviews and in-browser reviews, in my experience >their in-browser reviews end up being much more productive and >scalable as they can have rich context information that is always >up-to-date, can track statuses and in general juggle many more reviews >in parallel. Also, if a bug goes into production, having the track >record properly in git and Forges really makes a difference. I think that tracking patches and tracking bugs have little in common. The BTS is a good medium for tracking bugs. MRs and the forge are a good tool for tracking patches. I am willing to move to MRs for tracking patches (I will break a lot of things there until I am productive with that workflow), but please let me keep the BTS for tracking bugs. Btw, I think that trivial one liner patches (such as the classing "allows one to" in man pages) are better filed as a bug. Just going through the fork, clone, commit, push, MR workflow takes as much time as opening ten issues like "your man page says 'allows to', please change that to the correct 'allows one to'". And after having said that I have not monitored the progress of the MR and the deletion of the forked repo. >But as said, I understand you have now your optimized workflow in >Mutt, and I am not asking you to change it. Many of the suggestions in such threads are like "let's replace the BTS with foo". Greetings Marc -- ---------------------------------------------------------------------------- Marc Haber | " Questions are the | Mailadresse im Header Rhein-Neckar, DE | Beginning of Wisdom " | Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402
