Codex:Guidelines

This article seeks to outline recommended practices for editors and volunteers at WordPress Codex. Should you have a suggestion for improvement, please post a note on the WordPress Documentation mailing list.

Add a link from another article to your article to develop interconnections between articles. Do not create "dead-end pages". These are pages without links to other Codex pages.

Once pages are created they are live, and any links to them will work. When users click their way to an empty page, they have wasted their time. Only create pages when you have fairly complete and accurate content to put into them.

Once completed and moved out into the documentation from your user page, links must be made from the "sub" Table of Contents and other related documents to the new article. Ask if you are not sure of where to create a link from the sub-Table of Contents. Do not put a link on the Main Page without permission from the Documentation team.

Use the following "stubs", categories which designate the state an article is in:

{{Stub}}

The Stub categorizes the page as incomplete and in need of editing and expansion.

{{Draft}}

Put this at the top of the page. All pages added are scanned by search engines. The Draft notice at the top of every page will warn others that this is a work in progress, that the information may be incorrect, and may also warn others not to edit it until you are finished working on it.

[[Category:New page created]]

Defines a page as new and will attract the attention of editors. Do not use until you are ready for editing and/or moving the article out into the general documentation from your user page.

{{Copyedit}}

Put this at the bottom of the page. Copyedit designates this article as in need of work, usually general overview and editing. It marks it as fairly complete but needing review. Use {{Stub}} for incomplete articles. (see above)

Text Formatting

Predefined formatting markup is here to help you produce good looking articles and maintain a consistent look throughout the WordPress Codex. Please see the Editing Help article to learn how to use the correct markup for headings, paragraphs, character formating, links, multimedia, etc. In the Character Formatting section of that article, you will also find the recommended formatting for text with various emphasis or quality, such as terms and filenames.

Although WordPress Codex uses the wiki markup for general formatting, there are some specifics which you should adhere to when making your contribution, such as when you want to show some examples or code samples. See Codex Styles for more information and tips about these specifics.

Layout

Layout of WordPress Codex articles follows a simple convention. An article normally starts with a descriptive paragraph, though sometimes it may start with a section heading followed by an introductory paragraph. Following that, then the rest of the article is presented, and is divided into concise sections of information, examples, and images that help WordPress users understand the concept under discussion.

Try to stick with the topic of the article and make references to other WordPress Codex articles or sections within the same article where possible.

Resources

Resources are usually found at the end of the article in the section titled "Resources" and may include links to external sites. External links should be limited to the most reliable and consistent sources, preferably non-commercial sites, when possible.

Related Articles

You should also provide a section titled "Related" to allow visitors to effortlessly continue reading by visiting a related topic within a WordPress topic, or to help them find what they were initially looking for. The Related section is placed right after the Resources section at the end of the article, like in this article.

Titles

All headings must also be in Title Case. For example, use "Using the Links Manager" not "Using the links manager." These should be full titles i.e., not "IntroToBlogs" but "Introduction to Blogs."

They should also follow the Dr. Grammar rules regarding capitalization thus: "In titles, capitalize the first word, the last word, and all words in between except articles (a, an, and the), prepositions under five letters (in, of, to), and coordinating conjunctions (and, but). These rules apply to titles of long, short, and partial works as well as your own papers"(Anson, Schwegler, and Muth. The Longman Writer's Companion 240)

Titles are action or task-oriented whenever possible. So, "Using the Links Manager" is preferred to "The Links Manager" for example. What search words will a user use when looking for the information?

Titles shall not have leading or trailing spaces, or unnecessary spaces in between words. Try to avoid using symbols such as "-", "#", "?" and "+".

Shorter titles are better.

Please avoid using prepositions in titles, as far as possible.

The Codex is a wiki entirely dedicated to WordPress, so it is natural to have "WordPress" in titles.

In case of doubt regarding the suitability of a name, mail the wp-docs list and ask for suggestions.

Do not use CamelCase for page titles. The Codex does not use CamelCase like some other wikis do. All page titles, and therefore links, should be of normal title case. For example, the page about Codex should have the title "About Codex," with the link formatted as: [[About Codex]] and not the CamelCase [[AboutCodex]].

Links

Internal Links

Use internal links to direct the visitors to a specific topic covered in more detail by another article within WordPress Codex to keep the original article concise. You may also use internal links to point out that a special term is being mentioned, linking the term with the particular Glossary section or related article, or when describing where to find a specific feature, like: Administration Panels > Plugins > Add New. However, do not create links on every occassion, create them only when referring to a term, feature or article for the first time, except for when describing a path as above, because... it's handy and looking good :-)

Internal links to other articles that are closely related to the topic of the referring article, such as those from the same category, are listed in the Related section at the bottom of Codex articles.

External Links

External links are to be used judiciously as they can be notoriously difficult to maintain and verify. Use your best judgment, but consider the following when choosing to include an external link on the WordPress Codex:

The external site has a long history and is not expected to change domain names or become inactive or closed down.

A good majority of the overall content on the site is representative of WordPress, blogging, and the Open Source community (not a one-off article).

The site and its authors represent the WordPress Community.

The content is timeless, not restricted to one version or an out-of-date version of WordPress, as much as is possible.

The site does not sell, promote, or market products or services inconsistent with the WordPress GPL Policy.

The majority of the site and its content is dedicated to original content not advertising or unoriginal content.

There is no alternative to creating similar original content within the Codex.

External links are listed in the Resources section at the bottom of Codex articles. If they are included within the content, application of the above qualifications becomes even more stringent.

Links to Themes and Plugins

With the official directories in place for WordPress Plugins and Themes, all links to Plugins and Themes must only be to those listed within the directories. Links to authors' sites is not permitted.

Links to Commercial Content and Sites

The WordPress Codex documentation team is often faced with questions and decisions to remove links on the Codex to questionable sites. The following should hopefully clarify the decisions and actions.

External links must directly be applicable and relevant to the page content as a reference.

Links to sites which violate the WordPress GPL Policy, WordPress Trademark for domain names, WordPress Codex Guidelines, and long standing WordPress Community standards and practices are not permitted on the WordPress Codex.

Links to sites with the clear intention of selling WordPress services and products are not permitted, or used judiciously with the approval of the WordPress Codex documentation team or WordPress Foundation.

Links to sites with more commercial content, advertising, and intent, without a majority percentage dedicated to original content (and WordPress Community representation) are not permitted.

It is up to the best judgment of the WordPress Codex documentation and WordPress Foundation representatives to make the final call if a link is disputed.

All links in violation of these terms shall be removed.

Codex Categories

Each article within the WordPress Codex is categorized with specific categories, as listed on the Special:Categories listing. Please use one or more of the categories listed and do not add any new categories without approval from the WordPress Codex Documentation Team as a lot of work has gone into developing these categories.

To add a category to a page, at the bottom of the page use the following code, taking care to use the exact spelling and format from the Special:Categories list.

[[Category:Category name]]

An example would be:

[[Category:WordPress Lessons]]

Localization: For non-English language documents on the WordPress Codex, please use the two letter language code before the Category Name to group language specific documents:

[[Category:fr:Panneaux_Administration]]

You may also include the language-specific category for all documents in that language, such as:

[[Category:Turkish Codex]]

Link to a Category: To create a link to a category, use a colon before the word "Category" and add the link text for improved readability, such as:

[[:Category:WordPress_Lessons|WordPress Lessons]]

Which will appear in a sentence as:

You can find more helpful information in the WordPress Lessons category on the WordPress Codex.

Category Pages: Category pages are created automatically and customized by the WordPress Codex Documentation Team to include related and subcategories.

Some categorization makes sense. If an article is about WordPress Plugins, the Plugins definitely applies. However, what level of technical information is in the article? Who will benefit the most from reading it? If it is really basic, then it should be also categorized in the WordPress Lessons category. If it is advanced and technical, such as the coding and writing of Plugins, then it shouldn't be in the WordPress Lessons category. It should be in the Advanced Topics and/or WordPress Development, depending upon the sophistication of the information. Use your best judgment.

Adding a New Category

Categories in the WordPress Codex are added by the senior members of the WordPress Codex Documentation Team and reflect the table of contents of the Codex. In general, the criteria for adding categories to the Codex are:

Use Proper WordPress Terminology

While the names of WordPress features, functions and panels may change organically, in general, use the official names for the various features of WordPress when choosing the name for a new category, such as Administration Panels, not dashboard, admin panels or UI.

Adhere to Naming Convention

All category names must meet these guidelines and must use title capitalized, not lowercased as MediaWiki treats upper and lower case URLs as separate pages. Use of "WordPress" in a category name is acceptable and not to be avoided if necessary, such as "About WordPress" which is also preferred to only "About" as to allow "About Codex", "About Development", and other abouts to be used.

WordPress Codex Localization

All category names for translated and non-English language pages must feature the two letter language code before the category name, such as "fr:Panneaux Administration".

Consider the Audience

Create categories based upon keywords and search terms, words that will help the user find the information they need. If the information is basic, use the words "Beginner" or "Basic" in the category name, as well as "Advanced" if necessary.

SubPages

Do not create sub-pages of a page, other than from your own User page, without discussing it first on the wp-docs mailing list. Exceptions to this are the pages under Function Reference (each of which describes a single function).

Discussions

Using the "Talk" pages

Do you see something that is perhaps incorrect, or needs clarification? The best way to make mention of any issues is to use the Discussion function. Please refrain from adding your comments directly onto the article page. At the top of every page is a Discussion tab. This is the place to make your comments, suggestions, and such. Thank you!

Leaving Messages About the Article: To leave a message regarding the article, click the Discussion tab of that article and post your message and sign it (see below).

Leaving Messages for Users: Leave a message for a user by editing the User:Talk page associated with the user. Sign it (see below). The user will receive a visual prompt the next time they login to the Codex.

Separate Comments: Please create a horizontal rule between comments on the discussion page by using four dashes ---- between entries. If you are starting a new thread of conversation, consider using the "+" link next to edit, which lets you create a new section.

Always Sign Your Comments: To add your "signature" to a comment, add four ~s (tildes) at the end of your comment. This will list your User Name and a link to your User Page and add a time-stamp. This is very useful for discussion pages. An alternative method is to click on the signature icon at the top of the edit window...it's the second one from the right.

Codex Voice, Style, and Audience

The "voice" of the WordPress Codex is one of authority, but also a friendly conversational voice. The style of the Codex is to educate by providing simple and easy-to-use explanations when possible, and technical advice when necessary.

In general, articles are written to the reader, taking the reader through the process. The pronoun "I" is rarely used, focusing on "you click here" and "you open the template file". It is not about what you, the author, did, the story behind your decisions, or all the people who helped you succeed. It is about what the user needs to do in order to get their WordPress site up and functioning fast.

Bullets and lists are used to highlight the steps necessary to outline and streamline the process. Complicated tasks are broken down into small steps, guiding the novice or advanced user quickly to the solution.

The audience is extremely varied in ability and skill in HMTL, XHTML, CSS, and PHP. Articles found within the Advanced Topics and Developer Documentation are targeted for the experienced user. WordPress Lessons are designed for the novice, using language as if the author was the technical support volunteer sitting down next to the user at the computer, guiding them through the process. The rest of the Codex is targeted towards the beginner to intermediate level user and should contain simple language with links to definitions within the Glossary when necessary.

Conventions

Website Example Names: Always use example.com, example.org or example.net wherever you need to state a domain as an example. This is per RFC 2606.

Admin: The main admin user of a WordPress site always has the login admin. (In examples. A login of admin on a live site has negative security implications.)

Using people's names in examples: When a name is needed for an ordinary, non-admin user, or a person, use Harriet as the first name, and Smith as the last name.

Administration Panels: The WordPress interface is called Administration Panels not admin panels or dashboard. Dashboard is a specific panel within Administration Panels. Individual panels are also called Administration Screens.

WordPress is spelled WordPress: WordPress is spelled with two capital letters: WordPress.

Minor Edits

Whenever you edit a page you will see a checkbox with the label "This is a minor edit" above the save button. You should check this checkbox whenever you are making only a minor edit to a page. Examples of minor edits would be grammar and spelling corrections, small code formatting changes, etc. Minor edits are denoted by a lowercase "m"; for example on the recent changes page. If you are ever unsure whether your edit should be considered a minor edit or not, then leave the checkbox unchecked.