Quick start guide
Content creation for web.dev and developer.chrome.com has four phases: planning, writing, reviewing, and publishing. Most of the following information is relevant to both sites.
All content goes through our editorial process. Unless you are working on part of an already approved set of content, do not submit PRs for new content without following these instructions.
Planning #
- Decide if you want your post on web.dev or developer.chrome.com. More about the right site for your post.
- If you're a Googler or have access to a Googler, use the content proposal form to submit your new content request. If you don't have access to a Googler, use the content issue template for web.dev or developer.chrome.com.
- The team will evaluate the proposal's suitability for the goals of the relevant site. If the idea is approved, it will be assigned a reviewer.
Writing #
- Read the Content guidelines to understand how to create high-quality content. The higher the quality of your content, the less time and energy you'll have to spend incorporating feedback.
- How to write blog posts for web.dev and developer.chrome.com has an overview of our process and tips for writing great blog posts.
- After your content proposal is approved, create a copy of the content template to draft your content.
- Review your content with the content checklist to find and fix common problems. The more of these problems you fix yourself, the faster your review will go.
- When your first draft is ready, leave a comment in your GitHub issue and ask for a review.
Reviewing #
Your content will be edited and reviewed in Google docs, this will include:
- Technical review to check that the content is accurate.
- Copy edit: to check that the content meets our style guides and is free from typos and grammar errors.
Publishing #
- After you get approval from a web.dev team member that your content can be published on the site, submit a GitHub pull request.
- Make no changes to the approved copy when creating your PR.
- Check out the web.dev markup section to learn how to make your markdown squeaky clean. In particular, check out the web.dev components or developer.chrome.com components guide to discover UI elements that can make your content more engaging or aesthetically pleasing.
- Once your PR is merged, the content will be deployed to the site immediately, and appear live after around an hour.
Organizing content #
Check with your assigned technical writer before creating new collections or tags.
Collections (learning paths) #
Posts in collections in the Learn section are organized thematically within learning paths. Each collection is defined in the site/_data/paths
directory as a json
object.
To add a new collection, add a
<collection_name>.json
file to thesite/_data/paths
directory.In the collection's
.json
file, define fields like title, description, overview and topic titles as i18n paths, to allow their translation into many languages (e.g.i18n.paths.newpathname.title
).Add the content of these fields to the
site/_data/i18n/paths
directory (underen
key). If applicable, launch translation process for this content by emailing web.dev@.
Tags #
Tags are used to categorize articles and also to generate web.dev/tags pages. The canonical list of tags is published in tags.yml on GitHub.
- to add a new tag, add it first to
tags.yml
- to use an existing tag, add it to your article's
frontmatter
:
tags:
- accessibility