how-to-play-2

This page is a work-in-progress, draft rewrite of how-to-play. The aim is to produce a document that's clearer to newcomers, and better structured in general. The initial version of the page is a direct copy of the current how-to-play, and will be modified from there on.

Note that the numbering of each item is not finalized, and the auto-numbering of lists is broken up by line breaks to favour legibility in editing the document for the time being. (Numbering will be resolving later.)

Sections:

As well as rewriting the prose of some of the items to make them more approachable, they also get moved into some clear top-level headings:

• In general
  • General guidelines that apply to all mediums, general attitude
  • Key pieces of information that people should ensure they understand before participating
• On the wiki
  • Wiki specific guidelines, concerning page creation/editing/etc.
• On mailing lists
  • Link to mailing lists page, but also give brief intro to them, such that people get a decent idea of what they're for/why they're here from reading this page.
• In IRC
  • IRC specific stuff
• Creating new microformats
  • Link to The Process, but provide brief overview to cover the gotchas of creating new microformats, since some devs will arrive at this page because they want to create a new format.

Within those sections, the items themselves are being reordered into something more logical, such that subsections can be added where necessary. The current set-up is pretty much chronological.

In General

Thanks for getting involved in microformats development! This page helps you find your feet, sets out the methods we use to work productively, and provides a few ground rules and expectations. If this is your first visit, please see the introduction page, too.

The most important rules to fostering a healthy, productive open community:

1. Be nice. You are expected, and should expect in return, to act positively and treat your fellow members of this community with respect. Assume good intent; in precise scientific debate (as frequently occurs in standards development) you should be careful not to automatically perceive another person's tone as aggressive, even when they feel strongly about their opinions and statements. Conversely, be careful not to give that impression, either.

2. Microformat documentation (including the specifications) is released into the public domain. This mostly affects content on this wiki, but we encourage complete, open release of as much microformat-related material as possible. We ask that users active before 2008 consider adding the Template:cc-public-domain-release to their User Page so that their contributions to microformats.org made prior to 2008 will be released into the public domain .

1. When giving general examples, ensure that you use valid HTML or XHTML
   • Use indentation and line breaks for clarity
   • Please wrap lines at 78 characters, so that code can be reproduced (and quoted) within email

1. Please avoid simple contradictory responses such as "No" to questions and issues. Instead provide reasoning with information beyond what is provided in the question or issue.
   • Simple contradictions (inverting other statements on a page as if such an inversion was an argument) waste of time, bloat documentation.

1. Use example.org for hypothetical URL examples rather than a presumed-fake domain name (which may eventually be registered, used for spam etc.) On the wiki, wrap example domains in <nowiki> elements so that the URLs are not converted into hyperlinks, e.g.: <nowiki>http://example.org/</nowiki>.
   • Use different domain suffixes or sub-domains to show interactions between domains: example.net or example.com or foo.example.org and bar.example.org.

On the Wiki

1. Create an account before editing. Please consider using your real name, although you may use an alias if you like. Note that usernames need to be of the form FirstLast, or Nick. Please do not use organization names or other proper nouns (e.g. products, technologies) in your username. See also: Wikipedia Username guidelines.

1. Before editing, and in general, if in doubt, ask. Try the irc channel or mailing list if you have questions.

1. The microformats wiki exists to document microformats and some closely associated technologies and areas, namely POSH, picoformats. Discussion in directly related areas and applications of microformats (in line with the microformats principals such as data-portability is also encouraged. Be aware that off-topic pages may be deleted. If in doubt, ask.

1. Please use U.S. English (en-US) spelling for English documentation. This is by convention, following the W3C Manual of Style Spelling Editorial Guideline.
   • With exception of: Proper native spellings of proper nouns, e.g. "BT Centre", "Business Design Centre, London, UK", "Centre of Canadian Studies".
   • With exception of: Contributions to discussion content (content signed content within <div class="discussion"> blocks), which may be spelled in the author's native English.

1. You must follow the naming conventions when creating pages.
   • You can override the rendered page title to something more verbose if necessary using <entry-title> mark-up in the page.

1. Do create stubs or placeholder pages. Linking to pages that do not yet exist (e.g. this-page-does-not-exist) is useful, and indicates intent, and pages not yet created are automatically aggregated on Special:WantedPages. Manually creating placeholders breaks that functionality.

1. Please don't add pages to arbitrary MediaWiki Categories. We use a limited number of categories in order to group specifications and drafts (and the category assignments are used to render them differently than other wiki pages, e.g. hCard).
   • Specifications are categorised [[Category:Specifications]]</code> and draft specifications into <nowiki>[[Category:Draft Specifications]]
   • If you think of additional categories that would help the community, please add them to the category-suggestions page and seek community feedback.

1. Use templates for RFC 2119 terms such as MUST, as this uses consistent formatting.

1. References to (X)HTML element names should be lowercase and marked up with code elements, e.g. the <code>input</code> element. (This convention is adopted from the practice used in the W3C Manual of Style.)

1. Multi-line code examples should be contained in <source lang="html4strict">…</source> elements — this uses a plug-in in MediaWiki to syntax highlight your code.

1. Avoid global editorial changes / edits. Don't make the same or similar edits to numerous pages, (say, more than a dozen or so pages) for editorial reasons. If you have an opinion on how to globally improve something stylistically or editorially on the wiki, please note it to the to-do page, and engage the community using the microformats-discuss mailing list. Interpret absence of response(s) as disinterest and thus implicit rejection.

1. Consider waiting at least 10 minutes after the most recent edit before making your own edit. The previous editor may have further edits to make. Waiting a few minutes avoids potential conflicts and confusion.
   • 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!)

1. When adding your opinion to pages (rather than adding to documentation), you must date and sign your comments with your username (use the --~~~~ shorthand to do this). Discussion on the wiki should be threaded in lists, and wrapped in a <div class="discussion"> block.
   • You must not alter the meaning of other people's signed comments.
   • You should not personalize proposed documentation such that it detracts from logical reasoning.

1. Please do not remove apparently broken links (404 etc.). If you cannot fix them, instead de-link them by wrapping <nowiki> tags around them, and add a note that the link stopped working as of a certain date. This way the context of the documentation is maintained, the person responsible for the links may fixthe problem, and those researching the links can look them up in the Internet Archive.

1. Avoid splitting pages. Do not split, divide, sub-divide, or otherwise reorganize pages unless you are one of the primary editors of such pages. You may not understand the intent of the authors/creators for the organization and growth of that content, and by splitting or reorganizing it, you might cause them work and inconvenience. Admins are responsible for reverting such splits.
   • If you think a page should be reorganized in some way, and are not yourself responsible for it:
     • Add notes in the page in-place where you think splits need to occur, and how you think they should occur, so that the primary author(s) have a chance to see and follow-up with refinements/changes.
     • When deciding how to split pages, consider doing so in ways that both make it easier for people to find information, easier for contributors to add information, and easier for people to iterate the documentation. See how-to-split-pages for more details.

1. In general, avoid doing large "clean-up" operations on the wiki for the same reasons as avoiding splitting pages. You're encouraged to incrementally improve to pages, and work with primary page editors for more substantial changes. Admins are responsible for reverting large reorganizations of pages.

1. Note that we don't use the ‘talk pages’ feature of MediaWiki on the microformats wiki as it fragments functionality offered by IRC and the mailing lists, as well as other pages on the wiki.

Need verifying

Some old how-to-play rules based on technical limitations of the wiki, and so worth revisiting since we upgraded.

1. 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.
2. 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.
3. 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.

1. Start headings with a letter (or underscore a letter doesn't work), in order to generate valid ID attributes on heading elements.

No longer applicable

1. Check "what links here" before moving pages, and fix any links to the page you're moving, if appropriate.

On the Mailing Lists

IRC

Creating Microformats

1. 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. Further, this avoids having criticisms of an idea be confused as criticisms of the author.

Unrefined how-to-play content that hasn't been moved into the above follows:

Guidelines

1. 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]

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 ([1] 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