brainstorming - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:21:06Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:21, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~Brainstorming~~</entry-title>~~		{{DISPLAYTITLE:Brainstorming}}

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

Tantek: minor updates

2012-10-03T21:23:59Z

minor updates

← Older revision		Revision as of 21:23, 3 October 2012
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 22:		Line 22:

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

Tantek: added wikipedia burden of proof - science reference

2007-05-13T20:28:58Z

added wikipedia burden of proof - science reference

← Older revision		Revision as of 20:28, 13 May 2007
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.

Tantek: add TOC

2007-04-27T16:01:31Z

add TOC

← Older revision		Revision as of 16:01, 27 April 2007
Line 1:		Line 1:
	<h1>Brainstorming</h1>		<h1>Brainstorming</h1>

			__TOC__

	== Types of Brainstorming ==		== Types of Brainstorming ==

AndyMabbett: /* Burden of Proof */ presumed meaning (99/1000 is a fraction)

2007-03-25T22:11:50Z

Burden of Proof: presumed meaning (99/1000 is a fraction)

← Older revision		Revision as of 22:11, 25 March 2007
Line 13:		Line 13:
	The burden of proof is on such proposals/suggestions/clarifications to demonstrate that those changes would :		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.		* 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 a 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.

	=== 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.

Tantek: drafted based on some email dialog and clarifications.

2007-03-25T20:31:25Z

drafted based on some email dialog and clarifications.

New page

<h1>Brainstorming</h1>

== 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 a 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.

=== 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.