how-to-play

If this is your first visit, please see the introduction page.

Please also review the in-progress how-to-play-2 page and provide feedback on it!

Guidelines

Before contributing please observe these guidelines:

1. You have to create an account before editing/creating pages. Please consider using your name, e.g. GivenFamily (FirstLast), see also Wikipedia Username guidelines. You may use an alias (e.g. User:Adactio, User:Phae). Please do not use organization names or other proper nouns (e.g. products, technologies).
2. Read about microformats.org Public Domain Declarations and please consider adding the Template:cc-public-domain-release to your User page accordingly to release your contributions to microformats.org before 2008 into the public domain.
3. Try the irc channel (preferable) or mailing lists first (and read the mailing-lists page before doing so).
4. If you write something more opinion rather than logically reasoned, sign it with your username - you can easily do so with a datetimestamp in MediaWiki with four tildes, e.g.: ~~~~.
   • On the few occasions when it is necessary to edit others signed contributions (as opposed to general content), take care not to change their meaning.
   • If your logically reasoned statement is part of a discussion which disagrees with a previous comment, you may sign it with your username. However signing such statements is both not required, and may detract from the logically reasoned statement standing on its own (related: avoid personalizing proposals), and thus consider leaving such statements unsigned. [src:A]
5. Please only create pages directly relating to POSH, microformats (and picoformats) on this wiki. data-portability in line with microformats principles is also encouraged. Other pages will likely be deleted.
6. Please obey the naming conventions for pages. [src:A]
7. Don't use talk pages. See #3. [src:A]
8. Please try to ensure that you produce valid XHTML.
9. When you paste code, add some line breaks at a reasonable width.
10. Please do not use "?" or other punctuation in the headings - it helps to keep the URLs to their fragment identifiers shorter and easier to read, copy/paste etc. [src:A]
11. Consider using lowercase words in headings (except for proper nouns), and avoid repeating the page title in headings. This helps with shortening permalinks to sections (thereby increasing fidelity of URL transfer, e.g. across email), and keeping their URLs all lowercase makes them easier to type. [src:A]
12. Headings may be explicitly marked up with <h1> <h2> tags etc. in order to avoid having them show up / pollute the Table of Contents. If you find such headings in a page, please do not change them to "=" or "==" style headings. [src:A]
13. Avoid renaming/changing heading text, including even just their capitalization or to comply with above rules that apply to headings. Headings are often used as permalinks, and changing the heading breaks such permalinks that have already been used. Thus be careful when creating headings. If you change a heading please leave a <div id="oldheadingID"></div> around the new heading with oldHeadingID set to the necessary value to maintain heading permalinks.[src:A]
14. Start headings with a letter (or underscore a letter doesn't work), in order to generate valid ID attributes on heading elements.
15. Avoid global editorial wiki changes / edits (e.g. the same or similar edits applied to numerous pages, say, more than a dozen or so pages). If you have an opinion on how to globally improve something stylistically or editorially on the wiki, please add it to your section on the to-do page, and then perhaps ask the community using the microformats-discuss mailing list what folks think of it. Interpret absence of response(s) as disinterest and thus implicit rejection. Admins may from time to time do global wiki changes to remove spam, repair damage done by other global wiki edits etc.[src:A]
16. Please avoid simple contradictory responses such as "No" to questions and issues. Instead provide at least a short sentence with a reason which provides information beyond what is provided in the question or issue. Simple contradictions (like just inverting other statements on a page as if such an inversion was an argument), are a waste of time and space and to be avoided.[src:A]
17. Do not remove "red links", nor create empty / placeholder "..." pages for them just to make them not red. The red links usefully communicate a need or a desire for that page to exist, and the person expressing that desire may not be the same person that is able to take the time, or has the necessary skill/background to draft such a page. The links to pages not yet created often serve as an effective (and easy to execute) "to do" list. Removing those links makes it harder, less convenient to do so. (One exception noted so far: red links to non-existent microformats e.g. "hbib", should be delinked, as it is desirable for it to be harder/less convenient to create new microformats). Finally, as such links do provide information, they are not redundant. [src:A]
18. Please do not add MediaWiki Categories. With the upgrade to the wiki we have begun using a very limited number of categories in order to present specifications and drafts differently than other wiki pages. For now if you think additional Categories would help the community, please make suggestions on the category-suggestions page. [src:TI]. Previously: Do not use the MediaWiki "Categories" mechanism. As with "Talk" pages, this community does not use all the features of MediaWiki.[src:A]
19. Do not create new "User:" links by hand. User: links should only created as a result of users actually signing their edits with ~~~ or ~~~~. That way each User: page will correspond to an actual login, rather than accidentally linking to a page which doesn't represent a login. If you see a red link which appears like it should be a User: link, e.g. [[DavidJanes]], rather than editing the link in place, create a redirect at the destination of the link to the person's User: page.[src:A]
20. Check "what links here" before moving pages, and fix any links to the page you're moving, if appropriate.
21. Please use U.S. English (en-US) spellings of common words on English microformats pages. This is by convention, following the W3C Manual of Style Spelling Editorial Guideline. [src:A]. Exception: Please use and maintain the proper native spellings of proper nouns, e.g. "BT Centre", "Business Design Centre, London, UK", "Centre of Canadian Studies", etc. [src:AD([1])]
22. Use templates for RFC 2119 terms such as MUST.
23. References to (X)HTML element names should be lowercase and marked up with <code>...</code>, e.g. the input element. This convention is adopted from the practice used in the W3C Manual of Style.
24. Add whitespace to markup examples for readability. Real world markup examples are often whitespace collapsed, often with all the markup/content on a single line of text. Please add whitespace (e.g. returns between elements, indentation to indicate element depth) to markup examples.
25. Use example.org for hypothetical URL examples rather than a fake domain name (which may eventually be registered, used for spam etc.). When doing so, be sure to use <nowiki> tags, e.g.: <nowiki>http://example.org/</nowiki> so that the URLs are not auto-hyperlinked by MediaWiki. Where interactions between multiple domains need to be illustrated, you may use example.net or example.com or subdomains of example.org like foo.example.org.
26. If you notice that someone is iteratively editing a page (say by watching the IRC channel, or the Special:Recentchanges page) that you'd like to edit, consider waiting at least 10 minutes after the most recent edit before doing so, as the person iteratively editing the page may have further edits to make, and thus waiting a few minutes would likely save you both time by avoiding potential/likely edit conflicts. Similarly, if you plan to make multiple edits to a page, consider using Template:inuse by placing {{Template:inuse}} at the head of the page. Please don't forget to remove it, when you're done! [src:A]
27. Please do not remove apparently broken links (404 etc.). If you cannot fix them, de-link them using <nowiki> and note (perhaps with a nested list item or parenthetical remark) that the links appear to have stopped working as of a certain date. This way whoever added the links or is responsible for them may discover that they need to fix them, and those researching the links can still look them up in the Internet Archive. [src:A]
28. Avoid labeling proposals with people's names. Instead please label a proposal using a summary of some (perhaps unique) technical aspect of the proposal. The reasons for this are to avoid overly "personalizing" an idea and having the idea be judged (positively or negatively) by the author associated with it rather than the merits of the idea itself, to avoid having criticisms of the idea even remotely appear as if they are criticisms of the person, and to avoid having a specific person feel like they must defend attacks on an idea as if they were attacks on their person. [src:A]
29. Avoid splitting most pages. Do not split, divide, sub-divide, or otherwise reorganize pages unless you are one of the primary authors of such pages. The reason is that you may not understand what the authors/creators of that page had/have in mind for the organization and growth of the content of the page, and by splitting it or reorganizing it, you might actually cause them more work and inconvenience, as well as raising the barrier to editing and/or contributing to the page for new folks as well, thus discouraging community participation. Admins will likely revert such splits. [src:A([2] [3])]
30. If you do see a need to split a page which you are not one of the primary authors of, first add notes in the page in-place where you think splits need to occur, and how you think they should occur, before making any split, so that the primary author(s) have a chance to see and follow-up with refinements/changes on how the pages should be split. When deciding how to split pages, consider doing so in ways that both make it easier for new contributors to add information, making it easier for people to iterate, and making it easier for people looking from a real world perspective to find the information. See how-to-split-pages for more details. [src:A([4])]
31. In general, avoid doing large "clean up" operations on the wiki for the same reasons as avoiding splitting most pages. Admins will likely revert such large re-organizations of pages and encourage incremental improvements, and suggesting larger improvements to the primary page authors. [src:A]
32. Write simply, and directly, assuming an eager(impatient,positive) reader in the primary reading flow. Move (keep) clarifications/details/documentation for edge case people (i.e. deliberate misinterpreters, sarcastic skeptics etc.) to details further down in a page (or on subpages) rather than in the primary reading flow. (ed: clearly how-to-play (and many other pages) need(s) to be rewritten from this perspective. I've updated the Main Page accordingly and captured the rest as a to-do - Tantek 17:40, 3 April 2012 (UTC) )

Accessibility

1. Use upper case for acronyms like HTML but use <strong style="text-transform:uppercase"> to add strength to phrases like "do not". This improves accessibility for people using text-reading software and other assistive technologies ([5] PDF) (list and versions of text-reading software & other agents affected needed).
2. Do not use styles or write in ways which contravene Web Content Accessibility Guidelines 1.0. For example, do not rely on color alone to convey information; mark up lists and list items properly.

Wiki Cleaning

See spam-removal.

If you see something which you think needs massive cleanup on the wiki, please point it out to admins on the irc channel or microformats-discuss list rather than doing it yourself. [src:A]

Related

• mediawiki-customization - brief notes on how the microformats wiki is different from a "typical" MediaWiki install, in many ways to help with how-to-play and naming-conventions.
• wiki2
• wiki-better-than-email
• how-to-play-2