A Team Protocol to help you prepare and plan for merging Hermeneutic Units in ATLAS.ti 5.0
There is much detailed help and advice provided in the ATLAS.ti online help sections, written by Susanne Friese, of QUARC: either go to the sections on Collaboration, or do a search for Merge. What follows here, is a minimal set of instructions and safeguards designed to make you aware of various issues in order to enable teams to think about the software related logistics of merging work if you want to consider that option. Some teams decide against merging for reasons to do with time, complications and unfamiliarity. Other teams consider it is a crucial factor in the whole decision to use software to assist in the analysis. The protocol below is based on the idea that you will perform an early test of the whole process, in order to make this decision in an informed way and to enable you to create your own specific protocol to suit your own project. This page does not comprise the whole step by step process or give advice on all the different ways of working. This page is based on a general premise that you as a team will work separately on different aspects of the project, but at your own workstations.
SAFEGUARDS FOR HU and DATA FILES (PRIMARY DOCUMENTS)
There will be many models for merging HUs and the work done by separate members of a team. As yet, it is still not possible for simultaneous work to be done from separate workstations on the same project or HU. On the other hand,in ATLAS.ti the team and their separate HUs can all be ‘reading’ from the same source location for the individual data files within the HU, but the complications of using this method are not fully taken into consideration below. However, if you as a team do decide to read data from one location e.g. (a shared drive), it is very important to consider the following safeguard:-
Individual textual data files should be prepared and saved in Word format, to prevent accidental edits which threaten the integrity and safety of the mechanisms within ATLAS.ti.
NB: Remember the data files or documents remain outside the HU, when you assign them, you merely connect the HU to the path of the data files (external database).
However you are working, however you are connecting to data as an individual or a team, for beginners or for a mix of different levels of experience within the team, it s always better to try to import a finished version of the individual data files, in Word format, rather than to retain editing permission by saving them in Rich Text format, and. For more information on this:
See notes on data preparation for ATLAS.ti.
RECOMMENDATION: quite early on practice the steps below, to get an idea of the logistics of merging. You can practice the merge on two slightly different versions of your own HU… you will quickly get an idea of how quickly HUs multiply on your computer once this process starts. For this reasons its very important to come up with good naming protocols for , working versions, backed up, Bundled, Saved as, and newly merged versions of your HUs. So that you can delete older versions of the HUs (but never the datafiles themselves). After you have practiced a merge you will understand better the suggestions and cautions which form this initial protocol.
Before merge safeguards
- With your HU open, back up your HU, by copying Bundle (see Backing up/ATLAS.ti –link here) –(a sensible thing to do is to create a folder on your computer…maybe under My Documents, call it ATLAS.ti backups)
- Save as your open HU (this will be referred to later as the TARGET or master HU) to rename it, so that if you make a mistake, you do not irretrievably damage your ‘working’ version of the project (HU).
- Repeat steps 1 and 2 on the other HU or (referred to in the merge as SOURCE HU).
Practise merging 2 HUs
- Re-open the HU you have just Saved as, ATLAS.ti refers to this as the TARGET HU
- From the HU Editor’s main menu, select Tools/Merge with HU.
- It will already have put the path and name of the HU you have open into the grey box next to Target HU
- In the browse pane next to Source HU, find the source version of the HU that you recently Saved as (Step 3). See Figure 1.
- When you see the next Merge HU (define strategy pane)..what you will see on the left are broad merge models to choose from, on the right, fine tuning options for the model you choose. For instance in my practice session, I have chosen to merge to slightly different versions on my own HU. So I have chosen Same PD’, Same Codes, because I want the documents merged(unify) and coding merged (unify) on the same documents (I don’t want two versions of the same document). I don’t need to change the fine tuning: if documents have been changed they won’t merge; if extra codes have been added in one project they will be added in to merged project; if same codes are spelt differently they will not merge(unify). See Figure 2.
- As a team decide what option is relevant to the working logistics and division of labour you planned for.
Figure 1. Selecting source hermeneutic unit.
Figure 2. Defining the merge strategy in Atlas.ti
ACTIONS / DISCUSSIONS / DECISIONS DURING WORK PRIOR TO REAL MERGE ? - suggestions
A. You should universally choose an efficient format for the transcription of data See notes on data preparation for ATLAS.ti.
B. Work division… Different files? Same files-different aspects? NOTE: they may be different files until first merge, but if different individuals continue to work on the newly merged HU, next time you do a merge, you are more likely to have to choose the options Same files, Same codes.
C. Coding Schema – a team project often makes concessions to pragmatic agreements about coding schema up front. Much negotiation has to occur between the team members about what codes might be relevant, what is meant by each code, style of applying codes (how much text –surrounding context etc).
D. If you choose to agree on a coding schema, and yet retain some flexibility for the creation of new codes, you will still choose the Same Codes option at the time of the merge – but new codes could be identified by initials of team member e.g. AL-family influence (A. Lewins’ new code family influence) Its useful for the team leader or ‘mergemaster’ to be able to easily identify the author of a new code.
E. Choose a similar Memo naming protocol, which identifies each members’ own memo’s, so that they can be sorted and identified easily
F. Each team member create his own Teamtalk (initialled) memo, which is a centralized location for main points of discussion, uncertainties, negotiation.
G. Careful Copy bundle, Saving as of all relevant HUs before Merge, to safeguard original HUs as per steps 1-3 above, before the merge.