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
_______________________________________________
microformats-new mailing list
[email protected]
http://microformats.org/mailman/listinfo/microformats-new
