Management

TODO: This article is very stale. Much of its content is duplicated elsewhere in the site. We should factor it out into relevant sub-articles.

This document sets expectations about the organization and management of the Web Developer Center, and describes how the site implements the ideals described in the Pillars. Like all parts of the site, this document is expected to evolve over time in accordance with the will of the community.

Scope of Content on the Site

• The content to seed the site initially will be pragmatic content tailored towards an audience of web developers, from beginners to advanced. For example, the site may include reference documentation, tutorials, and general guides. Some of this material will be written from scratch, and some will be sourced from already existing resources, such as the Opera web standards curriculum.
• These items of content will deliberately be organized in a very granular, unstructured fashion, so they can be as useful to as many educators, students and other interested parties as possible.
• The site will also include several curriculum documents, which organize the learning content into different structured learning resources, referencing the different articles in appropriate places and adding learning outcomes, exam questions, rubrics, etc. on top of that. The seed material for this will be http://interact.webstandards.org/.
• Over time the scope may change, for example to include groups like designers, marketing professionals and other non-developers who may be involved in a web project.
• The following content is currently out of scope: browser implementation documentation, specifications with no implementations.

Content Organization

The content will cover the spectrum of open standards-based web development as completely as possible. We expect that the community will find ways to organize the content usefully for various levels of experience, types of content, and so on.

To ensure maximum flexibility, we plan to support the annotation or tagging of content to include it in different structures, rather than organizing it in rigid categories. For example, some content on the HTML <img> element could potentially be useful in a course focused about HTML basics, a course about accessibility, or a course about web multimedia.

Some of the sorts of views we believe will be useful include:

• Core (“everyone should know and use this”)
• Implementation levels and stability indicators
• Maturity in standards bodies
• Device profiles (e.g., mobile, desktop, television)
• Types of content (e.g., tutorials, good practices, etc.)
• Origin of information (e.g., a particular browser vendor, a standards-setting organization, etc.)
• Knowledge level of audience: beginner, intermediate, advanced

It is a goal that the different views provide useful information (e.g, “what works reliably across major browsers”) and avoid confusion (e.g., “this is an unstable draft; use at your own risk” or “this is vendor-specific”).

The site will support translations. A similar organization is encouraged for non-English language areas.

Referencing system

The tagging system will also support a smart referencing system to make it easier to find related materials. Examples:

1. An article on responsive design discusses media queries, viewport, HTML5 <video>, and CSS transitions. Useful references would include links to “Learn the basics!” reading on each of the above topics, links to their defining specifications, links to more sophisticated topics (“build your own HTML5 <video> controls), etc.

2. In tutorials, mentions of HTML elements or CSS properties would like to the relevant specification. For every reference it would be really useful to display tutorial articles covering usage and examples in tutorials.

3. Code examples might be made available as standalone entities so that they could be transplanted into tutorials at appropriate places, but also just browsed on their own, without the tutorials.

Contributions and Attribution

• Contributors agree to license content they contribute, to be shared under the appropriate open license; initially, prose content and references will be licensed under CC-BY, and code examples will be made public domain under CC-0. Special dispensation may be made on a case-by-case basis for open content for which copyright assignment does not exist.
• People must have an account to edit the site, and must be logged in to do so.
• Contributors must cite sources when including content from other sites and must abide by copyrights and licenses for such content. Content whose inclusion violates anyone’s intellectual property rights will be removed.
• The community will develop good practices for recognizing significant contributions. Initially, we expect a manually-created list of contributors.
• Each contributor will have a profile page, which they can choose to populate or leave blank; profile pages will automatically include any affiliation and list of contributions.
• While users will be able to edit any content, we expect etiquette to govern interactions. For example, companies that include useful information about their products may prefer that their competitors do not make substantive edits to those contributions.

Quality Assurance

• Maintaining high quality is crucial for the success of the effort, and those who focus on updating articles to adhere to the Manual of Style are valued members of the community.
• Pages can be annotated with tags to register instances where an article does not adhere to one of the Manual of Style guidelines. This helps community members easily find articles that need attention, as well as communicate to readers that a page’s quality is not up to snuff. Helpful tags will be available, such as:
  • Template:Spam
  • Template:CompatibilityOutOfDate
  • {{NeedsExamples}]}
  • Template:NeedsAccessibility
  • …[e]
• Curriculum materials have a higher standard of quality to meet. Before publishing, all curriculum material will undergo a review process. This process is currently:
  • Author submits first draft.
  • Appointed tech reviewer looks over it and suggests technical corrections/improvements.
  • Author and/or other contributors can look it over and make corrections.
  • A final proof read should be done, to weed out language and stylistic errors.