process-brainstorming - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:31:14Z

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

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

	I'm using this page to collect brainstorms on additions to the [[process]] for discussion and feedback before incorporation. -- [[User:Tantek\|Tantek]]		I'm using this page to collect brainstorms on additions to the [[process]] for discussion and feedback before incorporation. -- [[User:Tantek\|Tantek]]

Tantek: added related issues/questions section - when does it make sense to demote drafts etc.?

2011-03-03T02:03:47Z

added related issues/questions section - when does it make sense to demote drafts etc.?

← Older revision		Revision as of 02:03, 3 March 2011
Line 104:		Line 104:
	**** write up remaining missing test cases for a full property (not necessarily value) coverage test suite		**** write up remaining missing test cases for a full property (not necessarily value) coverage test suite
	**** drop insufficiently supported properties (e.g. "class", "key")		**** drop insufficiently supported properties (e.g. "class", "key")

			=== related issues questions regarding document stages ===

			<div class="discussion">
			* '''if/when does it make sense to demote a microformat spec to a lower level?'''
			** '''can a standard be undone?''' we haven't seen any examples of this, but it is certainly possible that a sufficient implementations/publishers of a ''standard'' could disappear until it no longer meets requirements, should (and when should) it be demoted to just a ''specification'' or perhaps even a ''draft''?
			** '''from spec back to draft''' it's possible that implementations or publishers may disappear, and thus what used to qualify as a ''specification'' no longer meets the requirements, when should it be demoted explicitly back to a ''draft''?
			** '''undrafts''' e.g. there are plenty of drafts that never got any traction, should we have another category for "uninteresting-draft" that means no one other than the editor(s)/author(s) really cared for it, and thus it isn't a priority for the community. maybe we could call these "undrafts" - where drafts go when they don't make it to spec after some amount of time. From there it's probably best to simply use them for more brainstorming, and not encumber any future microformat effort with their legacy. This is likely important to keep the list of drafts as accurate/recent, and will also likely be challenging case-by-case judgment calls.
			</div>

	== see also ==		== see also ==

Tantek: /* draft spec standard */ more g

2011-02-11T19:16:52Z

draft spec standard: more g

← Older revision		Revision as of 19:16, 11 February 2011
Line 56:		Line 56:
	*** 1+ solid real world publisher(s) that		*** 1+ solid real world publisher(s) that
	**** are not the editor(s) of the spec (demonstrates some breadth of interest)		**** are not the editor(s) of the spec (demonstrates some breadth of interest)
	**** ~~benefits~~ end users (i.e. not just artificial data published for data's sake)		**** benefit end users (i.e. not just artificial data published for data's sake)
	*** 1+ solid real world consumer(s) that		*** 1+ solid real world consumer(s) that
	**** are not the editor(s) of the spec (demonstrates some breadth of interest)		**** are not the editor(s) of the spec (demonstrates some breadth of interest)
	**** successfully ~~consumes~~ the microformats published by the publisher(s).		**** successfully consume the microformats published by the publisher(s).
	**** ~~provides~~ real world end user benefits / ~~solves~~ use-cases		**** provide real world end user benefits / solve use-cases
	**** (libraries/opensource are nice as enablers but insufficient for this)		**** (libraries/opensource are nice as enablers but insufficient for this)
	** '''actions:'''		** '''actions:'''

Tantek: /* draft spec standard */ grammar

2011-02-11T19:15:26Z

draft spec standard: grammar

← Older revision		Revision as of 19:15, 11 February 2011
Line 55:		Line 55:
	* all outstanding -issues resolved (hit zero issues for a few weeks)		* all outstanding -issues resolved (hit zero issues for a few weeks)
	*** 1+ solid real world publisher(s) that		*** 1+ solid real world publisher(s) that
	**** ~~beyond~~ the editor(s) of the spec (demonstrates some breadth of interest)		**** are not the editor(s) of the spec (demonstrates some breadth of interest)
	**** benefits end users (i.e. not just artificial data published for data's sake)		**** benefits end users (i.e. not just artificial data published for data's sake)
	*** 1+ solid real world consumer(s) that		*** 1+ solid real world consumer(s) that
	**** ~~beyond~~ the editor(s) of the spec (demonstrates some breadth of interest)		**** are not the editor(s) of the spec (demonstrates some breadth of interest)
	**** successfully consumes the microformats published by the publisher(s).		**** successfully consumes the microformats published by the publisher(s).
	**** provides real world end user benefits / solves use-cases		**** provides real world end user benefits / solves use-cases

Tantek: /* draft spec standard */ make more JSON-like per feedback from Chris Messina at ActivityStreams meetup, simplified/shortened descriptions

2011-02-11T18:46:48Z

draft spec standard: make more JSON-like per feedback from Chris Messina at ActivityStreams meetup, simplified/shortened descriptions

← Older revision		Revision as of 18:46, 11 February 2011
Line 37:		Line 37:

	Specific brainstorm definitions:		Specific brainstorm definitions:
	* '''draft'''		* '''draft''' - experimental new microformat
	** ~~precondition~~: consensus has been reached among the various *-brainstorming proposals~~, sufficient to~~ write-up into a stand-alone draft.		** '''preconditions:'''
	** means: ready for publishers to start experimenting with on their public pages~~, and providing feedback for draft iteration accordingly~~		*** consensus has been reached among the various *-brainstorming proposals
	** ~~means:~~ ready for consumers to start experimenting with consuming such publishers, and providing feedback for draft iteration accordingly		** '''actions:'''
	** stability: major changes can still occur~~, including adding~~/~~dropping~~/~~renaming~~ arbitrary features (~~based on~~ research ~~and publisher~~/~~consumer implementation~~ feedback)		* determine a name for the new microformat ()
	* '''specification''' - a draft ~~that is mature/stable as determined by~~:		*** write-up consensus brainstorm into a stand-alone draft
	** ~~precondition:~~ all outstanding *-issues resolved (~~bounced off~~ zero issues~~, and perhaps stayed there~~ for a few weeks)		* create -issues page for collecting feedback
	** ~~precondition:~~ 1+ solid real world publisher(s) that		** '''means:'''
	*** ~~benefit~~ end users (i.e. not just ~~fictional/~~artificial data published for data's sake)		*** ready for publishers to start experimenting with on their public pages
	*** ~~not~~ the~~/an~~ editor of the spec (demonstrates some breadth of interest)		*** ready for consumers to start experimenting with consuming such publishers
	** precondition: 1+ solid real world consumer(s) that		*** and both providing feedback for draft iteration accordingly
	*** successfully consumes the microformats published by the ~~aforementioned~~ publisher(s).		** '''stability:'''
	*** provides real world end user benefits / use-cases (libraries/opensource are nice as enablers but insufficient for this)		*** major changes can still occur
	*** ~~not the/an editor of the spec (demonstrates some breadth of interest)~~		*** e.g. add/drop/rename arbitrary features (per research/feedback from publishers/consumers)
	** means: ready for publishers to start depending on		* '''specification''' - a stable and mature draft
	** ~~means:~~ ready for consumers to start depending on		** '''preconditions:'''
	** stability: minor changes can still occur based on real-world publisher/consumer ~~implementation~~ experience~~, up to~~ and ~~including dropping of~~ properties ~~and values (especially in order~~ to ~~reach "~~standard~~" stage~~ - ~~see below~~)		* all outstanding -issues resolved (hit zero issues for a few weeks)
	** ~~test cases~~: [[hReview]] and [[hAtom]] ~~are ready to~~ become "specifications" with a bit of work:		*** 1+ solid real world publisher(s) that
	*** resolve ~~outstanding~~ issues ~~and~~ incorporate into spec updates (0.4, 0.2 respectively)		**** beyond the editor(s) of the spec (demonstrates some breadth of interest)
	*** ~~use existing~~ -examples-in-wild ~~and~~ -implementations pages ~~as supporting evidence for~~ publisher(s)/consumer(s) ~~requirement~~		**** benefits end users (i.e. not just artificial data published for data's sake)
	* '''standard''' - ~~only~~ market proven ~~specifications are standards for practical purposes, thus this is determined by~~:		*** 1+ solid real world consumer(s) that
	** ~~precondition:~~ test suite with ~~at least one~~ test per feature (property~~/value~~) (should be easy)		**** beyond the editor(s) of the spec (demonstrates some breadth of interest)
	** ~~precondition:~~ 2+ solid real world publishers as defined above for "specification"		**** successfully consumes the microformats published by the publisher(s).
	** ~~precondition:~~ 2+ solid real world consumers as defined above for "specification" ~~and with additional requirements~~ that:		**** provides real world end user benefits / solves use-cases
	*** pass the test suite tests		**** (libraries/opensource are nice as enablers but insufficient for this)
	*** interoperably consume ~~the~~ microformats published by the ~~aforementioned~~ publishers.		** '''actions:'''
	** ~~precondition:~~ each property is published by 2+ of those publishers		*** update draft to use specification template
	** ~~precondition:~~ each property is consumed by 2+ of those consumers		* create -examples-in-wild, **-implementations pages to collect them
	** ~~thus properties that are published by <2 publishers or consumed by <2 consumers block advancement from specification to standard. The options to progress to standard are~~:		** '''means:'''
	*** ~~drop such under-supported property(ies) - insufficient market support~~ to ~~keep them~~. ~~Thus properties which fail in the real world should be and get dropped. This also supports the simplify [[principle]]. Such features may be reconsidered for future versions~~ if ~~more sufficient publishers/consumers adopt them.~~		*** ready for publishers to start depending on
	*** or wait for more additional publisher(s)/consumer(s) to support them. a bit up to the editor'~~s preference.~~		*** ready for consumers to start depending on
	** ~~means:~~ the market is interoperably publishing and consuming this microformat		** '''stability:'''
	** ~~means~~: ~~at this point bump the version # to 1.0 (if it isn~~'~~t there already)~~		*** minor changes can still occur
	** ~~stability:~~ the microformat is considered stable~~, and only~~ minor errata ~~are~~ expected ~~in response to~~ real world publishing/consuming ~~implementation~~ experience		*** e.g. dropping of properties and values (e.g. to reach "standard" - see below)
	** ~~test cases~~: [[hCard]] and [[hCalendar]] ~~are ready to~~ become "standards" with a bit of work:		*** iteration based on real-world publisher/consumer experience
	*** incorporate resolved issues into 1.0.1 releases (use 1.0.1 due to how long we left them a 1.0)		** '''actions:'''
	*** write up remaining missing test cases for a full property (not necessarily value) coverage test suite		*** encourage widespread adoption by all publishers and consumers
	*** drop insufficiently supported properties (e.g. "class", "key")		*** evaluate properties published by <2 publishers
			*** evaluate properties consumed by <2 consumers
			**** such properties block advancement from specification to standard.
			**** drop such under-supported property(ies) - insufficient market support to keep them. properties which fail in the real world should be and get dropped (per the simplify [[principle]]). features may be reconsidered for future versions.
			**** or wait for more additional publisher(s)/consumer(s) to support them. up to editor's preference.
			** '''example microformats to advance:'''
			*** [[hReview]] and [[hAtom]] can become "specifications" with a bit of work:
			**** resolve issues, incorporate into spec updates (0.4, 0.2 respectively)
			**** -examples-in-wild -implementations pages show publisher(s)/consumer(s) support
			* '''standard''' - market proven microformat
			** '''preconditions:'''
			*** test suite with 1+ test per feature (e.g. property) (should be easy)
			*** 2+ solid real world publishers as defined above for "specification"
			*** 2+ solid real world consumers as defined above for "specification" that:
			**** pass the test suite tests
			**** interoperably consume microformats published by the publishers.
			*** each property is published by 2+ of those publishers
			*** each property is consumed by 2+ of those consumers
			** '''actions:'''
			*** bump the version # to 1.0 (if it isn't there already)
			** '''means:'''
			*** the market is interoperably publishing and consuming this microformat
			** '''stability:'''
			*** the microformat is considered stable
			*** minor errata expected per real world publishing/consuming experience
			** '''example microformats to advance:'''
			*** [[hCard]] and [[hCalendar]] can become "standards" with a bit of work:
			**** incorporate resolved issues into 1.0.1 releases (use 1.0.1 due to how long we left them a 1.0)
			**** write up remaining missing test cases for a full property (not necessarily value) coverage test suite
			**** drop insufficiently supported properties (e.g. "class", "key")

	== see also ==		== see also ==

Tantek: moving metaprocess thinking to process-principles where it belongs, add draft spec standard proposal from events/2011-02-01-microformats-dinner

2011-02-11T02:11:48Z

moving metaprocess thinking to process-principles where it belongs, add draft spec standard proposal from events/2011-02-01-microformats-dinner

Show changes

Tantek: entry-title, see also

2011-02-10T00:34:16Z

entry-title, see also

← Older revision		Revision as of 00:34, 10 February 2011
Line 1:		Line 1:
	<h1>process brainstorming</h1>		<entry-title>process brainstorming</entry-title>

	A lot of thought and experience went into designing the microformats [[process]], and somewhere I want to capture that background. However, this page is not for that purpose, but rather to collect brainstorms and ideas on improving the process, along with some methodologies (or patterns) for considering changes to the process.		A lot of thought and experience went into designing the microformats [[process]], and somewhere I want to capture that background. However, this page is not for that purpose, but rather to collect brainstorms and ideas on improving the process, along with some methodologies (or patterns) for considering changes to the process.
Line 32:		Line 32:

	(Should this have been a blog post instead?)		(Should this have been a blog post instead?)

			== see also ==
			* [[process]]
			* [[process-faq]]
			* [[process-issues]]

Tantek: /* Prevent the negatives */ typo

2011-02-09T17:19:11Z

Prevent the negatives: typo

← Older revision		Revision as of 17:19, 9 February 2011
Line 17:		Line 17:
	What's wrong with focusing on preventing the negatives?		What's wrong with focusing on preventing the negatives?

	Because rarely is that the actual goal of any organization or effort. Most efforts have a specific constructive goal in mind and that goal is more important than the prevention of any negative. While that may be easy to understand, the habit of preventing the negative is do deeply ingrained that people often act to prevent the negative to such a great extent that they prevent the actual goal(s) of the effort(s) as well, and thus end up thinking and acting against their own interests.		Because rarely is that the actual goal of any organization or effort. Most efforts have a specific constructive goal in mind and that goal is more important than the prevention of any negative. While that may be easy to understand, the habit of preventing the negative is so deeply ingrained that people often act to prevent the negative to such a great extent that they prevent the actual goal(s) of the effort(s) as well, and thus end up thinking and acting against their own interests.

	What is the alternative to preventing the negatives?		What is the alternative to preventing the negatives?

Tantek: first draft and thoughts on prevent the negative vs. enable the positive

2006-08-02T00:45:35Z

first draft and thoughts on prevent the negative vs. enable the positive

New page

<h1>process brainstorming</h1>

A lot of thought and experience went into designing the microformats [[process]], and somewhere I want to capture that background. However, this page is not for that purpose, but rather to collect brainstorms and ideas on improving the process, along with some methodologies (or patterns) for considering changes to the process.

by [http://tantek.com/ Tantek], 20060801T1745-0700.

== Questioning Assumptions ==

Much of what [[microformats]] has achieved can be directly attributed to various assumptions made by other organizations, groups, experts that have been questioned about technology, markup, adoption, XML, XHTML etc.

There are other kinds of assumptions being questioned as well however, even assumptions that most don't even realize they are making due to habits and ways of thinking learned years ago. Not to mention established cultural behaviors in various communities.

=== Prevent the negatives ===

One assumption that pervades A LOT of process-think (bureaucracy if you will) is that it is of utmost importance (unquestioned even) to prevent negatives from occuring. I'm using "negative" here as a shorthand for "negative actions", "negative outcomes", "negative effects" etc. If you read any contracts for example, you'll see an incredible focus and obsession about preventing the negatives. Most processes build up rules to follow to prevent a negative that occured that recently occured. Problem happens. Not covered by the process. Rules added to the process to prevent the problem. One might even assert that most governments and bodies of law are grown this way.

What's wrong with focusing on preventing the negatives?

Because rarely is that the *actual* goal of any organization or effort. Most efforts have a specific *constructive* goal in mind and *that* goal is more important than the prevention of any negative. While that may be easy to understand, the habit of preventing the negative is do deeply ingrained that people often act to prevent the negative to such a great extent that they prevent the *actual* goal(s) of the effort(s) as well, and thus end up thinking and acting against their own interests.

What is the alternative to preventing the negatives?

One alternative might be the actual goal of the organization or effort, as explained above. But that doesn't work. Or rather, it doesn't work in a universal enough way in order to actually combat the deeply seated prevent the negative assumption. When that goal or effort is completed, it is far too easy to simply fall back on old habits.

The key alternative to prevent the negatives is the inversion of the entire statement.

== Enable the positives ==

One of the key realizations that I (and lots of other people have) had when first seeing and subsequently interacted with Wikipedia was how the nature of the medium and the culture and the community built around it enabled a constant stream of small positive steps to construct something incredible. I'm not sure that aspect was overtly designed into the system (and the culture around it), or if it was a happy accident or if it evolved. Regardless, we can use that aspect as a design center, especially in something like microformats which also depends on the incremental positive contributions of lots of people.

Thus when someone does something which appears to cause a negative, rather than first think, how do we prevent that, we should consider, how can we redirect/shape the *initiative*, *energy*, and *interest* of that person and *enable* such contributions to be positive, rather than focusing on preventing such actions. In the long term, I think this kind of philosophical shift will be absolutely essential for scaling both the growth and productivity of the community.

(Should this have been a blog post instead?)