Brainstorming

(Difference between revisions)

Jump to: navigation, search
m (add TOC)
Current revision (21:23, 3 October 2012) (view source)
m (minor updates)
 
(One intermediate revision not shown.)
Line 1: Line 1:
-
<h1>Brainstorming</h1>
+
<entry-title>Brainstorming</entry-title>
-
__TOC__
+
'''*-brainstorming''' pages are a part of the [[process]] for developing a new microformat.
== Types of Brainstorming ==
== Types of Brainstorming ==
Line 16: Line 16:
* 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.
* 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.
* 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 [http://en.wikipedia.org/wiki/Burden_of_proof#Science_and_other_uses Wikipedia: Burden of proof: Science and other uses].
=== Interoperability ===
=== 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|hCard]] and [[hcalendar|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.
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|hCard]] and [[hcalendar|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]]

Current revision


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

Contents

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 :

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

Brainstorming was last modified: Wednesday, October 3rd, 2012

Views