Project Guide
From LiquidPubWiki
Contents |
Summary
Our collaborative work will become a huge mess if we don't agree on how to create and update common information. Of course, work internal to one group can be handled how ever that group feels is best.
The LiquidPub project has a fair amount of cyber-real estate in use and it can be confusing to know where to go to post common information, or where information is being kept. This document is an attempt to provide some initial guidelines and get everyone on the project together to discuss the resources and practices we need in order to be successful. None of what follows is an attempt to specify what is "right" or "correct". Please feel totally free to use the discussion tab at the top of the page to comment on anything. If there is some consensus that we should handle some aspect of our collaborative work differently, these guidelines will be changed.
In order of priority, the resources you should look to are: the Project Wiki, Google Docs, email, and Zoho. In the following sections we will discuss the rational for these priorities.
Motivation
We have a lot of moving parts to coordinate due to the number of partners and individuals involved in the project. We also have truly lofty goals. We are trying to cause a paradigm shift in the production, dissemination, evaluation, and consumption of scientific knowledge. We are at the same time researchers and, as scientists, the subjects of our own research. The requirements we have for collaboration are the requirements we must address in any solutions we offer. The actions we must perform in doing our work are the tests that our solution must pass to be successful. Therefore we must take a closer look at the daily problems we have in our work on this project. Please use the Liquidpub Wishlist to record any shortcomings or features that you feel would make our work go better.
All this is part of requirements collection in a way: trying to understand what is the best way to perform collaborative editing of a complex object among a potentially large group of people, while leaving the flexibility for small groups to work with the tools they find best. This experience can be a little painful the first time around but can be very insightful. Later, as we develop the LiquidPub platform, we'll want to begin using it for our work. Then we will see if we are making progress, or not.
History and Considerations
We started out with email and an account on Zoho.com. The idea was to discuss in email, and trade and collaboratively edit documents on Zoho. Zoho could provide online storage and access control. However, it became apparent pretty quickly that the editing capabilities of Zoho were too limited.
Plans were already underway to set up a wiki partly as an aid to collaboration and partly to study the particular shortcomings of this popular platform. Once Zoho was deemed insufficient for collaborative editing the wiki became the focus for collaborative work. One of the strengths of wiki platforms is the accessibility and relatively easy use. Unfortunately, one of the shortcomings of the wiki (specifically MediaWiki) is that permissions are relatively inflexible, leading to difficulties in selectively restricting access. This meant that files that needed special access handling might be best left in Zoho. Consequently, it is difficult to completely abandon Zoho. One option for replacing Zoho is Google Documents.
Google Documents has the same functionality as Zoho documents, plus more powerful editing. Sharing Google Docs is fine-grained, by explicit email addresses. Both Zoho and Google require registering for an account.
What Goes Where?
Given the situation, here are the suggested methods.
- For as much collaborative work as possible -- use the Wiki.
- For selective access for collaborative docs -- use Google Documents.
- If neither the Wiki or Google Docs are workable -- use email.
- For storage of selective access docs -- use Google Docs or Zoho.
Use the "discussion" tab at the top of the page to leave your comments.
