📗 Open Ethnographer Manual

[alberto]

I think @amelia has a timetable in mind. But yes, I can’t imagine it would be a big thing. A week.

[amelia]

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.

[amelia]

And as if by magic she responded we are good to start.

[matthias]

@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.

• #89 Highlight own Open Ethnographer annotations when viewing a topic. @amelia specifically asked for this one some time back.

• #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.

[alberto]

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…

[matthias]

For the discussion how the Discourse tags to mark Open Ethnographer projects should look like:

The 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 project-opencare-oe-selection either.

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?

[alberto]

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 ethno-PROJECTNAME.

[matthias]

Makes complete sense. Please go ahead with that

[matthias]

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”.

(This is an announcement to everyone whom I did not announce this to already … that would be: @alberto @CCS @DrSeanHanley @johncoate @leonie @MariaEuler.)

[amelia]

@alberto @MariaEuler @johncoate @nadia

@community_wiki

For audio-recorded events and interviews:
(See the Consent Process Manual for the ethical framework)

1. Each participant of the event creates an account and posts their inputs as comments (difficult, but ideal).
2. ER member transcribes the audio event, creates different accounts to represent each speaker (with permission, and pseudonymised), and posts their contributions as separate contributions.
3. ER member transcribes the audio event and ethnographers code that transcription.
4. Ethnographer codes the event audio directly using the audio coding function described in Sections 3.3 and 3.4. This is not ideal unless the event is audiovisual and the visual elements are themselves significant (e.g. there is action going on besides just speakers talking, and that action is meaningful ethnographically).

For field notes and event notes:

1. As much as possible, have participants themselves write their reflections on the platform by making an account and writing a post.
2. Import ethnographer field notes as different posts and comments attached to pseudonym accounts based on different participants’ contributions/reflections, to capture them as different people for SSNA.
3. ER member (community manager, ethnographer) posts field and/or event notes to platform in text form so they can be coded.

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.

[johncoate]

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.

[amelia]

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.

[amelia]

@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?

[amelia]

Calling all ethnographers:
@Jan @Wojt @Richard @Jirka_Kocian @SZdenek
@Leonie @katejsim
@MariaEuler

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.

Woohoo!

[hugi]

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.

[matthias]

@hugi

the “Translate” view. How is it meant to be used in practice?

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.

[hugi]

@matthias

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.

Ah got it, since the filtering is preserved when switching the view, that makes sense.

[Wojt]

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?

[amelia]

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.

[SZdenek]

@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.