Mailing Lists

(Difference between revisions)

Jump to: navigation, search
Current revision (23:54, 10 June 2016) (view source)
(Be nice: subhead for citation)
 
(4 intermediate revisions not shown.)
Line 1: Line 1:
-
HOW THING OUT
+
<entry-title> Mailing Lists </entry-title>
-
HOW ANYTHING OUT
+
 
-
HOW EVERYTHING OUT
+
== Redirect to IRC ==
-
HOW UNIVERSE OUT
+
If someone emails you directly, asking about microformats, or making a proposal, if you can answer *quickly* (like a one liner, like "use [[h-card]] to markup people and organizations"), then do so, but always redirect them to [[IRC]] for discussion. E.g. here's an email template you may use:
-
HOW MAKE THING OUT
+
 
-
HOW MAKE ANYTHING OUT
+
=== Email Template to IRC ===
-
HOW MAKE EVERYTHING OUT
+
<blockquote><p>
-
HOW MAKE UNIVERSE OUT
+
Hi,
-
HOW THING BE OUT
+
</p><p>
-
HOW ANYTHING BE OUT
+
Thanks for your interest in microformats!
-
HOW EVERYTHING BE OUT
+
</p><p>
-
HOW UNIVERSE BE OUT
+
We're a community based organization, and thus I'd definitely prefer discussing this in our public forum:
-
HOW MAKE THING BE OUT
+
</p><p>
-
HOW MAKE ANYTHING BE OUT
+
irc://irc.freenode.net/microformats
-
HOW MAKE EVERYTHING BE OUT
+
</p><p>
-
HOW MAKE UNIVERSE BE OUT
+
If you need help with joining the #microformats forum on Freenode, see:
-
HOW THING OUT
+
</p><p>
-
HOW ANYTHING OUT
+
http://microformats.org/wiki/irc
-
HOW EVERYTHING OUT
+
</p><p>
-
HOW UNIVERSE OUT
+
There are community members from all around the world in the forum, which is also logged and read by many others even if offline. Go ahead and ask any questions you want to about microformats there, and someone will likely work with you to figure out the answers!
-
HOW MAKE THING OUT
+
</p><p>
-
HOW MAKE ANYTHING OUT
+
Thanks again, and see you on #microformats!
-
HOW MAKE EVERYTHING OUT
+
</p></blockquote>
-
HOW MAKE UNIVERSE OUT
+
 
-
HOW THING BE OUT
+
{{warning|This page is in general out of date, see [[irc]] for discussions.}}
-
HOW ANYTHING BE OUT
+
 
-
HOW EVERYTHING BE OUT
+
= Historical Archive of Mailing List Info =
-
HOW UNIVERSE BE OUT
+
 
-
HOW MAKE THING BE OUT
+
Read the [http://microformats.org/discuss/ microformats discuss page] first.
-
HOW MAKE ANYTHING BE OUT
+
 
-
HOW MAKE EVERYTHING BE OUT
+
Then read the [http://microformats.org/mailinglists-policies/ mailing list policies].
-
HOW MAKE UNIVERSE BE OUT
+
 
-
HOW THING OUT
+
Then read the respective archives ([http://microformats.org/discuss/mail/microformats-discuss/ -discuss], [http://microformats.org/discuss/mail/microformats-dev/ -dev], [http://microformats.org/discuss/mail/microformats-new/ -new]).
-
HOW ANYTHING OUT
+
 
-
HOW EVERYTHING OUT
+
After that please see the following additional notes of scope and topics for each list. 
-
HOW UNIVERSE OUT
+
 
-
HOW MAKE THING OUT
+
== Getting subscribed ==
-
HOW MAKE ANYTHING OUT
+
To subscribe to any of the mailing lists discussed below, please see http://microformats.org/discuss/ - here you will find all relevant subscription links, archives and also access to lists you are already subscribed to where you may change the email address you are subscribed with and the level of emails you will receive (all or digest).
-
HOW MAKE EVERYTHING OUT
+
 
-
HOW MAKE UNIVERSE OUT
+
== General guidelines ==
-
HOW THING BE OUT
+
Here is a list of general guidelines to follow in microformats list discussions in general.  The overall goal of many of these guidelines is to increase the signal to noise ratio on the lists by encouraging signal, and discouraging noise. Maximizing the signal-to-noise ratio (S/N) is essential to scaling a list membership, and thus as microformats grow in popularity, maximizing S/N becomes more and more important. If you have suggestions for general guidelines, please post them to the microformats-discuss list so that the list-admins may consider your suggestions.
-
HOW ANYTHING BE OUT
+
 
-
HOW EVERYTHING BE OUT
+
=== Send plain text email only ===
-
HOW UNIVERSE BE OUT
+
The microformats mailing lists are configured to only accept plain text (text/plain) emails.
-
HOW MAKE THING BE OUT
+
 
-
HOW MAKE ANYTHING BE OUT
+
If you get an error message like:
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
<blockquote>The message's content type was not explicitly allowed</blockquote>
-
HOW THING OUT
+
 
-
HOW ANYTHING OUT
+
Change your email client to send text/plain.
-
HOW EVERYTHING OUT
+
 
-
HOW UNIVERSE OUT
+
For example, in Gmail, you have to go into Settings (under the gear icon menu in the top right), and  at the bottom, choose:
-
HOW MAKE THING OUT
+
 
-
HOW MAKE ANYTHING OUT
+
'''Outgoing message encoding: '''<br/>
-
HOW MAKE EVERYTHING OUT
+
'''&nbsp;(*) Use default text encoding for outgoing messages''' <br/>
-
HOW MAKE UNIVERSE OUT
+
'''&nbsp;( ) Use Unicode (UTF-8) encoding for outgoing messages'''
-
HOW THING BE OUT
+
 
-
HOW ANYTHING BE OUT
+
In addition, if you're using the recently "new" Gmail "Compose" feature, you may have to click the little drop-down arrow button menu to the bottom right of the compose text area, and make sure that
-
HOW EVERYTHING BE OUT
+
 
-
HOW UNIVERSE BE OUT
+
'''&nbsp;[x] Plain text mode'''
-
HOW MAKE THING BE OUT
+
 
-
HOW MAKE ANYTHING BE OUT
+
is checked.
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
=== Be nice ===
-
HOW THING OUT
+
The microformats.org community is quite different than both other standards organizations and most open source efforts in (at least) one very important way: this community is a much nicer place to be, with people in general treating each other with a lot of respect and benefit of the doubt.
-
HOW ANYTHING OUT
+
 
-
HOW EVERYTHING OUT
+
This guideline, which may seem totally obvious, is made explicit because of a few bad examples.
-
HOW UNIVERSE OUT
+
 
-
HOW MAKE THING OUT
+
This friendlier tone in the community is something that the community very much values and will fight to defend. The [[admins]] will take swift action to ban or moderate individuals who essentially are "jerks" on IRC or any of the lists.
-
HOW MAKE ANYTHING OUT
+
 
-
HOW MAKE EVERYTHING OUT
+
If you see someone being rude, please ask them *privately* to not do so, and if necessary contact one or more of the [[admins]], again privately (feel free to CC them on a single email) pointing out the behavior. Admins will likely respond to rude individuals publicly to make it clear their behavior is not acceptable.
-
HOW MAKE UNIVERSE OUT
+
 
-
HOW THING BE OUT
+
Note: neutral tone emails that use simple logical/rational emotion-free language are perfectly fine.  This guideline is not a request to add artificial kindness etc. to emails. Nor is it a discouragement to engage in constructively critical discourse.
-
HOW ANYTHING BE OUT
+
 
-
HOW EVERYTHING BE OUT
+
Personal attacks are unacceptable and may be given a warning by an admin and then blocking upon any additional instance. See [http://en.wikipedia.org/wiki/Personal_attack Wikipedia:No personal attacks]: <blockquote><p>Comment on content, not on the contributor. Personal attacks do not help make a point.</p></blockquote> Personal Attacks ([https://secure.wikimedia.org/wikipedia/en/wiki/Ad_hominem ad hominem], [https://secure.wikimedia.org/wikipedia/en/wiki/Name_calling name-calling], etc.) on one or a set of individuals will be pointed out by the admins, and will likely only receive one warning. Upon a second such personal attack an admin will likely ban the attacking individual.
-
HOW UNIVERSE BE OUT
+
 
-
HOW MAKE THING BE OUT
+
If you do make a mistake and make a personal attack, consider following-up with a public apology, as doing so demonstrates personal responsibility, good will, and a desire to improve the overall tone of conversations.
-
HOW MAKE ANYTHING BE OUT
+
 
-
HOW MAKE EVERYTHING BE OUT
+
=== Why to avoid negative behaviors ===
-
HOW MAKE UNIVERSE BE OUT
+
* <cite>[http://headrush.typepad.com/creating_passionate_users/2006/04/angrynegative_p.html Angry/negative people can be bad for your brain]</cite> by Kathy Sierra
-
HOW THING OUT
+
* <cite>[http://www.smithsonianmag.com/arts-culture/Choosing-Civility-in-a-Rude-Culture.html Smithsonian.com: Choosing Civility in a Rude Culture]</cite>
-
HOW ANYTHING OUT
+
* <cite>[http://www.paulgraham.com/trolls.html Paul Graham's Gresham's Law of trolls]</cite> - in short: trolls use forums with thoughtful people, but thoughtful people leave forums with trolls.  Thus if a community wants to keep thoughtful people, it must pro-actively ban those that troll.
-
HOW EVERYTHING OUT
+
* <cite>[http://video.google.com/videoplay?docid=-4216011961522818645 Google Video: How Open Source Projects Survive Poisonous People]</cite> - 55 minute Google Tech Talk, 2007-01-25: Summary: <blockquote> Every open source project runs into people who are selfish, uncooperative, and disrespectful. These people can silently poison the atmosphere of a happy developer community. Come learn how to identify these people and peacefully de-fuse them before they derail your project. Told through a series of (often amusing) real-life anecdotes and experiences.</blockquote>
-
HOW UNIVERSE OUT
+
** [https://msujaws.wordpress.com/2011/01/25/protecting-your-open-source-project-from-poisonous-people/ Protecting your open source project from poisonous people] - blog post about a similar talk
-
HOW MAKE THING OUT
+
*** [https://docs.google.com/document/pub?id=1E-ZfKciAfiC1qhvnkB3FUrYHBSCxhBhhva5nag33HPs How to protect your open source project from poisonous people] notes referenced from said blog post
-
HOW MAKE ANYTHING OUT
+
* <cite>[https://harthur.wordpress.com/2011/06/30/dealing-with-not-dealing-with-the-open-source-assholes/ Dealing With (Not Dealing With) the Open Source Assholes]</cite>
-
HOW MAKE EVERYTHING OUT
+
* <cite>[http://www.plausiblydeniable.com/opinion/gsf.html Five Geek Social Fallacies]</cite>
-
HOW MAKE UNIVERSE OUT
+
* <cite>[http://ASIN.cc/~3SiWw The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn't]</cite>
-
HOW THING BE OUT
+
 
-
HOW ANYTHING BE OUT
+
=== Be patient ===
-
HOW EVERYTHING BE OUT
+
The community, as part of its broader positive tone, tries to be fairly patient with folks, and we want to continue to encourage that.  The microformats lists will always (assuming continued growth and popularity) get new subscribers, and these new subscribers may be unfamiliar with the customs and conventions of the community.  As an experienced member in the community, please be patient with new subscribers, and help them improve their behavior by kindly pointing out relevant guidelines and answers on the wiki. However, if it appears that a newcomer has a negative attitude, please raise it to the attention of the admins (offlist) with an official complaint email that references (by email archive URL) or includes the email that demonstrates the negative attitude.  Negativity is the biggest exception - this community has very little patience for negativity (see previous '''Be nice''' guideline).
-
HOW UNIVERSE BE OUT
+
 
-
HOW MAKE THING BE OUT
+
=== Use real world examples ===
-
HOW MAKE ANYTHING BE OUT
+
People often invent completely fictitious (and theoretical) [[examples]] in response to (perhaps rhetorical) questions or to make a point they are trying to make.  microformats themselves are based on studying real world examples and designing for real world examples.  Thus arguments based on theoretical examples hold much less weight in microformats discussions.  Please avoid posting arguments / questions based solely on theoretical examples. [<abbr title="guideline created due to one or more actions by Andy Mabbett and others">src:A,o</abbr>].
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
If a theoretical example seems compelling to you (perhaps others may have brought it up as well), instead of emailing about it, document it on the respective specific microformat's *-brainstorming wiki page, (preferably near the bottom), and explicitly labeled as a "*theoretical example*".
-
HOW THING OUT
+
 
-
HOW ANYTHING OUT
+
==== Ask for real world examples ====
-
HOW EVERYTHING OUT
+
If someone discusses or provides arguments based on theoretical examples, then:
-
HOW UNIVERSE OUT
+
* ask them to provide a real world example with URL(s) and point them to [[mailing-lists#Use_real_world_examples|the above guideline]].
-
HOW MAKE THING OUT
+
* ask them to document their theoretical example on the respective specific microformat's *-brainstorming wiki page. Provide a direct link to the *-brainstorming page as a courtesy. Doing so may help reduce the reraising of the same theoretical example.
-
HOW MAKE ANYTHING OUT
+
 
-
HOW MAKE EVERYTHING OUT
+
==== Use URLs to examples ====
-
HOW MAKE UNIVERSE OUT
+
Please provide URLs to real world examples when possible. This helps to validate that such examples truly are "real world" as they are on the public Web, and provides additional context around the example which might be crucial to understanding it or answering questions about it. [<abbr title="guideline created due to one or more actions by Andy Mabbett and others">src:A,o</abbr>]
-
HOW THING BE OUT
+
 
-
HOW ANYTHING BE OUT
+
==== Ask for URLs to examples ====
-
HOW EVERYTHING BE OUT
+
When people do not provide a specific URL to a test case or example, then especially as a developer, PLEASE ask them to provide a specific URL (and cite [[mailing-lists#Use_URLs_to_examples|the previous guideline]]) rather than attempting to work out how an inline snippet of code might work.
-
HOW UNIVERSE BE OUT
+
 
-
HOW MAKE THING BE OUT
+
=== Use the wiki to share state instead of email ===
-
HOW MAKE ANYTHING BE OUT
+
<span id="usethewiki">Use the wiki.</span> Summary: Please add any substantial content to the wiki and use email only for referring to the URLs on the wiki accordingly.  If you're not sure where to add something, ask in [[IRC]] or on the list.
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
In particular: when providing examples or (re-)raising/opening a discussion on IRC or the mailing lists, please provide a URL to the relevant wiki page which captured the example or state of the discussion previously.
-
HOW THING OUT
+
 
-
HOW ANYTHING OUT
+
If you can't find the relevant wiki page, ask for it (on [[IRC]] or on the microformats-discuss mailing list). If no one can find it, ask for help creating a wiki page for it. Then [[put-it-on-the-wiki]]. [<abbr title="guideline created due to one or more actions by Andy Mabbett and others">src:A,o</abbr>]
-
HOW EVERYTHING OUT
+
 
-
HOW UNIVERSE OUT
+
See [[wiki-better-than-email]] for some background and explanations of how and why the wiki works better than email for content in general (whether issues, brainstorms, etc.).
-
HOW MAKE THING OUT
+
 
-
HOW MAKE ANYTHING OUT
+
==== Read FAQs before asking questions ====
-
HOW MAKE EVERYTHING OUT
+
Especially read relevant/respective FAQs before asking questions. Before asking a question on a microformats list, read the relevant FAQs:
-
HOW MAKE UNIVERSE OUT
+
# Start with the general microformats [[faq]]
-
HOW THING BE OUT
+
# Then read specific microformats FAQs, e.g. for [[rel-tag]], see the [[rel-tag|rel-tag FAQ]], for [[adr]], see the [[hcard-faq|hCard FAQ]] as the spec indicates, etc.
-
HOW ANYTHING BE OUT
+
 
-
HOW EVERYTHING BE OUT
+
==== Cite URLs to answer questions ====
-
HOW UNIVERSE BE OUT
+
When answering questions on a list, cite URL(s) to FAQ answers. Despite the previous guidelines, experience has shown us that there will be time that smart, considerate individuals may attempt to look for an answer on the FAQ, and not find it despite it being there. In such cases, assume that it was a simple unintended oversight (rather than laziness or failure to check the FAQ), and when answering such a question on a microformats list:
-
HOW MAKE THING BE OUT
+
# Please check the relevant FAQs first, and if the answer is not there, document the question and your answer there. I.e. [[put-it-on-the-wiki]].  This is so that the community memory of answers (especially the most recent and accurate state of answers) is kept and grown in a semi-organized and hopefully easily findable fashion on the wiki, rather than deep in the depths of email archives which are often much more difficult to search, and difficult to tell what answer is "the" most recent, relevant and accurate answer.
-
HOW MAKE ANYTHING BE OUT
+
# Cite URL(s) FAQ answer(s) (that you may have just written) rather than just writing an answer, when composing your reply in email.  This will hopefully encourage more reading of the wiki and thus learning of answers to microformats related questions in general.
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
Note: when citing URLs, make sure they answer the specific question being asked.  For additional advice about providing good "RTFM" messages see JimboJW's blog post: <cite>[http://jimbojw.com/wiki/index.php?title=Irresponsible_use_of_RTFM_doesn%27t_help_anyone Irresponsible use of RTFM doesn't help anyone]</cite>.
-
HOW THING OUT
+
 
-
HOW ANYTHING OUT
+
==== Raise issues on the wiki not in email ====
-
HOW EVERYTHING OUT
+
If you find an issue with a microformat, please <em>first</em> read the respective [[faq]] and [[issues]] pages for that microformat before raising the issue.  If the issue is already documented on the wiki, please add any new comments there (do not simply repeat statements that others have made, nor repeat your own statements). [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]
-
HOW UNIVERSE OUT
+
 
-
HOW MAKE THING OUT
+
When someone does raise issues via email, kindly request that they raise issues via the wiki instead, e.g.:
-
HOW MAKE ANYTHING OUT
+
 
-
HOW MAKE EVERYTHING OUT
+
<blockquote>
-
HOW MAKE UNIVERSE OUT
+
<p>Please capture specific issues regarding a specific microformats on the respective *-issues wiki page rather than email.</p>
-
HOW THING BE OUT
+
<p>If there is a specific issue that applies to several microformats (e.g. class microformats) add it to:</p>
-
HOW ANYTHING BE OUT
+
<p>
-
HOW EVERYTHING BE OUT
+
http://microformats.org/wiki/issues
-
HOW UNIVERSE BE OUT
+
</p>
-
HOW MAKE THING BE OUT
+
</blockquote>
-
HOW MAKE ANYTHING BE OUT
+
 
-
HOW MAKE EVERYTHING BE OUT
+
==== Point out reraised issues and redirect follow up to the wiki ====
-
HOW MAKE UNIVERSE BE OUT
+
When someone does (re-)raise an issue via email that is already on the wiki, rather than arguing the issue in email, point out that the issue is already documented on the wiki (preferably with a URL to the issue, add a fragment identifier if necessary), and ask them to follow-up on the wiki, e.g.:
-
HOW THING OUT
+
 
-
HOW ANYTHING OUT
+
<blockquote>
-
HOW EVERYTHING OUT
+
<p>Note that this is an already documented issue:
-
HOW UNIVERSE OUT
+
</p><p>
-
HOW MAKE THING OUT
+
http://microformats.org/wiki/issues#specific-issue-fragment
-
HOW MAKE ANYTHING OUT
+
</p><p>
-
HOW MAKE EVERYTHING OUT
+
Please add any follow-up there rather than in email.
-
HOW MAKE UNIVERSE OUT
+
</p><p>
-
HOW THING BE OUT
+
Thanks,
-
HOW ANYTHING BE OUT
+
</p></blockquote>
-
HOW EVERYTHING BE OUT
+
 
-
HOW UNIVERSE BE OUT
+
This will hopefully end the thread and thus avoid further email on a topic that is already documented on the wiki.
-
HOW MAKE THING BE OUT
+
 
-
HOW MAKE ANYTHING BE OUT
+
==== Reply to email followups to issues with request to use wiki instead ====
-
HOW MAKE EVERYTHING BE OUT
+
When someone debates/follows-up to an issue via email (rather than doing the above and requesting that the issue be documented in email), request to the person following-up to please add their follow-up to the wiki instead (even if that means also adding the original issue), e.g.:
-
HOW MAKE UNIVERSE BE OUT
+
 
-
HOW THING OUT
+
<blockquote>
-
HOW ANYTHING OUT
+
<p>
-
HOW EVERYTHING OUT
+
Please follow-up to issues raised in email by directing folks to raise issues on the respective *-issues wiki page rather than following-up to issues in email.
-
HOW UNIVERSE OUT
+
</p><p>
-
HOW MAKE THING OUT
+
Thanks,
-
HOW MAKE ANYTHING OUT
+
</p>
-
HOW MAKE EVERYTHING OUT
+
</blockquote>
-
HOW MAKE UNIVERSE OUT
+
 
-
HOW THING BE OUT
+
=== Avoid wasting others time by sending a lot of email ===
-
HOW ANYTHING BE OUT
+
Historically a few individuals have overloaded some of the microformats mailing lists with a lot of email.  As each individual email costs time for everyone on the list, this is quite inconsiderate and should be avoided. Here are a few ways (but certainly not all ways) to avoid wasting others' time with too much email. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]
-
HOW EVERYTHING BE OUT
+
 
-
HOW UNIVERSE BE OUT
+
In general, if you find yourself sending more than one message in a row to *any* of the microformats lists, you are probably doing something wrong. Give others a chance to read/consider/reply to your messages one at a time. If you have a lot to say, you should instead be capturing your thoughts on the appropriate wiki page(s) per above guidelines, and simply referencing relevant URLs in *optional* notification messages to the list. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]
-
HOW MAKE THING BE OUT
+
 
-
HOW MAKE ANYTHING BE OUT
+
==== Avoid replying to yourself to reraise a topic ====
-
HOW MAKE EVERYTHING BE OUT
+
Especially avoid replying to yourself just to reraise a topic. Please avoid replying to yourself just to "ping" the mailing list or to ask for an update or advice. Especially avoid making assumptions / conclusions simply from the lack of a reply to you or your points. If you really think the issue is of merit, add it to the relevant [[issues]] page and just wait for it to be resolved. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>]
-
HOW MAKE UNIVERSE BE OUT
+
 
-
HOW THING OUT
+
==== Avoid wasting others time with simple contradictory email ====
-
HOW ANYTHING OUT
+
Similar to the [[how-to-play#avoid-simple-contradictions|how to play guideline to avoid simple contradictory responses]], please avoid replying to statements made in email with nothing more than simple contradictions. Simple contradictions (like just inverting another statement as if such an inversion was an argument), both do not add anything useful to a discussion, and worse, only add noise which wastes space and everyone's time, and are thus to be avoided. E.g.:
-
HOW EVERYTHING OUT
+
 
-
HOW UNIVERSE OUT
+
Original statement: "It's not really got much support of tools that support it and do something useful with it".
-
HOW MAKE THING OUT
+
 
-
HOW MAKE ANYTHING OUT
+
Simple contradiction: "There *is* support and there *are* tools, not least in the fields for which it was intended."
-
HOW MAKE EVERYTHING OUT
+
 
-
HOW MAKE UNIVERSE OUT
+
The contradiction example provided no new information that could argue against the original statement. It is no better than endless loops of "Yes it is.  No it isn't.  Yes it is.  No it isn't.".
-
HOW THING BE OUT
+
 
-
HOW ANYTHING BE OUT
+
Instead, provide at least a short sentence with a reason which provides information beyond what is provided, such as a specific piece of information and a URL.  E.g.
-
HOW EVERYTHING BE OUT
+
 
-
HOW UNIVERSE BE OUT
+
Better follow-up statement: "There are tools that support it, for example application XYZ, available at <nowiki>http://example.com/xyz</nowiki> ."
-
HOW MAKE THING BE OUT
+
 
-
HOW MAKE ANYTHING BE OUT
+
[<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>([http://microformats.org/discuss/mail/microformats-new/2008-February/001385.html 1])]
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
==== Avoid sending one message per issue raised ====
-
HOW THING OUT
+
If you add multiple issues to a microformats issues page, and wish to announce that you did so, please only send at most '''one''' email announcing the batch of issues you added and note the URL of the issue page on the wiki, rather than sending one email per issue. Direct people to the wiki to follow-up on your issues, rather that encouraging threads of conversation/discussion per issue on the email list.
-
HOW ANYTHING OUT
+
 
-
HOW EVERYTHING OUT
+
[<abbr title="guideline created due to one or more actions by Manu Sporny">src:M</abbr>([http://microformats.org/discuss/mail/microformats-new/2009-February/002026.html 1], [http://microformats.org/discuss/mail/microformats-new/2009-February/002031.html 2], [http://microformats.org/discuss/mail/microformats-new/2009-February/002030.html 3], [http://microformats.org/discuss/mail/microformats-new/2009-February/002029.html 4], [http://microformats.org/discuss/mail/microformats-new/2009-February/002028.html 5], [http://microformats.org/discuss/mail/microformats-new/2009-February/002027.html 6])]
-
HOW UNIVERSE OUT
+
 
-
HOW MAKE THING OUT
+
=== Avoid logical flaws ===
-
HOW MAKE ANYTHING OUT
+
See [[logical-flaws]] for a list of common logical flaws seen on the mailing-list(s) which are to be avoided. [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>([http://microformats.org/discuss/mail/microformats-discuss/2007-July/010269.html])]
-
HOW MAKE EVERYTHING OUT
+
 
-
HOW MAKE UNIVERSE OUT
+
==== Point out logical flaws ====
-
HOW THING BE OUT
+
When someone employs one or more known [[logical-flaws]] on the mailing-list(s), kindly point out the logical flaw(s), preferably with a link to the specific logical flaw(s). [<abbr title="guideline created due to one or more actions by Andy Mabbett">src:A</abbr>([http://microformats.org/discuss/mail/microformats-discuss/2007-July/010269.html])]
-
HOW ANYTHING BE OUT
+
 
-
HOW EVERYTHING BE OUT
+
==== Responding to rude emails ====
-
HOW UNIVERSE BE OUT
+
We need everyone's help to keep the community civil and friendly (see [[#Be_nice|be nice]] above, however, sometimes someone will say something rude on the email list. In such cases it is useful to have a set of pre-written responses to make it easier to deal with. See:
-
HOW MAKE THING BE OUT
+
* [[rude-email-responses]]
-
HOW MAKE ANYTHING BE OUT
+
 
-
HOW MAKE EVERYTHING BE OUT
+
== microformats-discuss ==
-
HOW MAKE UNIVERSE BE OUT
+
A mailing  list for general discussion of microformats, with a strong leaning towards:
-
HOW THING OUT
+
 
-
HOW ANYTHING OUT
+
* starting out with microformats
-
HOW EVERYTHING OUT
+
* real-world content authoring
-
HOW UNIVERSE OUT
+
 
-
HOW MAKE THING OUT
+
=== Good topics for discussion ===
-
HOW MAKE ANYTHING OUT
+
Here is a list (certainly not definitive) of good topics which are appropriate for the microformats-discuss mailing list:
-
HOW MAKE EVERYTHING OUT
+
 
-
HOW MAKE UNIVERSE OUT
+
* general thoughts on the design and use of semantic XHTML markup
-
HOW THING BE OUT
+
* how to use and write microformats in content
-
HOW ANYTHING BE OUT
+
* how to use microformat design patterns in content
-
HOW EVERYTHING BE OUT
+
 
-
HOW UNIVERSE BE OUT
+
=== Good topics that belong somewhere else ===
-
HOW MAKE THING BE OUT
+
* see [http://microformats.org/wiki/mailing-lists#good_topics_for_discussion_2 microformats-dev good topics for discussion]
-
HOW MAKE ANYTHING BE OUT
+
* see [http://microformats.org/wiki/mailing-lists#good_topics_for_discussion_3 microformats-new good topics for discussion]
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
=== Bad topics for discussion ===
-
HOW THING OUT
+
 
-
HOW ANYTHING OUT
+
AKA topics better discussed elsewhere (somewhere other than microformats.org).
-
HOW EVERYTHING OUT
+
 
-
HOW UNIVERSE OUT
+
Here is a list (also not definitive) of topics which are undesired and inappopriate for the microformats-discuss mailing list.  In fact, they're not even worth the time to bother discussing, so please do not bring them up on the microformats-discuss mailing list.  We'll add more topics as people come up with more off-topic or out-of-scope or rathole topics.
-
HOW MAKE THING OUT
+
 
-
HOW MAKE ANYTHING OUT
+
# '''How to make a "general purpose" (micro)format.'''  Go read [http://microformats.org/wiki/microformats#microformats_are_not what microformats are not], actually, go read the entire [[microformats|principles]] page.  Sometimes this may masquerade as a "format of formats".  Either way, it is one of those boil the ocean ratholes which are far outside the focus of microformats. If you really want to work on such subjects, teach yourself DTD (SGML, XML), XML Schema, Relax NG, RDF Schema, and find the communities working on those technologies.
-
HOW MAKE EVERYTHING OUT
+
# <span id="bad-topic-namespaces">'''Using namespaces and namespace prefixes.'''</span>  In short, namespaces are neither necessary (the Internet ran just fine without them for decades, go read some RFCs), nor desirable (prefixes make formats far uglier and more difficult to hand-code).  See also [[namespaces-considered-harmful]].
-
HOW MAKE UNIVERSE OUT
+
# '''Using non-English names for properties'''.  This was briefly discussed on the microformats-discuss list most recently as "Language Maps" but has been raised before that.  Some folks have raised the issue that microformats use English names for properties, and they would like alternate (non-English) names in other (natural) languages, and perhaps try to establish a mapping between them.  As microformats property names are based on existing standards (see [[process]], and [[naming-principles]]), this is another problem that is far outside the scope of microformats.  As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on.  Note that this is NOT about the internationalization (i18n) of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF).  This is purely about the names of the properties (and enumerated values) in the formats.
-
HOW THING BE OUT
+
 
-
HOW ANYTHING BE OUT
+
== microformats-dev ==
-
HOW EVERYTHING BE OUT
+
For discussion of microformats development, with a leaning towards:
-
HOW UNIVERSE BE OUT
+
 
-
HOW MAKE THING BE OUT
+
* anything that involves writing code
-
HOW MAKE ANYTHING BE OUT
+
* abstractions / models (in contrast to actual content)
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
=== Good topics for discussion ===
-
HOW THING OUT
+
These tend to be topics that belong in microformats-dev instead of microformats-discuss.  This list is also not definitive, but illustrates the general areas:
-
HOW ANYTHING OUT
+
 
-
HOW EVERYTHING OUT
+
* microformat parsing
-
HOW UNIVERSE OUT
+
* microformat "(auto)-discovery"
-
HOW MAKE THING OUT
+
* comparisons of microformats with other data abstractions or data representations (e.g. XML, RDF)
-
HOW MAKE ANYTHING OUT
+
* compatibility/interoperability of microformats with other data abstractions or data representations
-
HOW MAKE EVERYTHING OUT
+
 
-
HOW MAKE UNIVERSE OUT
+
Formerly, the membership to this list was moderated and limited to people who had demonstrated public implementations of microformats. We've since relaxed this requirement, yet maintain the same expectations that people involved in the discussion are focused on concrete and pragmatic topics related to writing code using microformats.
-
HOW THING BE OUT
+
 
-
HOW ANYTHING BE OUT
+
== microformats-rest ==
-
HOW EVERYTHING BE OUT
+
For discussion of use of microformats with [http://en.wikipedia.org/wiki/Representational_State_Transfer REST], in protocols, services, APIs etc.
-
HOW UNIVERSE BE OUT
+
 
-
HOW MAKE THING BE OUT
+
== microformats-new ==
-
HOW MAKE ANYTHING BE OUT
+
This list is for the discussion, exploration and development of new microformats. 
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
This list was created in February 2007 [http://microformats.org/blog/2007/02/08/new-mailing-list/] to reduce the new microformat development noise on the [http://microformats.org/wiki/mailing-lists#microformats-discuss microformats-discuss] list, and allow those that are interested in exploring new microformats to concentrate their efforts.
-
HOW THING OUT
+
 
-
HOW ANYTHING OUT
+
=== Specific posting guidelines ===
-
HOW EVERYTHING OUT
+
* Make sure you have read and fully understand the [[process]] and have already made your website [[POSH]] and have used existing microformats as much as you can.
-
HOW UNIVERSE OUT
+
* Make an effort to search the mailing list archives and the wiki to see if your suggestion has already been made, or is closely related to something in existance.  It may be more advisable to build on previous work.  See also [[rejected-formats]].
-
HOW MAKE THING OUT
+
* Be ready to show plenty of examples of what you're trying to achieve and what real problems you're trying to resolve in the first instance.  Suggested formats should expect a certain amount of interrogation about the aim of a new microformat - this shouldn't be taken as negative feedback, or taken personally!
-
HOW MAKE ANYTHING OUT
+
* Please make a note of any suggested new microformats that do not make it through the [[process]] on the [[rejected-formats]] wiki page, along with a link to the discussion and the suggested resolution.
-
HOW MAKE EVERYTHING OUT
+
 
-
HOW MAKE UNIVERSE OUT
+
=== Good topics for discussion ===
-
HOW THING BE OUT
+
* Discussion on how to re-use existing microformats for "new" uses.
-
HOW ANYTHING BE OUT
+
* Discussion on extension of existing microformats syntax
-
HOW EVERYTHING BE OUT
+
* Discussion of the [[process]]
-
HOW UNIVERSE BE OUT
+
* Development of brand new microformats, adhering to the [[process]]
-
HOW MAKE THING BE OUT
+
 
-
HOW MAKE ANYTHING BE OUT
+
=== Bad topics for discussion ===
-
HOW MAKE EVERYTHING BE OUT
+
All [[mailing-lists#Bad_topics_for_discussion|microformats-discuss bad topics for discussion]] are also bad topics for microformats-new as well.  In addition:
-
HOW MAKE UNIVERSE BE OUT
+
==== new microformat hXYZ ====
-
HOW THING OUT
+
* '''"proposal for a new microformat: hXYZ"''' - especially if as your first post.  '''Don't''' send a proposal email as your first email.  You're likely to not get very far.  In particular, it's also bad form to prematurely name a microformat hXYZ or whatever as well.  See [[process#Naming_considerations|Naming consideration]].  And re-read the [[process|entire process]].
-
HOW ANYTHING OUT
+
** '''email response template:''' when someone makes a "proposal for a new microformat: hXYZ", kindly reply with something like:
-
HOW EVERYTHING OUT
+
<pre><nowiki>
-
HOW UNIVERSE OUT
+
Please read:
-
HOW MAKE THING OUT
+
 
-
HOW MAKE ANYTHING OUT
+
http://microformats.org/wiki/process
-
HOW MAKE EVERYTHING OUT
+
 
-
HOW MAKE UNIVERSE OUT
+
before proposing any new microformats.
-
HOW THING BE OUT
+
 
-
HOW ANYTHING BE OUT
+
In addition, please read the specific posting guidelines for microformats-new:
-
HOW EVERYTHING BE OUT
+
 
-
HOW UNIVERSE BE OUT
+
http://microformats.org/wiki/mailing-lists#microformats-new
-
HOW MAKE THING BE OUT
+
</nowiki></pre>
-
HOW MAKE ANYTHING BE OUT
+
==== new microformat hPreviousFormatProposal ====
-
HOW MAKE EVERYTHING BE OUT
+
* '''"proposal for a new microformat: hPreviousFormatProposal"'''. This is a particular common variant of the previous bad topic for discussion.  Please do not propose a microformat simply based upon taking some PreviousFormatProposal (like some random XML or RDF format proposal) and turning it into class names. While re-using an existing format (or proposal, or portion thereof) for vocabulary for a microformat ''may'' be part of developing a microformat (see [[process]]), it is insufficient.
-
HOW MAKE UNIVERSE BE OUT
+
**  '''email response template:''' when someone makes a "proposal for a new microformat: hPreviousFormatProposal", in addition to the above email response template requesting that they read the [[process]] and list guidelines, kindly reply with something like:
-
HOW THING OUT
+
<pre><nowiki>
-
HOW ANYTHING OUT
+
Simply proposing a set of class names is not a microformat (again, see /wiki/process/) - at best it is a poshformat.
-
HOW EVERYTHING OUT
+
 
-
HOW UNIVERSE OUT
+
http://microformats.org/wiki/poshformat
-
HOW MAKE THING OUT
+
</nowiki></pre>
-
HOW MAKE ANYTHING OUT
+
 
-
HOW MAKE EVERYTHING OUT
+
== Unsure ==
-
HOW MAKE UNIVERSE OUT
+
If you are unsure about any of guidelines, or have any other list-specific issues, you are welcome to email the list admins, e.g. for microformat-discuss: email microformats-discuss-owner at microformats dot org.
-
HOW THING BE OUT
+
 
-
HOW ANYTHING BE OUT
+
== Help Redirect Topics ==
-
HOW EVERYTHING BE OUT
+
If you notice a topic being discussed in one list which would be more appropriate for another list (e.g. discussion of a developer topic like "parsing" in the microformats-discuss list), you can help encourage better list usage by redirecting the thread to the more appropriate list with a gentle reminder at the top, e.g.:
-
HOW UNIVERSE BE OUT
+
 
-
HOW MAKE THING BE OUT
+
<blockquote>
-
HOW MAKE ANYTHING BE OUT
+
<p>Please redirect discussions of "parsing" and other development related/centric topics to the microformats-dev list per:</p>
-
HOW MAKE EVERYTHING BE OUT
+
<p>http://microformats.org/wiki/mailing-lists#Bad_topics_for_discussion</p>
-
HOW MAKE UNIVERSE BE OUT
+
<p>http://microformats.org/wiki/mailing-lists#microformats-dev</p>
-
HOW THING OUT
+
</blockquote>
-
HOW ANYTHING OUT
+
 
-
HOW EVERYTHING OUT
+
== How to search the mailing list archives ==
-
HOW UNIVERSE OUT
+
If your post to the list starts off "I'm new to the list and microformats so I don't know if you've discussed this already" READ THROUGH THE [http://microformats.org/discuss/mail/microformats-discuss/ ARCHIVES]!
-
HOW MAKE THING OUT
+
 
-
HOW MAKE ANYTHING OUT
+
The archives are getting larger, so here are a few simple ways you can search them. Most popular search engines imploy some sort of site based results filtering. Google does this in your initial search. Type "site:http://microformats.org/discuss/ <search terms here>" to limit the search results to only our discussion list. This will help you from asking a question that has already been posted, debated, and possibly resolved. It saves everyone time and energy!
-
HOW MAKE EVERYTHING OUT
+
 
-
HOW MAKE UNIVERSE OUT
+
Gmane provides [http://news.gmane.org/gmane.comp.web.microformats.general an alternate search and interface] as well as [http://rss.gmane.org/gmane.comp.web.microformats.general RSS feed] for the microformats-discuss list.
-
HOW THING BE OUT
+
 
-
HOW ANYTHING BE OUT
+
== Historical ==
-
HOW EVERYTHING BE OUT
+
 
-
HOW UNIVERSE BE OUT
+
For the record, view our [[mailing-lists-proposals|proposals for a new mailing list]] for discussing the research and creation of new microformats (see "microformats-new" above) so that those discussions do not overwhelm microformats-discuss.
-
HOW MAKE THING BE OUT
+
 
-
HOW MAKE ANYTHING BE OUT
+
== Other ==
-
HOW MAKE EVERYTHING BE OUT
+
 
-
HOW MAKE UNIVERSE BE OUT
+
Items regarding the mailing lists that didn't fit anywhere else.
-
HOW THING OUT
+
* [[mailing-list-unmoderation]]
-
HOW ANYTHING OUT
+
 
-
HOW EVERYTHING OUT
+
==See also==
-
HOW UNIVERSE OUT
+
*[[discuss|Other discussion fora]]
-
HOW MAKE THING OUT
+
-
HOW MAKE ANYTHING OUT
+
-
HOW MAKE EVERYTHING OUT
+
-
HOW MAKE UNIVERSE OUT
+
-
HOW THING BE OUT
+
-
HOW ANYTHING BE OUT
+
-
HOW EVERYTHING BE OUT
+
-
HOW UNIVERSE BE OUT
+
-
HOW MAKE THING BE OUT
+
-
HOW MAKE ANYTHING BE OUT
+
-
HOW MAKE EVERYTHING BE OUT
+
-
HOW MAKE UNIVERSE BE OUT
+
-
HOW THING OUT
+
-
HOW ANYTHING OUT
+
-
HOW EVERYTHING OUT
+
-
HOW UNIVERSE OUT
+
-
HOW MAKE THING OUT
+
-
HOW MAKE ANYTHING OUT
+
-
HOW MAKE EVERYTHING OUT
+
-
HOW MAKE UNIVERSE OUT
+
-
HOW THING BE OUT
+
-
HOW ANYTHING BE OUT
+
-
HOW EVERYTHING BE OUT
+
-
HOW UNIVERSE BE OUT
+
-
HOW MAKE THING BE OUT
+
-
HOW MAKE ANYTHING BE OUT
+
-
HOW MAKE EVERYTHING BE OUT
+
-
HOW MAKE UNIVERSE BE OUT
+

Current revision


Contents

Redirect to IRC

If someone emails you directly, asking about microformats, or making a proposal, if you can answer *quickly* (like a one liner, like "use h-card to markup people and organizations"), then do so, but always redirect them to IRC for discussion. E.g. here's an email template you may use:

Email Template to IRC

Hi,

Thanks for your interest in microformats!

We're a community based organization, and thus I'd definitely prefer discussing this in our public forum:

irc://irc.freenode.net/microformats

If you need help with joining the #microformats forum on Freenode, see:

http://microformats.org/wiki/irc

There are community members from all around the world in the forum, which is also logged and read by many others even if offline. Go ahead and ask any questions you want to about microformats there, and someone will likely work with you to figure out the answers!

Thanks again, and see you on #microformats!

Warning: This page is in general out of date, see irc for discussions.

Historical Archive of Mailing List Info

Read the microformats discuss page first.

Then read the mailing list policies.

Then read the respective archives (-discuss, -dev, -new).

After that please see the following additional notes of scope and topics for each list.

Getting subscribed

To subscribe to any of the mailing lists discussed below, please see http://microformats.org/discuss/ - here you will find all relevant subscription links, archives and also access to lists you are already subscribed to where you may change the email address you are subscribed with and the level of emails you will receive (all or digest).

General guidelines

Here is a list of general guidelines to follow in microformats list discussions in general. The overall goal of many of these guidelines is to increase the signal to noise ratio on the lists by encouraging signal, and discouraging noise. Maximizing the signal-to-noise ratio (S/N) is essential to scaling a list membership, and thus as microformats grow in popularity, maximizing S/N becomes more and more important. If you have suggestions for general guidelines, please post them to the microformats-discuss list so that the list-admins may consider your suggestions.

Send plain text email only

The microformats mailing lists are configured to only accept plain text (text/plain) emails.

If you get an error message like:

The message's content type was not explicitly allowed

Change your email client to send text/plain.

For example, in Gmail, you have to go into Settings (under the gear icon menu in the top right), and at the bottom, choose:

Outgoing message encoding:
 (*) Use default text encoding for outgoing messages
 ( ) Use Unicode (UTF-8) encoding for outgoing messages

In addition, if you're using the recently "new" Gmail "Compose" feature, you may have to click the little drop-down arrow button menu to the bottom right of the compose text area, and make sure that

 [x] Plain text mode

is checked.

Be nice

The microformats.org community is quite different than both other standards organizations and most open source efforts in (at least) one very important way: this community is a much nicer place to be, with people in general treating each other with a lot of respect and benefit of the doubt.

This guideline, which may seem totally obvious, is made explicit because of a few bad examples.

This friendlier tone in the community is something that the community very much values and will fight to defend. The admins will take swift action to ban or moderate individuals who essentially are "jerks" on IRC or any of the lists.

If you see someone being rude, please ask them *privately* to not do so, and if necessary contact one or more of the admins, again privately (feel free to CC them on a single email) pointing out the behavior. Admins will likely respond to rude individuals publicly to make it clear their behavior is not acceptable.

Note: neutral tone emails that use simple logical/rational emotion-free language are perfectly fine. This guideline is not a request to add artificial kindness etc. to emails. Nor is it a discouragement to engage in constructively critical discourse.

Personal attacks are unacceptable and may be given a warning by an admin and then blocking upon any additional instance. See Wikipedia:No personal attacks:

Comment on content, not on the contributor. Personal attacks do not help make a point.

Personal Attacks (ad hominem, name-calling, etc.) on one or a set of individuals will be pointed out by the admins, and will likely only receive one warning. Upon a second such personal attack an admin will likely ban the attacking individual.

If you do make a mistake and make a personal attack, consider following-up with a public apology, as doing so demonstrates personal responsibility, good will, and a desire to improve the overall tone of conversations.

Why to avoid negative behaviors

Be patient

The community, as part of its broader positive tone, tries to be fairly patient with folks, and we want to continue to encourage that. The microformats lists will always (assuming continued growth and popularity) get new subscribers, and these new subscribers may be unfamiliar with the customs and conventions of the community. As an experienced member in the community, please be patient with new subscribers, and help them improve their behavior by kindly pointing out relevant guidelines and answers on the wiki. However, if it appears that a newcomer has a negative attitude, please raise it to the attention of the admins (offlist) with an official complaint email that references (by email archive URL) or includes the email that demonstrates the negative attitude. Negativity is the biggest exception - this community has very little patience for negativity (see previous Be nice guideline).

Use real world examples

People often invent completely fictitious (and theoretical) examples in response to (perhaps rhetorical) questions or to make a point they are trying to make. microformats themselves are based on studying real world examples and designing for real world examples. Thus arguments based on theoretical examples hold much less weight in microformats discussions. Please avoid posting arguments / questions based solely on theoretical examples. [src:A,o].

If a theoretical example seems compelling to you (perhaps others may have brought it up as well), instead of emailing about it, document it on the respective specific microformat's *-brainstorming wiki page, (preferably near the bottom), and explicitly labeled as a "*theoretical example*".

Ask for real world examples

If someone discusses or provides arguments based on theoretical examples, then:

Use URLs to examples

Please provide URLs to real world examples when possible. This helps to validate that such examples truly are "real world" as they are on the public Web, and provides additional context around the example which might be crucial to understanding it or answering questions about it. [src:A,o]

Ask for URLs to examples

When people do not provide a specific URL to a test case or example, then especially as a developer, PLEASE ask them to provide a specific URL (and cite the previous guideline) rather than attempting to work out how an inline snippet of code might work.

Use the wiki to share state instead of email

Use the wiki. Summary: Please add any substantial content to the wiki and use email only for referring to the URLs on the wiki accordingly. If you're not sure where to add something, ask in IRC or on the list.

In particular: when providing examples or (re-)raising/opening a discussion on IRC or the mailing lists, please provide a URL to the relevant wiki page which captured the example or state of the discussion previously.

If you can't find the relevant wiki page, ask for it (on IRC or on the microformats-discuss mailing list). If no one can find it, ask for help creating a wiki page for it. Then put-it-on-the-wiki. [src:A,o]

See wiki-better-than-email for some background and explanations of how and why the wiki works better than email for content in general (whether issues, brainstorms, etc.).

Read FAQs before asking questions

Especially read relevant/respective FAQs before asking questions. Before asking a question on a microformats list, read the relevant FAQs:

  1. Start with the general microformats faq
  2. Then read specific microformats FAQs, e.g. for rel-tag, see the rel-tag FAQ, for adr, see the hCard FAQ as the spec indicates, etc.

Cite URLs to answer questions

When answering questions on a list, cite URL(s) to FAQ answers. Despite the previous guidelines, experience has shown us that there will be time that smart, considerate individuals may attempt to look for an answer on the FAQ, and not find it despite it being there. In such cases, assume that it was a simple unintended oversight (rather than laziness or failure to check the FAQ), and when answering such a question on a microformats list:

  1. Please check the relevant FAQs first, and if the answer is not there, document the question and your answer there. I.e. put-it-on-the-wiki. This is so that the community memory of answers (especially the most recent and accurate state of answers) is kept and grown in a semi-organized and hopefully easily findable fashion on the wiki, rather than deep in the depths of email archives which are often much more difficult to search, and difficult to tell what answer is "the" most recent, relevant and accurate answer.
  2. Cite URL(s) FAQ answer(s) (that you may have just written) rather than just writing an answer, when composing your reply in email. This will hopefully encourage more reading of the wiki and thus learning of answers to microformats related questions in general.

Note: when citing URLs, make sure they answer the specific question being asked. For additional advice about providing good "RTFM" messages see JimboJW's blog post: Irresponsible use of RTFM doesn't help anyone.

Raise issues on the wiki not in email

If you find an issue with a microformat, please first read the respective faq and issues pages for that microformat before raising the issue. If the issue is already documented on the wiki, please add any new comments there (do not simply repeat statements that others have made, nor repeat your own statements). [src:A]

When someone does raise issues via email, kindly request that they raise issues via the wiki instead, e.g.:

Please capture specific issues regarding a specific microformats on the respective *-issues wiki page rather than email.

If there is a specific issue that applies to several microformats (e.g. class microformats) add it to:

http://microformats.org/wiki/issues

Point out reraised issues and redirect follow up to the wiki

When someone does (re-)raise an issue via email that is already on the wiki, rather than arguing the issue in email, point out that the issue is already documented on the wiki (preferably with a URL to the issue, add a fragment identifier if necessary), and ask them to follow-up on the wiki, e.g.:

Note that this is an already documented issue:

http://microformats.org/wiki/issues#specific-issue-fragment

Please add any follow-up there rather than in email.

Thanks,

This will hopefully end the thread and thus avoid further email on a topic that is already documented on the wiki.

Reply to email followups to issues with request to use wiki instead

When someone debates/follows-up to an issue via email (rather than doing the above and requesting that the issue be documented in email), request to the person following-up to please add their follow-up to the wiki instead (even if that means also adding the original issue), e.g.:

Please follow-up to issues raised in email by directing folks to raise issues on the respective *-issues wiki page rather than following-up to issues in email.

Thanks,

Avoid wasting others time by sending a lot of email

Historically a few individuals have overloaded some of the microformats mailing lists with a lot of email. As each individual email costs time for everyone on the list, this is quite inconsiderate and should be avoided. Here are a few ways (but certainly not all ways) to avoid wasting others' time with too much email. [src:A]

In general, if you find yourself sending more than one message in a row to *any* of the microformats lists, you are probably doing something wrong. Give others a chance to read/consider/reply to your messages one at a time. If you have a lot to say, you should instead be capturing your thoughts on the appropriate wiki page(s) per above guidelines, and simply referencing relevant URLs in *optional* notification messages to the list. [src:A]

Avoid replying to yourself to reraise a topic

Especially avoid replying to yourself just to reraise a topic. Please avoid replying to yourself just to "ping" the mailing list or to ask for an update or advice. Especially avoid making assumptions / conclusions simply from the lack of a reply to you or your points. If you really think the issue is of merit, add it to the relevant issues page and just wait for it to be resolved. [src:A]

Avoid wasting others time with simple contradictory email

Similar to the how to play guideline to avoid simple contradictory responses, please avoid replying to statements made in email with nothing more than simple contradictions. Simple contradictions (like just inverting another statement as if such an inversion was an argument), both do not add anything useful to a discussion, and worse, only add noise which wastes space and everyone's time, and are thus to be avoided. E.g.:

Original statement: "It's not really got much support of tools that support it and do something useful with it".

Simple contradiction: "There *is* support and there *are* tools, not least in the fields for which it was intended."

The contradiction example provided no new information that could argue against the original statement. It is no better than endless loops of "Yes it is. No it isn't. Yes it is. No it isn't.".

Instead, provide at least a short sentence with a reason which provides information beyond what is provided, such as a specific piece of information and a URL. E.g.

Better follow-up statement: "There are tools that support it, for example application XYZ, available at http://example.com/xyz ."

[src:A(1)]

Avoid sending one message per issue raised

If you add multiple issues to a microformats issues page, and wish to announce that you did so, please only send at most one email announcing the batch of issues you added and note the URL of the issue page on the wiki, rather than sending one email per issue. Direct people to the wiki to follow-up on your issues, rather that encouraging threads of conversation/discussion per issue on the email list.

[src:M(1, 2, 3, 4, 5, 6)]

Avoid logical flaws

See logical-flaws for a list of common logical flaws seen on the mailing-list(s) which are to be avoided. [src:A([1])]

Point out logical flaws

When someone employs one or more known logical-flaws on the mailing-list(s), kindly point out the logical flaw(s), preferably with a link to the specific logical flaw(s). [src:A([2])]

Responding to rude emails

We need everyone's help to keep the community civil and friendly (see be nice above, however, sometimes someone will say something rude on the email list. In such cases it is useful to have a set of pre-written responses to make it easier to deal with. See:

microformats-discuss

A mailing list for general discussion of microformats, with a strong leaning towards:

Good topics for discussion

Here is a list (certainly not definitive) of good topics which are appropriate for the microformats-discuss mailing list:

Good topics that belong somewhere else

Bad topics for discussion

AKA topics better discussed elsewhere (somewhere other than microformats.org).

Here is a list (also not definitive) of topics which are undesired and inappopriate for the microformats-discuss mailing list. In fact, they're not even worth the time to bother discussing, so please do not bring them up on the microformats-discuss mailing list. We'll add more topics as people come up with more off-topic or out-of-scope or rathole topics.

  1. How to make a "general purpose" (micro)format. Go read what microformats are not, actually, go read the entire principles page. Sometimes this may masquerade as a "format of formats". Either way, it is one of those boil the ocean ratholes which are far outside the focus of microformats. If you really want to work on such subjects, teach yourself DTD (SGML, XML), XML Schema, Relax NG, RDF Schema, and find the communities working on those technologies.
  2. Using namespaces and namespace prefixes. In short, namespaces are neither necessary (the Internet ran just fine without them for decades, go read some RFCs), nor desirable (prefixes make formats far uglier and more difficult to hand-code). See also namespaces-considered-harmful.
  3. Using non-English names for properties. This was briefly discussed on the microformats-discuss list most recently as "Language Maps" but has been raised before that. Some folks have raised the issue that microformats use English names for properties, and they would like alternate (non-English) names in other (natural) languages, and perhaps try to establish a mapping between them. As microformats property names are based on existing standards (see process, and naming-principles), this is another problem that is far outside the scope of microformats. As Ryan King put it, this is a pre-existing (unsolved) "problem" with English-based HTML, the English-based CSS, the English-based HTTP and so on. Note that this is NOT about the internationalization (i18n) of the content and data itself - which is of course an excellent goal, advocated and promoted by microformats and the standards they are based on (e.g. W3C, IETF). This is purely about the names of the properties (and enumerated values) in the formats.

microformats-dev

For discussion of microformats development, with a leaning towards:

Good topics for discussion

These tend to be topics that belong in microformats-dev instead of microformats-discuss. This list is also not definitive, but illustrates the general areas:

Formerly, the membership to this list was moderated and limited to people who had demonstrated public implementations of microformats. We've since relaxed this requirement, yet maintain the same expectations that people involved in the discussion are focused on concrete and pragmatic topics related to writing code using microformats.

microformats-rest

For discussion of use of microformats with REST, in protocols, services, APIs etc.

microformats-new

This list is for the discussion, exploration and development of new microformats.

This list was created in February 2007 [3] to reduce the new microformat development noise on the microformats-discuss list, and allow those that are interested in exploring new microformats to concentrate their efforts.

Specific posting guidelines

Good topics for discussion

Bad topics for discussion

All microformats-discuss bad topics for discussion are also bad topics for microformats-new as well. In addition:

new microformat hXYZ

Please read:

http://microformats.org/wiki/process

before proposing any new microformats.

In addition, please read the specific posting guidelines for microformats-new:

http://microformats.org/wiki/mailing-lists#microformats-new

new microformat hPreviousFormatProposal

Simply proposing a set of class names is not a microformat (again, see /wiki/process/) - at best it is a poshformat.

http://microformats.org/wiki/poshformat

Unsure

If you are unsure about any of guidelines, or have any other list-specific issues, you are welcome to email the list admins, e.g. for microformat-discuss: email microformats-discuss-owner at microformats dot org.

Help Redirect Topics

If you notice a topic being discussed in one list which would be more appropriate for another list (e.g. discussion of a developer topic like "parsing" in the microformats-discuss list), you can help encourage better list usage by redirecting the thread to the more appropriate list with a gentle reminder at the top, e.g.:

Please redirect discussions of "parsing" and other development related/centric topics to the microformats-dev list per:

http://microformats.org/wiki/mailing-lists#Bad_topics_for_discussion

http://microformats.org/wiki/mailing-lists#microformats-dev

How to search the mailing list archives

If your post to the list starts off "I'm new to the list and microformats so I don't know if you've discussed this already" READ THROUGH THE ARCHIVES!

The archives are getting larger, so here are a few simple ways you can search them. Most popular search engines imploy some sort of site based results filtering. Google does this in your initial search. Type "site:http://microformats.org/discuss/ <search terms here>" to limit the search results to only our discussion list. This will help you from asking a question that has already been posted, debated, and possibly resolved. It saves everyone time and energy!

Gmane provides an alternate search and interface as well as RSS feed for the microformats-discuss list.

Historical

For the record, view our proposals for a new mailing list for discussing the research and creation of new microformats (see "microformats-new" above) so that those discussions do not overwhelm microformats-discuss.

Other

Items regarding the mailing lists that didn't fit anywhere else.

See also

Mailing Lists was last modified: Friday, June 10th, 2016

Views