Encouraging more OS contributions to WebKit

Problems: Why aren't we getting contributions:

• Perception that blink/Chromium has better web developer tools
  • Fuzzy feeling that they have momentum and companies behind them.
  • Perhaps this is a separate issue. WebKit used to have a thriving open source community without Google's involvement.
• The build takes too long. You need really powerful hardware to work on WebKit.
• You cannot build iOS WebKit and put it on your phone. Only available to Apple developers.
  • No touch events in iOS in the open source WebKit.
• Long and annoying review process, need to find a reviewer.
• Documentation is scattered across places. Lack of clarity on which kinds to tests write. Testing page needs a lot of love.
• Lots of different kinds of tests with not a lot of documentation.
• The easiest way to contribute is to own a Mac. Many software engineers don't own a Mac.
• The relative size of the community. People will contribute to the browser they use day to day.
• Perception of relevance since the blink fork and compared to Firefox.
• Not knowing when your patch will be released to the world, because of the way that releases of Safari work. The fruits of labor are opaque.
• Bugzilla is too full of useless clutter. It's hard to tell if a bug is a duplicate or not. Not concept of component ownership in Bugzilla and the list of components is outdated. Bugzilla is confusing and difficult to use.
• The EasyToFix keyword is unknown.
• You need a bugzilla account to file bugs. We can't just give people a link to follow bugs even with a bug report page. Although making it too easy to file bugs could decrease the signal to noise ratio. Requiring high quality bugs can mean that people won't even bother to file a bug.
• WebKit has less evangelism than other browsers. Encouraging people to file bugs has resulted in good bugs in the past.
  • Why doesn't that happen more?
  • That's what this session is about.
  • Having a landing page can be a good combination with more evangelism.
• People don't have time always to file a bug report or make test cases, because they are trying to ship.
• Checkout size is really big! The clone is like 5GB. This is really hard for more remote contributors. Maybe a shallow clone or splitting the repository.
  • Just checking out parts of the repository and making them build-able separately.
  • Check out size is an issue for contributors in foreign countries.

What would some good examples of open source contribution? Can we make that happen again. We need to discriminate between good contributions and ones that aren't good.

• Lots of bugs are filed through twitter and stack overflow. People prefer to publicly shame and feel it gets more results. It's lower friction.
• Yusuke working on ES6.
• Contributions to internationalization specification. Interested in a feature that they used.
• Peavo at outlook.com, video and hidpi working on Windows.
• GNOME developers working on the upstream dependency of the GNOME web browser.
• Negative press on IndexedDB resulted in patches being submitted. Followup to angry blog posts.
• Both of these cases the contributors had counterparts who were experienced developers to guide them.

Thing that can OS contributions

• Servo has a list of easy bugs to fix.
• A guide to solve a bug from start to finish.
• Github integration: makes it easier to file bugs, but requires two way integration.
• Partnering with new contributors. Contacting the jond when there is a promising new contributor.
  • How do mentors find new contributors?
    • Getting CCd on patches that get uploaded via watchlists or Alexey CCs you.
  • How do we work with them?
    • Developers need to be on the lookout. This takes a lot of time though and often you have to write the code yourself.
    • We need to spread the reviews around, because reviewing open source contributions take a lot of time.

• Prioritize reviews from new contributors. Add a dashboard to show new bugs or pending reviews. Show new patches on IRC.
• Notifications when patches are uploaded into certain directories, sort of like Blink directories. In GNOME you can follow components by following the email alias that is per-component. We need to improve list of components and versions.
• More blogging.
• A page that describes the process of writing a patch and testing it for different components. We have this already for web inspector, but we don't have it for other components. It just needs to describe the test-build cycle.
• Maybe the nightly build could become build + source - layout tests, so that people could start hacking on the nightly or build bot artifacts without needing to fetch all of WebKit.
  • Technical issues with this. Some of the paths will be wrong. It will require rebuilding everything.
  • Still going to be really enormous.