| | 1 | = WebKit.org = |
| | 2 | == Redesign & Updates == |
| | 3 | 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. |
| | 4 | * Existing website is very disorganized. |
| | 5 | * Blog is not especially up-to-date. |
| | 6 | * Planet is out of date. |
| | 7 | |
| | 8 | == Content Plan == |
| | 9 | Our audience: |
| | 10 | * Existing contributors |
| | 11 | * Prospective contributors |
| | 12 | * Web developers who are looking for reference materials. |
| | 13 | |
| | 14 | === Goals === |
| | 15 | * Build trust |
| | 16 | * Educate and Delight |
| | 17 | * Engage |
| | 18 | |
| | 19 | === Content Plan === |
| | 20 | * Up-to-date references |
| | 21 | * Regular articles |
| | 22 | * Feature spotlights |
| | 23 | * Epic Tech Dives! |
| | 24 | * Contributor Resources |
| | 25 | * Plans |
| | 26 | |
| | 27 | == Plans == |
| | 28 | * WordPress Powered site (backed by Trac) |
| | 29 | * Want to keep same credentials we use for svn to reduce overhead on users (having to create separate accounts). |
| | 30 | * Want to avoid the "staleness" of the current Wiki, and deal with lack of context and difficulty in finding things. |
| | 31 | |
| | 32 | == status.webkit.org == |
| | 33 | * A portal to show current changes and activity in the project. |
| | 34 | * Evangelists and project managers from other companies are "telling the story of WebKit", and don't do as good a job as we can. |
| | 35 | * We should take ownership of this and present relevant information to our viewers. |
| | 36 | * We should do a better job of explaining where we have implemented features, versus when they have shipped. |
| | 37 | * Proposal: |
| | 38 | * Create a JSON file of features. Engineers update this file as they work on features. |
| | 39 | * Need a script to check the syntax of the file, perhaps a test page that shows you what your change will look like. |
| | 40 | * Lots of fear that this will not be updated and kept current. |
| | 41 | * Several tools and possible approaches were discussed, along with pros and cons. |
| | 42 | * For policy documents, we should use some kind of MarkDown-based system. |
| | 43 | * For things that change only rarely, and that need oversight and careful review, we need something more. |
