Working Together in a Team
There are several strategies for organising collaborative work on the same project in QualCoder. Choose whichever best fits your methodological approach and specific working environment.
1) Sequential Editing of the Same Project
This approach can be applied to both inductive and deductive coding. It is based on the principle that all team members work on the same project files, albeit not simultaneously.
Coordinating the Sequence of Work:
- You can do this via email so that each person, upon completing their tasks, mails the zipped project folder to the subsequent individual on the list.
- You can also work sequentially on the same computer, using the same project folder.
- If you coordinate the work manually, using a cloud-sharing service like OneDrive or Dropbox to transfer the files is also an option. However, it's critical that a) under no circumstances should two people access the same project simultaneously, and b) the project must be fully synced with the cloud service before passing the work to the next individual. The succeeding person must also ensure they have downloaded the latest version from the cloud before beginning their tasks. Be careful: Project versions getting out of sync may corrupt your data, and you then have to revert to a backup copy.
- Please do not use REFI-QDA Project export as a routine approach for collaboration when all coders are using QualCoder. Use one of the other options described here instead. If you need to open a project in different software (e.g., Taguette, NVivo, Atlas.ti, MAXQDA, Dedoose, Quirkos), only then should you use the REFI-QDA Project export. Project features can be lost when transferring a project between qualitative software using the REFI-QDA Project export.
Handle coder-names carefully (see below).
2) Using a Master Project: The 'Coding Separately Then Merging' Approach
This strategy allows your team to work simultaneously to some extent. It is most effective if you use a deductive coding approach, where the code system doesn't change much during the analysis. If you use it with inductive coding, be prepared to spend some time cleaning up and consolidating the code system when merging the work of different team members.
Follow these steps:
- Create a master project with the code system already defined (if applicable).
- Ideally, import all empirical documents at this stage. Avoid linking to external files, as this complicates the distribution of the project.
- Zip your project folder, including all subfolders and files, and send it to your collaborators (email, file transfer, or USB-stick).
- Decide on a strategy for handling coder names in your team, as explained in the notes below.
- Now, each team member can unzip their local copy of the project and work on it independently, adding codes, codings, memos, etc. However, do not edit the imported text of the empirical documents themselves, since this will potentially cause problems during the merging process later.
- Finally, gather all the local copies and sequentially merge them into your master project, using the process described here
Important Considerations Regarding Coder Names
- In most cases, you want to have a unique name for each coder on your team so that individual contributions can be identified even after merging the project together.
-
In Project > Settings, click the "Change" button next to the coder name to open a window where you can alter your own identity or create, rename, or merge other coders within the current project.
(Note that "📌 Speaker coding" is used internally to automatically mark speaker utterances in transcripts. This name should not be used for other purposes.) -
Be careful, especially with the Merge function, as there is no Undo. If you make a mistake while you are in the coder names screen, press the cancel button, and the changes will be reverted. After clicking OK, the changes are permanent. However, the merge function will make a copy of your project before the merge with a pre_coder_merge suffix.
- In the same window, you can control the visibility of other collaborators. Since version 3.8 of QualCoder, contributions from other coders are always visible and editable by default unless you choose otherwise. Hiding other contributors is especially useful for measuring inter-coder reliability, which requires multiple people to code the same document without influencing each other.
- This window is also accessible from the toolbar in the code text, code image, and code PDF workspaces, albeit with limited options.
Warning
Do not keep the project folder on a network drive or in a cloud location, and access that location whilst running Qualcoder. If the database connection is lost, it would corrupt the database while QualCoder is performing a series of database operations.
Backups
Make a backup of the project folder before doing any substantial changes, such as a substantial reorganising of codes and categories, merging projects, or merging codes. QualCoder does perform hourly backups (keeping up to the most recent five, if backups are set in the settings). Also, do not store extra files or outputs within the project folder.
In addition, for good data management practices, you should have a regular backup schedule for your work and also back up the project to different devices or drives.