The two biggest goals in my mind would be:<p>1) You involve the API consumers in the design and decision process, which helps in understanding their use cases better.<p>2) Give insights and transparency to consumers as to why and how some decisions were made about the API.
How would you deal with the issue of having to respond to everybody's comments, this could end up being a time sink.<p>E.g. you write a beautiful proposal on some new feature and then joe schmoe comes along and shits on your idea without taking time to consider it.<p>Now you have to either ignore his comment, leaving it there for other schmoes to read, or respond to it which takes time away from doing something constructive.
<i>"Embrace and extend." -- Bill Gates</i><p>These days that would correspond to forking the spec. So unlike an open source programming, it is not nice to fork the spec.<p>Or is it?
I like the idea of contributing but it would be nice if I could give a simple up vote rather than having to add a full comment. You may get weighed down by "me too +1" comments.
One of the goals should be the guarantees given that the API spec that's documented is actually reflected on the live version and the steps taken to ensure its accuracy.