brainstorming

*-brainstorming pages are a part of the process for developing a new microformat.

Types of Brainstorming

In the course of following the microformats process, one of the steps is to create a brainstorming page associated with the general type of content that is being explored, e.g. citation-brainstorming, media-info-brainstorming.

After a microformat has been drafted and reasonably well established, there are often desires/proposals to add features to it, or suggestions of usage, or even clarifications which go beyond mere errata. In such cases, brainstorming pages are created for the specific microformats, e.g. hcard-brainstorming, hcalendar-brainstorming. With sufficient publisher/implementer experience, items from those brainstorming pages may be incorporated into the specifications themselves.

Burden of Proof

By default it is assumed that the benefit of such proposals/suggestions/clarifications to existing microformats is unknown, and have potentially prohibitive costs, until proven otherwise (that they *have* a benefit, and that the costs are cheap).

The burden of proof is on such proposals/suggestions/clarifications to demonstrate that those changes would :

• Bring real world benefits using real world examples. It is expected that the proposer provide such examples, or at least admit that their proposal is hypothetical, and explicitly ask the community for help in finding such examples.
• Be easily implementable. Since only a small fraction of the participants in the microformats community are actual developers with sufficient time and resources to implement code that produces/parses microformats, it is expected that the microformats development community may be requested to help evaluate the implementability of any particular suggestion.

See also Wikipedia: Burden of proof: Science and other uses.

Interoperability

In addition, it is desirable to also demonstrate that any such changes would have some reasonable level of interoperability (perhaps even improving interoperability). While certainly one could construct entire test suites based on real world examples to help demonstrate high levels of interoperability (and it is of course desirable to eventually do so, as the community has been with both hCard and hCalendar test cases), even just a few real world examples (perhaps from different sites) that worked with more than one implementation (perhaps from different authors/organizations) helps provide support for making the suggested change.

see also

• examples
• formats
• principles
• process