WebKit.org

Redesign & Updates

What can we as a project do to make our website and other external artifacts work better to get the message out about what we are doing, etc.

• Existing website is very disorganized.
  • Blog is not especially up-to-date.
  • Planet is out of date.

Content Plan

Our audience:

• Existing contributors
• Prospective contributors
• Web developers who are looking for reference materials.

Goals

• Build trust
• Educate and Delight
• Engage

Content Plan

• Up-to-date references
• Regular articles
• Feature spotlights
• Epic Tech Dives!
• Contributor Resources
• Plans

Plans

• WordPress Powered site (backed by Trac)
• Want to keep same credentials we use for svn to reduce overhead on users (having to create separate accounts).
• Want to avoid the "staleness" of the current Wiki, and deal with lack of context and difficulty in finding things.

status.webkit.org

• A portal to show current changes and activity in the project.
• Evangelists and project managers from other companies are "telling the story of WebKit", and don't do as good a job as we can.
• We should take ownership of this and present relevant information to our viewers.
• We should do a better job of explaining where we have implemented features, versus when they have shipped.
• Proposal:
  • Create a JSON file of features. Engineers update this file as they work on features.
  • Need a script to check the syntax of the file, perhaps a test page that shows you what your change will look like.
  • Lots of fear that this will not be updated and kept current.
  • Several tools and possible approaches were discussed, along with pros and cons.
• For policy documents, we should use some kind of MarkDown-based system.
• For things that change only rarely, and that need oversight and careful review, we need something more.