Although Brandon Catteneo posted the following as a comment to the previous post, i felt, considering the level of thought and ideas within, I needed to post again for more visibility…
This is great! SL is spawning yet another revolutionary concept. I think this is an excellent idea, and I am very interested in seeing it take off. I’ve read the minutes on The Arch from your meetings. Obviously the scope of the task is large and will require a lot of grey matter to come up with standerds, but as far as using SL for the Wikitecture platform it is possible to accomplish this collaboration by engineering the workflow properly:
1) Each Project Needs a Project Manager:
Designer Dingson hit the nail on the head when he said “every team regardless of whether it is free colaboration or not – needs one thing for sure and that is a ‘leader’.”
Whomever owns the land is, by default, the PM. If it becomes too cumbersome you cut up the land into parcels and give each one a PM. If that is too much the PM designates an assistant PM for each separate structure (I will use the term ‘build’ from now on since that is what is used in SL).
The PM is responsible for the general management of the land and has the ability to delete or return any objects found thereon. He can change permissions on the land to prevent vandalism and act as POC for griefing incidents (to issue bans, etc.). Further, the PM acts as liaison and POC for the group, the Lindens, the creator/designers/builders (I’ll use the term ‘builder’ from now on since that is what is used in SL), and the community as a whole. It sounds complex but it really is not. See below:
2) Self-Determination is the Engine of Organization:
All builders want their creations recognized. Therefore, just as on Wikipedia, they need to adhere to some simple rules. If you do not properly format your text on Wikipedia it will be edited by someone else who will put it in the proper format. So too with Wikitecture. The builder must adhere to a few common criteria:
(a) Save Your Work: The builder will obviously save his own work into his inventory, and if he wants to prevent it from being deleted by the next person to come along he must also submit it to the PM (or his delegates). If the build needs to be ‘rolled back’ as they do on Wikipedia the PM can do that at anytime (and so can the community if the PM chooses).
(b) Use Comments: Just like on Wikipedia if you change something it is wise to add in some comments and (preferably) put some notes on the Talk Page about what you changed and why you changed it. In this case the builder simply jots down the changes in a ‘Builder’s Notecard’ and submits that to the PM along with the build.
(c) Use a Common Versioning Standard (CVS): Before submitting your build rename it to a new version. I would suggest the format x_ YYYY_MM_DD_b where x is the name of the build and b is the name of the builder. Thus the Catteneo Hotel would be called Catteneo Hotel_2007_03_02_Brandon Catteneo. If this is changed on March 14th of 2007 by Designer Dingson it would become Catteneo Hotel_2007_03_14_ Designer Dingson. (obviously this is just a proposal, and maybe this particular standard is adopted and maybe we decide on something else, but you get the picture)
(d) Prototype the Build: The concept of “shards” is great (if I understand it correctly). On Wikipedia you preview your work before you commit the edits, and so too should this be done on a Wikitechture build. Do your work in a sandbox or some other unobtrusive area, then replace the ‘live’ build with the one you have constructed. If it has changed since you were there last add your elements to the design. Ideally this will not be necessary (ideally), since builders can collaborate with the other builders working on that particular project.
3) Each Build is Accompanied by an Infoprim:
The Infoprim can have any appearance (maybe a spinning question mark “?” symbol outside of the build, or maybe an object within the build like a kiosk in the lobby in the example of the Catteneo Hotel), but the objective is to have an object that delivers a Builder’s Notecard with the revision history of the build, similar to what you have on Wikipedia. The PM is responsible for keeping this updated with the text in Notecards given to him by subsequent builders (simply cut n’ paste, save new, put in Infoprim). This is the bare-level requirement for the Inforprim, but it can also do much more.
Obviously, the Infoprim can also store previous builds – it is up to the PM. These can be Copy/No Mod/Transfer so that anybody can walk up and pull out a previous version, rez it, and look at the differences between the current version and past versions. It can also include a running commentary – a Community Notecard. A LM to the build (or any other place) can be placed in the Community Notecard. There can also be a Request Notecard for changes that are needed just like on Wikipedia.
Future upgrades to the functionality of Infoprims in general can be easily implemented by distributing the new scripts to the PMs, who will update them as with any build.
– – – –
So the process from the PM’s standpoint is simple: A build is created on land you manage, and the builder submits the build to you as an object in your inventory along with a Notecard. You save the builder’s Notecard, the build and a standard Notecard that has instructions, rules, contact info, etc. into an object of your design – this will be the Infoprim (make sure to designate it as a ‘give Notecard’ object). You place the Infoprim near the build with Copy/No Mod/Transfer. When a new version is dropped into your inventory by the next builder you simply update the Inforprim. Of course you can delegate tasks (such as placing Infoprims or updating the Notecards) so long as you have all the versions of your projects in your inventory.
As a PM you are obviously part of the group that owns the land. If the group decides, the PM can change permissions on the land so that nobody can build there. If builders want to update the current build they have to do it in a sandbox and then submit it to you and then *you* will go place the object. (This would be used in cases of persistent vandalism.) Also, the group can make a rule that all objects must be saved into a Group Only Mod object and this be distributed to all group members anytime there is a new version. This can be done in a ‘digest’ (e.g. daily/weekly/monthly) format if there is too much activity and people are complaining about being spammed, and maybe you have committees for certain aspects or areas.
From the builder’s standpoint it would look like this: Go to the build and take it into your inventory. Rez it (preferably in a sandbox), edit it, save it in the proper format, and then place it where it is going to be “live”. If you want it to stay and not be rolled back make sure to drop it on the inventory of the PM, and include a Notecard specifying what you did and why. All of this will be explained by touching the Infoprim, and all the previous builds will be available to you by opening the Infoprim and copying them to your inventory (if the PM chooses to allow it).
From the Community’s Standpoint: You come upon a build you think is great. The Infoprim will tell you all about its history, and you can also compare past versions if you wish. If you have suggestions or comments the info on who to give those to will be in the Builder’s Notecard (obviously), as will past commentary in the Community Notecard.
– – – –
So that’s my 2 cents, but hopefully this can be a basis for starting to move