On Thu, Jul 04, 2019 at 06:22:11AM +0300, Ilmari Lauhakangas wrote: > Nate Graham kirjoitti 3.7.2019 klo 21.23: > > On 7/3/19 11:53 AM, Albert Astals Cid wrote: > >> If the new is much better than the old, let's just remove the old. > >> > >> As said, having two things that do the same is just confusing for > >> everyone. > > > > I would tend to agree, and having two is super confusing. In general, > > people who have reported bugs on both Bugzilla and GitHub or GitLab seem > > to agree that Bugzilla's UX is inferior. However I don't believe we've > > officially trialed GitLab Issues and investigated what missing features > > need to be added before we can migrate to it. Maybe the time to do that > > is now, as a part of the general GitLab evaluation and migration period. > > > > Personally I find GitLab Issues to offer a vastly superior UX for bug > > reporting compared to Bugzilla. However the UX for bug management and > > triaging is not as granular. For example I still haven't figured out a > > way to create a saved search for "all Issues opened in the last 24 hours > > across all projects". And it would be nice to have some kind of overview > > similar to https://bugs.kde.org/weekly-bug-summary.cgi. > > The upcoming Bugzilla version 6 will have a vastly superior UX to BZ 5: > https://github.com/bugzilla/bugzilla-ux/wiki/Bugzilla-6-Roadmap > > With support from the BZ team, Kohei Yoshino has essentially solved BZ > UX (this includes drafting plans for the future) and I am immensely > grateful to him. > > The underlying functionality will remain superior to GitLabs and hubs as > it has been for years.
I couldn't help but to notice that the feature plan you refer to, for how Bugzilla now has a superior UX drafting future feature plans than Gitlab/Github, is actually hosted in Github rather than Bugzilla. The irony is that BZ 6 really will have key features that will be handy for developers, especially around search. E.g. from the @BugzillaUX Twitter I see examples of a search for bugs fixed in $CURRENT_RELEASE [1] and a search for bugs fixed "this month" (i.e. relative date) [2]. All the same, Gitlab issue tracker is certainly good enough for most developers, more convenient for some developers, and better integrated into the rest of the workflows Gitlab would support (merge requests, quick actions from commit messages). As a personal example, I'd point to https://invent.kde.org/kde/kdesrc-build/issues/27 where Gitlab itself was able to recognize and link to the relevant merge request. Had I merged that exact MR to implement the issue, Gitlab would even have been able to automatically have closed the issue. With a bit more discipline I could have even done things like link to a specific milestone, but kdesrc-build isn't a large enough effort to warrant that level of detail. I'm not sure how to bridge that gap between small projects like mine vs. our larger efforts, but it seems to me that Gitlab is good enough for many of our projects, while Bugzilla remains preferable for projects that have high numbers of bugs to triage and sort through and developers willing to learn its more advanced capabilities. But the same thing that makes Bugzilla so powerful seems likely to continue to make it harder for new contributors (especially contributors used to a Github model) and so I'd be leery about making it a mandatory user touchpoint for projects that have adopted Gitlab, at least as it stands today. BZ 6 may improve this enough to make it feasible for new contributors and then it would "just" be a discussion about how much the potential integration benefits with the rest of Gitlab would be worth balanced against the large migration effort that would seem needed if we were to point users away from Bugzilla. Whatever we do, we should remain mindful of our goal to be able to onboard new contributors and I think those new contributors will come in more and more over time with a familiarity with the Github/Gitlab model and that we may have to find ways ourselves to adapt to that, even if it's nothing more than having a way to "incubate" new contributors in graduated steps to what we're using. Regards, - Michael Pyne [1] https://twitter.com/triagegirl/status/1134554219766112256 [2] https://twitter.com/triagegirl/status/1139278780881444864
