[webkit-dev] Issue reports, merge requests, etc. (was: WebKit Transition to Git)

[Michael Catanzaro]

On Fri, Oct 2, 2020 at 11:51 am, Ryosuke Niwa <rniwa at webkit.org> wrote:
> Since Igalia has a lot
> more experience working with other open source projects, do you have
> some suggestions in how to approach that?

Sorry for a long-ish mail. I didn't mean for this to turn into an 
essay. Too late. :P

I actually moved to Red Hat, but anyway, I would say first step is to 
ensure every incoming issue is triaged, at least once when initially 
reported, and every merge request given at least cursory review within 
a reasonable amount of time. That's how open source projects attract 
and retain community contributors, and it's been a weakness for WebKit 
for a while (we're not the worst at this, but certainly not good at it 
either). One possible answer for this is to have a "project manager" or 
similar role to triage and prioritize issues, but of course it can also 
be done by developers working together (possibly according to some 
rotation).

WebKit is such a big project that I suspect almost nobody has enough 
expertise to triage all incoming bugs, but most of us have enough 
expertise to figure out which issue labels to apply to an incoming bug 
to pass the issue off to more specialized experts. On GNOME GitLab we 
label incoming issues with Bug, Crash, Enhancement, or Feature (the 
difference between Enhancement and Feature is hazy) and have a variety 
of global and per-project labels that can also be applied to issues 
[1]. The list of current components in WebKit Bugzilla would be a good 
starting point to use here. Every new issue gets reviewed and either 
gets closed or else gets a label applied to indicate it has been 
triaged, usually within one business day. If an issue is open and 
doesn't have any labels, we know it has not been triaged.

A lot of bugs can be closed immediately because they're reported in the 
wrong place, for instance. Most crashes are reported without a 
backtrace; to those, we attach a Needs Information label and point the 
reporter to instructions for getting a backtrace with gdb, and close 
after a few days if not provided. The details don't matter so much as 
the fact that the issue has received minimal human attention. In the 
rare cases where a bug report is perfect and all I need to do is add 
issue labels, I give the issue an upvote to indicate I've seen it, so 
the reporter knows it hasn't been *completely* ignored, even if nobody 
fixes it. The details don't matter so much as that contributors and 
issue reporters feel like they've received at least some attention and 
aren't shouting into a bug wasteland.

Then developers subscribe to project-specific labels in accordance with 
their expertise and tolerance for mail. E.g. I watch all issues for 
some projects, but for GLib I'm only subscribed to networking-related 
labels, since problems in the network-related code often impact WebKit. 
Some developers will want to watch only for CSS bugs, only layout bugs, 
only JSC bugs, only WebKitGTK bugs, etc.

Of course, triaging issues doesn't mean they actually get fixed, but 
it's a necessary first step. (And once isn't really enough, either. 
Most of our bugs from 2008 are probably no longer valid, but it takes 
time to review old bugs, and not many people have enough specialized 
technical expertise to triage outside their area of expertise. Anyway, 
once is a starting point.)

Responding to merge requests (or patch reviews) in a timely manner is 
also important (otherwise, contributors disappear). Merge requests take 
longer than issues, but it's good to get to each one within a couple 
days; otherwise, they really start to pile up. We currently have 
patches awaiting review from 2017 [2], and that's just the last time 
somebody decided to mass-deny old review requests. And a lot of these 
are from Apple/Igalia/Sony, who all know who to CC for reviews; imagine 
how much harder it is for someone not familiar with the WebKit 
community to get a patch reviewed. ;) GitHub will probably help with 
this because it puts merge requests front-and-center in its UI, instead 
of requiring us to first discover then take the time to sort through 
the request queue. It's hard to use GitHub without habitually reviewing 
pending requests. ;) The number of open issues and MRs is even clearly 
displayed as a sort of challenge to reduce the number. But we'd need 
some workflow for directing merge requests to appropriate reviewers.

When we move to GitHub, you can expect to start receiving merge 
requests from people who would not take the time and effort to create a 
WebKit Bugzilla account and learn how to use our arcane ChangeLog and 
patch creation scripts. Epiphany has twice as many active contributors 
and probably 3-4x more activity today on GNOME GitLab than it did when 
we used GNOME Bugzilla, and I'm pretty sure that's mainly due to GitLab 
rather than other factors. I wouldn't expect that dramatic a change for 
WebKit, since most WebKit contributors are professional rather than 
volunteer contributors, but I'd guess we'll attract at least that much 
more volunteer community contributor activity. It might take a year or 
two for the change to really become noticeable, but I expect it will be 
significant because moving to GitHub eliminates several barriers to 
contribution.

One more thing we can do is to stop updating the ChangeLog files. These 
files are archaic and not very useful, as long as we continue to write 
good, descriptive commit messages.

We'll need a script to migrate issues from WebKit Bugzilla to GitHub. 
(We don't have to do this initially, to make the initial transition 
smaller, but we *should* do it, to realize all the above benefits.) 
GNOME has a migration script that we used to migrate issues to GitLab, 
but of course we don't have one for GitHub. I understand GitHub has a 
REST API, though, so should be possible.

Lastly, I'll just say that GitHub CI should be a lot nicer than EWS 
bubbles in Bugzilla. ;) I don't have any experience with GitHub CI -- I 
hear it's not quite as powerful as GitLab's? -- but I assume it allows 
us to upload podman/docker images to run whatever checks we want. This 
is really great and the more we take advantage of it, the better.

Michael

[1] https://gitlab.gnome.org/GNOME/epiphany/-/labels
[2] 
https://bugs.webkit.org/request.cgi?action=queue&requester=&product=&type=review&requestee=&component=&group=type&do_union=1