Changes between Initial Version and Version 1 of EncouragingOpenSourceContributionsFall2015

Nov 12, 2015 12:08:43 PM (7 years ago)
Martin Robinson



  • EncouragingOpenSourceContributionsFall2015

    v1 v1  
     1Encouraging more OS contributions to WebKit
     3Problems: 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.
     42What would some good examples of open source contribution? Can we make that happen again.
     43We 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, 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.
     56Thing 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.
     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.