[uf-new] hAudio/Audio RDF clarification (possible admin moderation request)

[Ben Ward]

On 15 Sep 2008, at 17:50, Martin McEvoy wrote:

>> Martin McEvoy wrote:
>>> I will be adding Myself as Editor on the Version 1.0  format,  
>>> because I don't have some other agenda other than completing haudio.
>> In fact forget that its not very diplomatic, I will Invite Tantek,  
>> or Brian to edit the 1.0 version of hAudio they are the two admin's  
>> that have had the most input in haudio, haudio may gain a little of  
>> its credibility in this way, and I think that it is the best.
>>
>> I will be emailing the admin's airing your total disregard of  
>> microformat's principles, and of the damage you are causing the  
>> Microformats Community, in particular hAudio http://microformats.org/wiki/haudio 
>>  and currency http://microformats.org/wiki/currency to which you  
>> had no hand in authoring.

Obviously the admins are open to email from anyone about any issue,  
but I for one would prefer that as much of this complaint is resolved  
in public, please. And, of course, the personal issues are more  
complex and it's up to individual judgement if you think it's more  
appropriate to take something offlist.
I'm just emphasising that as much as can be resolved openly in this  
community and through process adherence should be, please.  
Additionally, my feeling is that I'm not involved enough in hAudio to  
comment on specifics, so what follows is quite general.

That said, a few things regarding the process/development side of this  
seem quite clear to me. I want to know if the alleged process  
violations can be handled within the development process itself,  
rather than being an admin issue. Please consider these points:

• All issues with hAudio, be they problems to solve, capabilities to  
add, incompatibilities with the Process or anything else should be  
tracked as issues on the microformats wiki. (http://microformats.org/wiki/haudio-issues 
). For a format to advance, issues need to be resolved. If issues are  
not resolved, the format can't be moved to its next stage (be that  
draft or spec)

• If an issue is ‘resolved’ in a way that is incompatible with the  
process (regardless of who resolves the issue), that issue cannot be  
resolved without addressing that breach of the process. Addressing  
that could be: Changing the issue resolution or changing the Process  
if the process were to be found to be broken. Either way, issues  
against formats cannot be resolved whilst in unaddressed violation of  
the process.

These two points *should* prevent any individual ever pushing through  
a format in a manner which is incompatible with the process. If issue  
resolutions are insufficient, the issue must be reopened.

Martin, if enforcing the process in the manner I describe here is  
insufficient to avoid/revert the issues you've raised, I'd be very  
grateful for elaboration or example of where these two checks have  
been avoided. Where the above is sufficient, anyone involved in hAudio  
development should be able to reopen issues that haven't been  
adequately addressed.

Again I emphasise that I'm not endorsing any side of this personal  
argument at this point, and I'm speaking generally for that purpose.  
What I am trying to do is jump in quickly to apply the Process to the  
development problems raised, and avoid the personal aspects of this  
complaint being tangled with hAudio process issues.

Thanks all,

Ben