I think @amelia has a timetable in mind. But yes, I can’t imagine it would be a big thing. A week.
Nermine won’t need to merge or fork codes til a second pass, so we have a little time (a couple of weeks after she gets going). She also hasn’t replied to me yet so fingers crossed that happens soon! I checked in with her at the beginning of the month and she was still on board.
And as if by magic she responded we are good to start.
@amelia and @alberto: The three features as discussed are ready to use since a few days, maybe you noticed already via Github or the OE software. In addition, I decided to let Daniel fix some of the more annoying issues in Open Ethnographer until the 600 EUR budget allocated above was used up. So in total, this is what we got for that budget:
#122 Allow Ethnographers to merge two codes. Allows normal users to merge their own codes only, and Discourse admin users to merge codes of different authors together. (That latter addition still has to be documented somewhere properly.)
#114 Implement annotation lists per code.
#123 Create a web interface to access annotations by author and by Discourse tag.
#108 Removing the non-working “Collections” UI elements.
Discourse admins can change code and annotation ownership. I’ll need that in the next days for example to assign proper ownership to the annotations Anu imported manually from the Drupal platform.
Invoice will follow shortly in FreeAgent, as usual.
Great, Matt and thanks @daniel. I did see the GitHub notification but was not sure that the new code had been deployed. I’ll test it…
For the discussion how the Discourse tags to mark Open Ethnographer projects should look like:
project-* tags were supposed to keep together content of our various client projects even after they finish and we sort in their content elsewhere. See the “Admin tasks for edgeryders.eu” manual at “Tags for project content”. The idea is that we will eventually have a nice list, for example on the “Company → Our Work” page, with links to the complete content of each project we did.
For that reason, all OpenCare content (including the one not meant for Open Ethnographer) should have the #project-opencare tag. And all content should only have one
project-* tag because it only belongs to one client project we do. So in this scheme it’s not possible to introduce
Proposal: I was thinking of introducing project-specific tag namespaces that can be used however people like (and give the assurance that mods and admins won’t mess with them). They would start with the project name as prefix, and anything afterwards. So @amelia could use
opencare-extracontent or similar to mark OpenCare content outside the OpenCare category that should be coded in Open Ethnographer. By including this in a tag group with
project-opencare as parent tag, it is also ensured that nobody can use this tag outside of OpenCare content.
If you agree, could you update your instructions above accordingly?
Your naming convention proposal is a bit unclear. It assumes that every ethnographic research project has to have a correspondent client project, but that’s not necessarily the case. For example, you could have a project called “Alberto’s thesis”, launched by a student called Alberto that approached us with a good idea and obtained access to the data.
So, I’d rather have a prefix for ethno projects, for example
Makes complete sense. Please go ahead with that
Open Ethnographer can now do collaborative coding, means the software will propose codes created by anyone working on the same coding project as yourself.
You need to set this up to make it work. See in the manual above under section “6.4. Enabling collaborative coding” and for some more details see the user settings documentation in section “4. Managing codes, annotations and settings”.
Maria and I are talking right now about the consent funnel + procedure for recording and transcribing events. We need to have a call to decide what the protocol is for transcribing events to optimise the SSNA data (from @amelia and @alberto’s perspective) vs the time consumption/difficulty of transcription and allocation of text for @johncoate and @MariaEuler. These are generally on opposite ends of the spectrum (as has been made clear to me by Maria in this call), so we need to agree on protocol going forward. Are people free to do this in the coming weeks? Perhaps next week since PARTENAIRE draft is in Friday.
As long as we can afford to do it, the human transcription service is reasonably fast and pretty accurate. Overall it is less expensive to pay them than it is to pay me to hand edit the audio.
Good to know! This call will be about the way we put the transcriptions themselves on platform once they are done. For the SSNA, having a huge block of text associated to just one person is not good. But there are levels of better, each requiring more labour and participation. We need to decide what’s reasonable to aim for.
@matthias, question. The backend view under “translate” could enable using the backend as a codebook (https://edgeryders.eu/annotator/codes?discourse_tag=ethno-ngi-forward&order=name&view=translate).
Is there an easy way to batch import all the code descriptions that I have in a spreadsheet to get us going? If I have a two column view, one with the codename as it appears in the OE backend and one with the code description?
Check out section 7.3 above — thanks to @matthias, we now have a fully integrated codebook in the backend!! Goodbye Google Sheets and goodbye human error prone duplicating work
Please review this section so you know the new protocol – it’s very straightforward and simple. Once we finish doing our category work merging codes on both NGI and POPREBEL projects, we will use the OE backend exclusively.
We are currently working on the best way to import all the existing codes and definitions, but regardless of method this will happen when we are done with our category and merging work.
Thanks a lot for the updates @matthias and @daniel! These fixes address a lot of the issues we’ve had up to now. It’s also great that we’re moving towards being able to update records without reloading the view, which saves a lot of time when doing ethnography.
I’m not sure if I’m missing something or if I’ve found a bug with the “Translate” view. How is it meant to be used in practice? I think that most of the time the desired functionality will be to search then update, but the Translate view does not seem to show up when searching? If this is a bug I’ll put it on GitHub, just want to make sure I’m not missing anything.
In the list of codes, you’d filter to see those you want and then switch to “View: Translate” in the top right. This is meant as a batch update feature for codes, and filtering for a certain
ethno-… tag oneself as author will give a set of codes to mass update.
It was not designed to be used on search results as when searching you’d find just the one code you’re interested to update, and could do that with the same comfort just in the regular code edit page.
But since the “View: Translate” option exists in the search results view but does nothing right now, you’re welcome to report that as a bug.
Ah got it, since the filtering is preserved when switching the view, that makes sense.
So we’re waiting for the already exisiting definitions to be batch-imported and create new ones in OE as new codes appear, am I correct?
This is done now! There are still a few things to be updated due to ethnographer formatting errors (for example, some codes that were lower case in OE were upper case in the codebooks, so they didn’t auto-import) but that will be updated shortly.
@amelia Can you please tell me, how are we using the star/* before the code names? I can’t find it here in the manual.