On Fri, Oct 2, 2020 at 11:51 am, Ryosuke Niwa <rn...@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.


[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

webkit-dev mailing list

Reply via email to