All
It is pretty obvious the we are in a place many other net based groups have faced...where are we going and how do we get there?? Group governace of something like Xith is difficult, perhaps a small set of...err...guidelines..might be able to establish a process we can all agree to to some degree.I have been thinking on this and have a few ideas to toss around in no particular order.
o Sub projects that are actively maintained by the original author, required the authros input before another user makes API breaking mods or radically alters behavior. This is between the author and who ever in making upgrades…I am thinking of the recent HIAL mods that involded William…very nice collaboration here…three cheers!!!
o If a user wishes to modify a sub project and cannot find or get the original author to particpate, they should propose changing it without authorization. While I strongly hold to the concept that authorship is deserving of great praise and respect, at the same time I feel if I have written something, and I don’t plan on improving/fixing it, I lose my rights to veto changes after some acceptable time frame. Similar to posting estate information in a newspaper…people have N days to make a claim on assets, if thay fail to do so they lose out… People come and go in these situations, current participation weighs more than older participation in my books
o Major API changes should be described in a small proposal, open for discussion for a week or two. People vote with their comments…if you fail to vote for your elected leaders you cannot complain about your taxes.!! If a resolution can be achieved a release can be rolled for people you wish to stay with previous API’s . The power of individual votes is up for interpretation, some people are very active and maybe should have heavier weighting on their vote, other haver professional vested interest (Croft!!) in stability…this deserves a heavy vote also.
O Major API changes need to be inserted along with at least a verbal commitment that you rebuilt and tested the demo programs. After years of programming I am still amazed at the sublte surprises I have coded into my fixes.
o Major API changes need to be demonstrated in a new example or a modified demo…absolute requirement…prove your changes actually work…
o MyFavoriteFunctionVersion10298 is just a rediculus naming scheme, If something has been significantly modified then the two rules above validate the work and now our examples all point to the more current work (thinking of textureloader versioning)
o I like depracated functions to identify older non supported stuff…I am not sure if this works with small changing development groups with only occasional releases… I would prefer to update things to the newer version and drop old versions, since the API changes were proposed and discussed an ealier posting then there will be a general feel if anyone is going to be advesly affected before the changes occur.
Just some thought…your milege may vary 
