This week saw the seeds being planted for a new digital humanities project, of which I am to play a development role. I will leave it to our team's promotion coordinator to decide how best to reveal the details publicly for this project -- but, I will say that I think it is a good balance of ambitious and innovative. It is a project I chose to be a part of as I wanted a challenge working with an operating system I've only regularly worked with years ago in undergrad (Linux) and to work with a funny little piece of hardware that has had developers and tinkers excited as children on Christmas since it's release (Raspberry Pi).
What I can offer instead of project details is a few understandings I've had from practical application development work that have come into play the first week coordinating major work between an interdisciplinary team of people who mostly work remotely.
Decide Early-On How Information is Going To Be Centrally Organized
This is crucial in any project of size and especially where team members work remotely. There needs to be a place where collective materials are placed. Make a habit of placing any project materials there by default, no matter how insignificant. Do not rely only on email to send files -- in fact, only use email to communicate information and point users to the correct location in the shared repository to do their work.
Decide on a Means of Version Control
There are many options for centrally locating files online -- and with each comes its own system version control (or not). When it comes to files in folder-based environments (like Google Docs or Windows Explorer), a central problem of version control is that it can be impossible to tell just by file names what the most recent version is. Say a file-naming convention is introduced that has participants appending a new version number to the file name each time they upload a new version of a document (e.g. HelloWorld_Version1.docx, HelloWorld_Version2.docx). There is nothing stopping two members of the team from both uploading Version2 simultaneously and/or mistyping their version number!
There needs to be at least one additional version control mechanism (e.g. emailing team members when a new version of a document is being worked on, then emailing team members when that a new version has been uploaded). Many document management systems already have version control built-in in some measure, though. For example, Google Drive allows one to select a document and upload a new version of that document -- while maintaining a history of previous versions.
This version control becomes invaluable on documents for which many hands are involved in the writing and editing, especially when one needs to look back at previous work. Simply overwriting the same document may work in some instances -- in others, not; this is another item to think through up-front.
Introduce Organization However Minimal
This could take the form of file-naming conventions, folders, folder-naming conventions, tagging, etc. -- it depends on the system. But it is important to establish at least a modicum of organization; it may seem like a hassle up-front, but it will pay off to also ingrain this in project practice as the amount of collective documents grows. Never place a document in the central repository without understanding where you're placing it (and that a version of it doesn't already exist in any folder).
Decide What Needs to be Tracked and Empower Someone to Keep On Top of It
Thinking about what needs to be tracked and, once again, doing the work to putt this together upfront will save you many a headache in the long run. An example: my team has to provide a status update and/or reflection each week to the professor moderating the praxis. How do we know what our 'status' is if we're not keeping track of vital status indicators? Of course, these indicators will change project-to-project -- but the bare minimum of what needs to tracked can often be found in the project description. In this case, a mechanism to track who is submitting our reports when is invaluable.
One way to do simple tracking is through Google Sheets (Google's web-based spreadsheet application based on Excel). This application has many handy features -- such as conditional formatting, formulas, data validation, etc. -- to help you structure the tracking information being entered by many different parties.
What is just as helpful as actually tracking important details is empowering members to take charge of alerting members to issues. It helps to be explicit in telling whomever may have the responsibility of keeping team members on their toes that it is okay to be a nuisance! This helps create an atmosphere of accountability for work getting done. Likewise, regular check-ins and settings up reminders in advance can help keep work on its track.
Additionally
It may prove helpful to take any number of the following actions:
- Create a team Calendar. One way is creating a Google Calendar and Sharing it among Team Members. If you want to get fancy, you can sync this Calendar with your phone and set up alerts for project deadlines.
- If the shared repository is web-based, explore its functions for offline work. For example, Google Drive allows has ways of allowing documents to be worked on Offline and synced when an internet connection is made. Downloading the Dropdox client also introduces automatic syncing with a folder on a user's device.
I'd love to gather any other invaluable tips for starting a new collaborative projects -- leave any insight below!
This blog is licensed under Attribution-Noncommercial-Share Alike 3.0 Unported license.