On 21/06/16 11:22, WJH wrote: > Essentially I was making a similar point about the difference between familysearch (which I would say is essentially a wiki since it shares a single view of "the truth" to which all members contribute) and ancestry.com (which is more of a collection of individuals' work). I am certain that the familysearch platform could be improved in many ways, and its reasons for wanting such a unified view of history may not be shared by everyone including me, but that doesn't stop it being a useful tool... You keep using that word (wiki). I do not think it means what you think it means. A wiki is a file (or collection of files) using a simplified text mark-up language which can be easily editied by online tools and converted into HTML for display by a browser. Whether editing is a free-for all or not is a completely different matter. It is /not/ a general term for online collaboration. Familysearch is not a wiki. It is a database for structured data, which can be accessed by HTML. Using the term too broadly simply serves to sow confusion. As I've suggested a couple of times in this discussion there's a need to step back from assuming what tools to use and, indeed, what form of governance to use until it's decided what, if anything, we want to do. In particular I suggest looking at how the open-source software movement goes about using the net. This has proven, rigorous techniques for successfully handling vast amounts of material (in this case computer source) to achieve complex products that work extremely well. Handling vast amounts of material to achieve a complex product that works extremely well ought to be an objective for any collaborative genealogical undertaking. There are a few characteristics to consider. Firstly, from an organisational point of view the material is curated by a /maintainer/ or hierarchy or team of maintainers. /Contributors/ can offer material or changes, but it is the maintainers who have the access to /commit/ those changes to the body of material. Secondly, the material is held in a /source code management system/ accessible online. This tracks changes so that any given past configuration of the material can be retrieved and the specific update that made a given change can be identified. Modern usage favours /distributed/ SCMSs such as Git or Mercurial. In these a user can download the material or a subset. The user can then work on it offline, extract the changes, either additions or modifications as a /patch/. This is a small file which can be applied to the main body of code to bring it into line with the user's changed version. This can then be submitted to the maintainer(s) who can decide whether to apply it. Users with their own copies can periodically refresh their copies to keep current. Thirdly the project's material is under a copyright licence that affords individuals the right to copy and distribute the material - the conditions attached to such licences vary and are, indeed, the subject of sectarian disputes but all adhere to the principle that the material is a form of commons. Taken together with the distributed nature of the SCMS this means that it's possible to take a version at some point in time and establish a new maintainer-ship to curate it separately from the original. This is called a /fork/. It might appear that this could lead to chaos but is, in fact, quite unusual. It could happen with single maintainer projects if the original maintainer becomes inactive for whatever reason. It also happens sometimes if a sufficient body of contributors become dissatisfied with the existing governance. The most striking example of this is the fork of LibreOffice from OpenOffice. In practice a fork is only practicable if a sufficient body of contributors support it. A characteristic of this is that the quality of the product is usually paramount. Governance is minimal. There are a few instances in which foundations with boards of directors form a protective shell around the project; for instance the Linux Foundation has been one of a number which have established and controlled trademarks around a project to protect it from predators. Such foundations also raise finance to fund hosting and pay professional developers. From observation ISTM that in some cases they also provide a platform for individuals to play politics unrelated to the matter at hand. A foundation should necessarily be at arm's length from the project it supports; it can't survive without the project but usually the project survived without the foundation and should be able to continue to do so if necessary. An interesting point to emerge is that companies which are in competition with each other still find it advantageous to collaborate with each other in such projects. This again might be contrary to the expectations of some views discussed here. Finally, it's worth looking at the tools being used. SCMSs I've mentioned. Communication is often by mailing lists, especially as a means of submitting patches. Some projects make the mailing lists completely open, in others maintainers might communicate with each other privately. However, bug-trackers are another means of discussion about corrections and this might well be a tool to consider for a genealogical project. Wikis are also used by some projects but usually, from what I've seen, as documentation of the product. -- Hotmail is my spam bin. Real address is ianng at austonley org uk