[uf-discuss] issue rejection governance? (Was: rel-tag title as tag value)

[Scott Reynen]

On Feb 26, 2007, at 3:39 PM, James Craig wrote:

> Mike Kaply wrote:
>
>> I want a solution that involves the web page, NOT the server.
>
> I agree, but my response here is not about rel-tag. It uses rel-tag  
> as an example in a larger issue regarding issue rejection.
>
> In the month or so I've been on the discussion list, the "rel-tag  
> title" issue has been raised many times, indicating a valid need  
> for a less-than-ideal alternative. Many of the stake-holders seem  
> to have tagspace-enabled sites (Technorati, Flickr, etc.) and,  
> while that is the ideal situation, they also seem defiant in their  
> willingness to admit creating a tagspace is problematic for many  
> users. I tracked down what I believe to be the documentation of the  
> first time this issue was rejected.
>
> Quoted from:  http://microformats.org/wiki?title=rel-tag- 
> issues&diff=4885&oldid=4881
>
> "Issue 3: It's not reasonable to restrict the host's REST  
> implementation according to this spec's rather limited idea of a  
> 'good' tag URL. The idea of tags as query parameters is rejected  
> without justification, for example. Query parameters are a  
> perfectly legitimate means of denoting state.' REJECTED, IGNORES  
> ESTABLISHED PRACTICE. Flickr and del.icio.us and other tagging  
> sites established the defacto standard of having the tag term be  
> denoted by the last segment in the URL and thus defined what makes  
> a 'good' tag URL. rel-tag has codified this good practice."
>
> I was not on the list at the time, and therefore cannot verify that  
> this issue was not discussed openly, but I also cannot find on the  
> wiki the due process of issue rejection. Format rejection is  
> defined, but issue rejection seems arbitrary. The closest thing I  
> can find is "some issues are REJECTED for a number of obvious  
> reasons and others contain longer discussions" on the Microformat  
> Issues page. I am not implying the uf group step to the  
> deliberation level of ISO or the W3C, but some issues should not be  
> noted as REJECTED by an individual, at least not without fair  
> consideration and voting. If this process exists, or if there is a  
> process for rejection APPEAL, it needs to be documented. If it does  
> not exist, it needs to be defined.
>
> For example, the previously noted rejection statement seems  
> opinionated to me. If for no other reason, the frequency of this  
> request demands that it receive more consideration and deliberation.

Naturally we all have opinions, but I think we also share a common  
agreement to follow the microformats process, so if you want to  
pursue an issue either pre- or post-rejection, the process is still  
the best way to do this.  In this case, the rejection includes  
examples of existing tag spaces which follow the established standard  
URL format.  If someone wants to suggest that this standard doesn't  
reflect a clear (80/20) majority of real-world publishing, collecting  
counter-examples (sites that use tags with some other URL format)  
would do a lot to support that argument, and also provide a good  
basis for determining a solution if this is ever considered a  
legitimate issue.  Make your case with real-world examples, and I  
think you'll find rejections come less readily.

But rejections will still come without a lot of justification.  More  
generally, I think you might be missing a fundamental principle of  
microformats: they don't demand reasons for rejection as other  
processes often do.  Much the opposite, microformats demand reasons  
for consideration.  In the interest of stripping microformats down to  
the simplest semantic building blocks (largely the basis of  
widespread adoption success), rejection is the default response to  
any additions.  The process description even starts by discouraging  
more microformats:

http://microformats.org/wiki/process

I think everyone will agree that more documentation would be good,  
but I'd encourage you to better document *why* before asking others  
to better document *why not*.  Again, bringing this back to the rel- 
tag example, anyone who thinks the de facto standard of tag space  
URLs is not reflected in the current rel-tag spec should document  
real-world examples to test that hypothesis.

Peace,
Scott