process-issues: Difference between revisions

From Microformats Wiki
Jump to navigation Jump to search
(The Process - a help or a hindrance?)
m (Replace <entry-title> with {{DISPLAYTITLE:}})
 
(2 intermediate revisions by one other user not shown)
Line 1: Line 1:
<h1>process issues</h1>
{{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.  
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 ==

Latest revision as of 16:31, 18 July 2020


These are issues that have been raised about the microformats process with broadly varying degrees of merit. Thus some issues are rejected 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 accepted and perhaps cause changes or improved explanations in the spec.

Important: Please read the process FAQ before giving any feedback or raising any issues as your feedback/issues may already be resolved/answered.

Submitted issues may (and probably will) be edited and rewritten for better terseness, clarity, calmness, rationality, and as neutral a point of view as possible. Write your issues well.

Closed Issues

Resolved issues that have no further actions to take.

See process-issues-closed.

Resolved Issues

Issues that are resolved, but may have outstanding to-do items.

See process-issues-resolved.

Issues

Please add new issues to the bottom of the list by copying and pasting the template. Please follow-up resolved or rejected issues with new information rather than resubmitting such issues. Duplicate issue additions will be reverted.

2011

  • none currently

Template

Please use this format (copy and paste this to the end of the list to add your issues):

  • open issue! YYYY-MM-DD raised by YOURNAME.
    1. Issue 1: Here is the first issue I have.
    2. Issue 2: Here is the second issue I have.

Related Pages

Retrieved from "http://microformats.org/wiki/index.php?title=process-issues&oldid=70027"