Editing-rules

From RDFaWiki

The basic guidelines for editing the wiki are below. Please be a good community member and adhere to all of the guidelines below when modifying wiki pages and interacting with the community in general.

Contents 1 Guidelines 2 Accessibility 3 Wiki Cleaning 4 Attribution

Guidelines

Before contributing please observe these guidelines:

1. You have to create an account (see Wikipedia Username guidelines) before editing/creating pages.
2. All edits to this wiki are placed under a Creative Commons 3.0 Attribution license. Know what this means before editing the wiki.
3. Join the public mailing list before making major edits to the wiki.
4. Please only create pages relating to RDFa on this wiki. Other pages will likely be deleted.
5. Please obey the naming conventions for pages.
6. Please try to ensure that you produce valid XHTML.
7. When you paste code, add some line breaks at a reasonable width.
8. 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, and copy/paste.
9. Use 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.
10. 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.
11. 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.
12. 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 raise the issue on the mailing list to make sure the community is okay with the change. Interpret absence of response(s) as disinterest and thus implicit rejection. Admins may from time to time do global wiki changes to remove spam or repair damage done by other global wiki edits.
13. 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. Finally, as such links do provide information, they are not redundant.
14. Do not use the MediaWiki "Categories" mechanism. As with "Talk" pages, this community does not use all the features of MediaWiki.
15. 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. [[ManuSporny]], rather than editing the link in place, create a redirect at the destination of the link to the person's User: page.
16. Check "what links here" before moving pages, and fix any links to the page you're moving, if appropriate.
17. Please use U.S. English (en-US) spellings of words on English microformats pages. This is by convention, following the W3C Manual of Style Spelling Editorial Guideline.
18. 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.
19. 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.
20. 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.
21. 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.
22. 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.

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

If you see something which you think needs massive cleanup on the wiki, please point it out to admins on the mailing list rather than doing it yourself.

Attribution

These rules have been adapted from the Wikipedia and Microformats community editing rules. If you have participated in either one of those communities, most of these should feel very familiar.