| | 1 | Encouraging more OS contributions to WebKit |
| | 2 | |
| | 3 | Problems: Why aren't we getting contributions: |
| | 4 | * Perception that blink/Chromium has better web developer tools |
| | 5 | * Fuzzy feeling that they have momentum and companies behind them. |
| | 6 | * Perhaps this is a separate issue. WebKit used to have a thriving open source |
| | 7 | community without Google's involvement. |
| | 8 | * The build takes too long. You need really powerful hardware to work on WebKit. |
| | 9 | * You cannot build iOS WebKit and put it on your phone. Only available to |
| | 10 | Apple developers. |
| | 11 | * No touch events in iOS in the open source WebKit. |
| | 12 | * Long and annoying review process, need to find a reviewer. |
| | 13 | * Documentation is scattered across places. Lack of clarity on which kinds to tests |
| | 14 | write. Testing page needs a lot of love. |
| | 15 | * Lots of different kinds of tests with not a lot of documentation. |
| | 16 | * The easiest way to contribute is to own a Mac. Many software engineers don't own a Mac. |
| | 17 | * The relative size of the community. People will contribute to the browser |
| | 18 | they use day to day. |
| | 19 | * Perception of relevance since the blink fork and compared to Firefox. |
| | 20 | * Not knowing when your patch will be released to the world, because of the |
| | 21 | way that releases of Safari work. The fruits of labor are opaque. |
| | 22 | * Bugzilla is too full of useless clutter. It's hard to tell if a bug is a duplicate |
| | 23 | or not. Not concept of component ownership in Bugzilla and the list of components |
| | 24 | is outdated. Bugzilla is confusing and difficult to use. |
| | 25 | * The EasyToFix keyword is unknown. |
| | 26 | * You need a bugzilla account to file bugs. We can't just give people a link to |
| | 27 | follow bugs even with a bug report page. Although making it too easy to file bugs |
| | 28 | could decrease the signal to noise ratio. Requiring high quality bugs can mean |
| | 29 | that people won't even bother to file a bug. |
| | 30 | * WebKit has less evangelism than other browsers. Encouraging people to file bugs |
| | 31 | has resulted in good bugs in the past. |
| | 32 | * Why doesn't that happen more? |
| | 33 | * That's what this session is about. |
| | 34 | * Having a landing page can be a good combination with more evangelism. |
| | 35 | * People don't have time always to file a bug report or make test cases, because |
| | 36 | they are trying to ship. |
| | 37 | * Checkout size is really big! The clone is like 5GB. This is really hard for |
| | 38 | more remote contributors. Maybe a shallow clone or splitting the repository. |
| | 39 | * Just checking out parts of the repository and making them build-able separately. |
| | 40 | * Check out size is an issue for contributors in foreign countries. |
| | 41 | |
| | 42 | What would some good examples of open source contribution? Can we make that happen again. |
| | 43 | We need to discriminate between good contributions and ones that aren't good. |
| | 44 | * Lots of bugs are filed through twitter and stack overflow. People prefer to publicly |
| | 45 | shame and feel it gets more results. It's lower friction. |
| | 46 | * Yusuke working on ES6. |
| | 47 | * Contributions to internationalization specification. Interested in a feature |
| | 48 | that they used. |
| | 49 | * Peavo at outlook.com, video and hidpi working on Windows. |
| | 50 | * GNOME developers working on the upstream dependency of the GNOME web browser. |
| | 51 | * Negative press on IndexedDB resulted in patches being submitted. Followup to |
| | 52 | angry blog posts. |
| | 53 | * Both of these cases the contributors had counterparts who were experienced |
| | 54 | developers to guide them. |
| | 55 | |
| | 56 | Thing that can OS contributions |
| | 57 | * Servo has a list of easy bugs to fix. |
| | 58 | * A guide to solve a bug from start to finish. |
| | 59 | * Github integration: makes it easier to file bugs, but requires two way integration. |
| | 60 | * Partnering with new contributors. Contacting the jond when there is a promising |
| | 61 | new contributor. |
| | 62 | * How do mentors find new contributors? |
| | 63 | - Getting CCd on patches that get uploaded via watchlists or Alexey |
| | 64 | CCs you. |
| | 65 | * How do we work with them? |
| | 66 | - Developers need to be on the lookout. This takes a lot of time |
| | 67 | though and often you have to write the code yourself. |
| | 68 | - We need to spread the reviews around, because reviewing open source |
| | 69 | contributions take a lot of time. |
| | 70 | |
| | 71 | * Prioritize reviews from new contributors. Add a dashboard to show new bugs or |
| | 72 | pending reviews. Show new patches on IRC. |
| | 73 | * Notifications when patches are uploaded into certain directories, sort of |
| | 74 | like Blink directories. In GNOME you can follow components by following the |
| | 75 | email alias that is per-component. We need to improve list of components and versions. |
| | 76 | * More blogging. |
| | 77 | * A page that describes the process of writing a patch and testing it for different |
| | 78 | components. We have this already for web inspector, but we don't have it for |
| | 79 | other components. It just needs to describe the test-build cycle. |
| | 80 | * Maybe the nightly build could become build + source - layout tests, so that people |
| | 81 | could start hacking on the nightly or build bot artifacts without needing to fetch |
| | 82 | all of WebKit. |
| | 83 | * Technical issues with this. Some of the paths will be wrong. It will require |
| | 84 | rebuilding everything. |
| | 85 | * Still going to be really enormous. |
