process-issues - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:31:15Z

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

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

	These are issues that have been raised about the microformats [[process]] with broadly varying degrees of merit. Thus some issues are <span style="text-transform:uppercase">rejected</span> for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be <span style="text-transform:uppercase">accepted</span> and perhaps cause changes or improved explanations in the spec.		These are issues that have been raised about the microformats [[process]] with broadly varying degrees of merit. Thus some issues are <span style="text-transform:uppercase">rejected</span> for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be <span style="text-transform:uppercase">accepted</span> and perhaps cause changes or improved explanations in the spec.

Tantek: entry-title

2011-02-12T21:09:43Z

entry-title

← Older revision		Revision as of 21:09, 12 February 2011
Line 1:		Line 1:
	<h1>process issues</h1>		<entry-title>process issues</entry-title>

	These are issues that have been raised about the microformats [[process]] with broadly varying degrees of merit. Thus some issues are <span style="text-transform:uppercase">rejected</span> for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be <span style="text-transform:uppercase">accepted</span> and perhaps cause changes or improved explanations in the spec.		These are issues that have been raised about the microformats [[process]] with broadly varying degrees of merit. Thus some issues are <span style="text-transform:uppercase">rejected</span> for a number of obvious reasons (but still documented here in case they are re-raised), and others contain longer discussions. Some issues may be <span style="text-transform:uppercase">accepted</span> and perhaps cause changes or improved explanations in the spec.

Tantek: resolve all outstanding issues

2011-02-12T21:08:39Z

resolve all outstanding issues

← Older revision		Revision as of 21:08, 12 February 2011
Line 10:		Line 10:

	== Closed Issues ==		== Closed Issues ==
	Resolved issues that have no further actions to take. ~~These will likely be moved to a separate page like~~ [[process-issues-closed]].		Resolved issues that have no further actions to take.
	* none yet.
			See [[process-issues-closed]].

	== Resolved Issues ==		== Resolved Issues ==
	Issues that are resolved, but may have outstanding [[to-do]] items. ~~As issues are resolved, they will be moved from the top of the~~ [[process-issues~~#Issues\|issues list~~]] ~~to the bottom of this section.~~		Issues that are resolved, but may have outstanding [[to-do]] items.
	* none yet.
			See [[process-issues-resolved]].

	== Issues ==		== Issues ==
	Please add new issues to the '''bottom''' of the list by copying and pasting the [[hcard-issues#Template\|template]]. Please follow-up resolved or rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.		Please add new issues to the '''bottom''' of the list by copying and pasting the [[hcard-issues#Template\|template]]. Please follow-up resolved or rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

	=== ~~2005~~ ===		== 2011 ==
	* {{OpenIssue}} 2005-07-03 raised by [[User:Bud]]		* none currently
	*# I would point out that the paving the cowpaths method suggests that all you are doing is enshrining current practice. One question I asked myself is how something like reltag fits into that. hCard certainly does. Not sure about hReview. What I would say more is that you are "enabling emerging practices". Maybe you should say "widening the ferrett holes".

	~~=== 2007 ===~~
	* {{OpenIssue}} 2007-09-07 raised by [http://wiki.digitalbazaar.com/en/Haudio-case-study#Problems_Encountered_with_Microformats Manu Sporny]
	*# Issue 1: What constitutes "Enough Examples"
	*# Issue 2: Proper interpretation of W3C standards
	*# Issue 3: Keeping up with changes to the process becomes frustrating
	*# Issue 4: There is no clear order of operations for "The Process". This makes uF creation a trial-and-error process that can frustrate new members, that may waste time on things that don't matter. It also annoys old members of the community, that have to answer the same questions over and over again.
	*# Issue 5: Analayzing the receipts-examples is difficult because we don't have a central location to dump the example, scrubbed HTML. We need a central SVN repository.
	*# Issue 6: We don't have a central Microformats code repository for tools and utilities that are useful to the community.
	*## hg.microformats.org is the code repository we have been using for several years now. There is also a wiki that can be used to link to various implementations. A central code repository, or lack of, should not be an issue in the process when developing a new format?

	~~=== 2008 ===~~

	* {{OpenIssue}} 2008-07-24 raised by [[User:TobyInk\|TobyInk]]
	** Is the process more of a hindrance than a help?
	*** A look at the list of "official" (non-draft) microformats on the [[Main_Page\|main page]] shows that ''none of them'' were developed through the process — most have simply been [[poshformats\|POSH formats]] created outside the microformats community which were then "adopted". e.g. [[xmdp\|XMDP]] and [[xfn\|XFN]] from GMPG; [[rel-tag]] from Technorati; [[hcard\|hCard]] and [[hcalendar\|hCalendar]] were simply [http://tantek.com/log/2004/09.html#hcard proposed on Tantek's blog]; [http://tantek.com/log/2004/02.html#d25t1805 ditto] [[rel-license]]; and [[rel-nofollow]] is from Google. In contrast, drafts being run through the process languish there for years, their proponents often eventually giving up and abandoning them. Given that there are no examples of a microformat that has successfully made it through the process, it is not unreasonable to conclude that the process ''as is'' has failed.
	*** I am not arguing that there should be no process at all — indeed in Manu's article linked to above, he cites instances where the process is helpful. But the process should be less onerous than it is currently.
	*** In particular, clearer guidelines should be established for when each stage of the process is "over".
	**** ''examples'': how many is enough?
	**** ''formats'': how many is enough?
	**** ''brainstorming'': how long should editors wait for objections to a draft schema before "freezing" it and determining the class names?
	**** ''draft'': how long should a microformat remain in draft form before becoming "official"? would it be better to say that a draft will become official once there are N interoperable implementations (for some number N)? what scale of objections to the draft should result in a change to the draft, and which objections are big enough to send the draft back to the brainstorming stage?
	*** The process should be something that ''helps'' people establish new microformats; not something that they have to fight against.

	== Template ==		== Template ==

TobyInk: The Process - a help or a hindrance?

2008-07-24T17:42:59Z

The Process - a help or a hindrance?

@@ Line 33: / Line 33: @@
 *# Issue 6: We don't have a central Microformats code repository for tools and utilities that are useful to the community.
 *## hg.microformats.org is the code repository we have been using for several years now. There is also a wiki that can be used to link to various implementations. A central code repository, or lack of, should not be an issue in the process when developing a new format?
 == Template ==

Tantek: moved issue from Talk:process

2007-12-11T00:31:30Z

moved issue from Talk:process

← Older revision		Revision as of 00:31, 11 December 2007
Line 19:		Line 19:
	== Issues ==		== Issues ==
	Please add new issues to the '''bottom''' of the list by copying and pasting the [[hcard-issues#Template\|template]]. Please follow-up resolved or rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.		Please add new issues to the '''bottom''' of the list by copying and pasting the [[hcard-issues#Template\|template]]. Please follow-up resolved or rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

			=== 2005 ===
			* {{OpenIssue}} 2005-07-03 raised by [[User:Bud]]
			*# I would point out that the paving the cowpaths method suggests that all you are doing is enshrining current practice. One question I asked myself is how something like reltag fits into that. hCard certainly does. Not sure about hReview. What I would say more is that you are "enabling emerging practices". Maybe you should say "widening the ferrett holes".

	=== 2007 ===		=== 2007 ===

Tantek at 01:32, 13 September 2007

2007-09-13T01:32:00Z

← Older revision		Revision as of 01:32, 13 September 2007
Line 39:		Line 39:
	* [[process]]		* [[process]]
	* [[process-faq]]		* [[process-faq]]
			* [[process-brainstorming]]

Brian: added mention of code repository

2007-09-08T19:16:02Z

added mention of code repository

← Older revision		Revision as of 19:16, 8 September 2007
Line 28:		Line 28:
	*# Issue 5: Analayzing the receipts-examples is difficult because we don't have a central location to dump the example, scrubbed HTML. We need a central SVN repository.		*# Issue 5: Analayzing the receipts-examples is difficult because we don't have a central location to dump the example, scrubbed HTML. We need a central SVN repository.
	*# Issue 6: We don't have a central Microformats code repository for tools and utilities that are useful to the community.		*# Issue 6: We don't have a central Microformats code repository for tools and utilities that are useful to the community.
			*## hg.microformats.org is the code repository we have been using for several years now. There is also a wiki that can be used to link to various implementations. A central code repository, or lack of, should not be an issue in the process when developing a new format?

	== Template ==		== Template ==

ManuSporny: /* Issues */

2007-09-08T19:12:22Z

Issues

← Older revision		Revision as of 19:12, 8 September 2007
Line 26:		Line 26:
	*# Issue 3: Keeping up with changes to the process becomes frustrating		*# Issue 3: Keeping up with changes to the process becomes frustrating
	*# Issue 4: There is no clear order of operations for "The Process". This makes uF creation a trial-and-error process that can frustrate new members, that may waste time on things that don't matter. It also annoys old members of the community, that have to answer the same questions over and over again.		*# Issue 4: There is no clear order of operations for "The Process". This makes uF creation a trial-and-error process that can frustrate new members, that may waste time on things that don't matter. It also annoys old members of the community, that have to answer the same questions over and over again.
			*# Issue 5: Analayzing the receipts-examples is difficult because we don't have a central location to dump the example, scrubbed HTML. We need a central SVN repository.
			*# Issue 6: We don't have a central Microformats code repository for tools and utilities that are useful to the community.

	== Template ==		== Template ==

ManuSporny: /* Issues */

2007-09-08T17:27:12Z

Issues

← Older revision		Revision as of 17:27, 8 September 2007
Line 25:		Line 25:
	*# Issue 2: Proper interpretation of W3C standards		*# Issue 2: Proper interpretation of W3C standards
	*# Issue 3: Keeping up with changes to the process becomes frustrating		*# Issue 3: Keeping up with changes to the process becomes frustrating
			*# Issue 4: There is no clear order of operations for "The Process". This makes uF creation a trial-and-error process that can frustrate new members, that may waste time on things that don't matter. It also annoys old members of the community, that have to answer the same questions over and over again.

	== Template ==		== Template ==

PaulWilkins at 00:50, 8 September 2007

2007-09-08T00:50:26Z

← Older revision		Revision as of 00:50, 8 September 2007
Line 21:		Line 21:

	=== 2007 ===		=== 2007 ===
	* {{OpenIssue}} 2007-09-07 raised by ~~Manu Sporny~~		* {{OpenIssue}} 2007-09-07 raised by [http://wiki.digitalbazaar.com/en/Haudio-case-study#Problems_Encountered_with_Microformats Manu Sporny]
	*# ''Issue 1: http://wiki.digitalbazaar.com/en/Haudio-case-study#Problems_Encountered_with_Microformats''		*# Issue 1: What constitutes "Enough Examples"
			*# Issue 2: Proper interpretation of W3C standards
			*# Issue 3: Keeping up with changes to the process becomes frustrating

	== Template ==		== Template ==