Awesome news, @Wojt. I’ll make an integrated sheet for us today so we can all work on it together.
Also your meme made me LOL yesterday when I opened this post 
Glad you’re enjoying the new functions – so am I! Rock on @matthias.
1 Like
Thank you @matthias <3
One thing, though. Now that I chose to see only Jan’s codes in the backend, I can’t see some of my own codes - namely those that were automagically merged with codes by other annotators. Every time I use the code, e.g. “diversity”, since I was not its original creator, it does not appear in my suggestions. It is in our codebook, in the babckend there are our annotations that go with it, but it simply won’t show as a suggestion.
Do you think I should put it onto our wishlist?
Hmm ok I guess I finally understand what you mean by “codes that were automagically merged with codes by other annotators”: when you entered a code that already existed, it was not created another time (this time with you as the creator) but re-used (not changing whoever was the creator before). Nothing is automagically merged, as your own code never existed. You chose to apply somebody else’s code by choosing it from the auto-complete list.
That behavior is intended because the whole application is meant for collaborative coding, so code re-use. The proper solution would be to enter the names of all collaborators in your coding team in the backend under “User Settings → … → Propose codes from users:”. Your team would be the group of people from whom you want to see codes proposed.
The trouble you’re having now is because of the migration from “your team is everyone contributing to the ethnographic project” to “your team is a few users”. To fix this, you’ll have to copy codes containing your annotations where the code does not have you as the author. The copy will have you as the author, and you’ll have to remove the copies of others’ annotations from the copied code and the copies of your own annotations from the original code to prevent redundancy.
On a more general note, I don’t know the purpose of this new feature of proposing codes from selected users. It effectively creates partially overlapping sub-projects inside an ethnographic coding project. Isn’t the whole idea of collaborative coding that inside one ethnographic coding project (such as ethno-poprebel), one single common codebook is used by everyone? (cc @amelia )
1 Like
Here is the spreadsheet we’ll use for the combined categories:
I’ve populated them, but if everyone could go through and familiarise themselves with the sheet and start to mark places for merging, that would be great.
1 Like
Indeed, and this is what we do in NGI and Babel (and what I do in POPREBEL). But @Jan and @Wojt like to assign their codes first and then check that they mean the same things as the other ethnographers, and then do the merge if that is true (rather than checking the codebook while coding before assigning the code). Later down the line, when it’s easy to see both the codes and definitions on the platform while coding, there will be no question that we all check for definitional alignment at the time of code assignment. At the moment, that adds a lot of time, so I’m ok with them doing it the other way and then merging their codes when they check and confirm that they mean the same thing as the other ethnographers. All have committed to being stringent about this merging and doing it regularly – we have a large-scale merging exercise on Thursday to get on the same page, and will make the merging process firm.
I identified that the process you describe (the selection of other people’s codes while coding) was happening on a call with Wojciech rather than anything ‘automagic’ and explained it to him, but he also thought there was an actual ‘automagic’ process going on prior to his setting his user settings to the ethno poprebel tag — @Wojt can you confirm and describe, please, if this is still happening?
Otherwise, I agree with @matthias re your old codes — it’s ideal that they become merged anyway, once we know we mean the same thing, so we need to come up with a process for this (them joining the group codes) which doesn’t make you feel like you’ve lost them. The ideal is that we work toward a shared codebook, not siloed ones, and this should be much easier now that we can filter the codes by ethno poprebel tag.
In NGI, for example, we have one codebook that we all contribute to, not 3 different ones. This wasn’t workable in POPREBEL when we were in vastly different places, but now we need to move toward that shared format, which is in part what we are doing on Thursday. We can discuss the merging procedure then and at that point we can talk with @matthias if we need any kind of solution to the issue you’re putting forward, @Wojt. My hope is that once we merge codes on Thurs we also create a unified codebook that we use from here on out (and that we will all ultimately spend more time on the POPREBEL codes list than our own!) Of course to do this, we need to establish a clear process together 
1 Like
@matthias @amelia
As far as I remember the issue was indeed there.
For now blessed be your explanation and suggestion for a possible way of fixing the issue raised, @matthias!.
(And I used the word “merging” because the result was or seemed identical to the result of using the merge function)
I rest my case.
For good it seems.
Thanks again!
That will solve some of the issues, I think.
Just a technical question, though: I’m wondering if this shared codebook is going to have tabs for translations or will it be English only?
Translations too, for sure!
Ok @amelia @matthias , I still don’t get why my code “tourism” got “merged” with Nermine’s, not Zdenek’s or Inga’s. Judging by the codes’ Ids Inga’s was chronologically first.
Now I had no suggestion for it during coding since I chose to see only Jan’s codes.
It’s still kinda magical to me.
This happened even though you were set to only see POPREBEL / jan’s codes? Definitely an issue then.
Right? And, like I said, it happened before, when no suggestions appeared.
Is it possible that you or Jan had already selected this code previously, so it would show up as suggested for you since you’d used it before siloing, even though Nermine was the original author?
2020-08-06T13:00:00Z → 2020-08-06T14:30:00Z
Call Agenda Today
Expected Attendees: @amelia @Jan @Wojt @Jirka_Kocian @SZdenek and likely @alberto
Big Picture/Goal: Create systems and merge codes to improve intercoder reliability and collective approach to coding.
1_OE Update (GitHub process and new features) + Shared Codebook Goal (10 minutes)
See open issues and resolved issues here.
Important highlights
-
We can now see a list of codes by ethno-poprebel tag, so we can generate a list of all of our codes. Use this view as frequently as the view of your own codes so we maintain a project-wide view of the corpus.
-
Code merges now happen from the page of the code you want to merge, so navigate to the code you want to get rid of, not the code you want to keep, to implement the merge (from a UX perspective, this is much better). Merging a code now keeps its parent intact.
-
All annotations of the child codes are automatically also assigned to the parent code, and are visibly different in the backend. This also means that to remove the annotations of the child from the parent, all we have to do is unparent the code. We need to figure out if this is implemented in GraphRyder.
-
We can now group users so that @Jan and @Wojt only see each others’ codes as suggestions, as requested. If we do this, we need to be highly dilligent about consistently merging codes, on a weekly basis at minimum (but ideally after every batch of coding). I can explain my process and see if others think they’d want to adopt it — it allows for me to keep my view at project level without losing the codes I assigned (by sorting by ‘new’ while also logging my codes in the codebook immediately). A shared codebook should also massively help with this, ensuring that one tab is chronological, one is alphabetical, and then one is a category tab (with as many additional as people want as sandbox areas).
-
Your default code list view is now your own, which should make backend work easier and less tedious.
2 _Hierarchy vs Category Discussion (10 minutes)
- We have decided against allowing multiple parents for one child code in the backend, for both computational reasons and organisational reasons. We need to keep distinguishing clearly between hierarchies (which are strict and ontological) vs categories (which are looser and more for the ethnographers’ mental models). To implement a hierarchy, the code must always, regardless of context, belong under that parent code. This requires more careful attention to meaning in use, because a lot of the examples we have of parent-child relationships don’t hold everywhere (e.g. the Pope is not always an “influential figure” to all informants, and so isn’t a strict child of it).
3_Merging codes (1 hour)
Procedure: One member of each language team has their codebook open and is in charge of codebook changes. The other member has the Open Ethnographer backend open and is in charge of code merges. Please decide who is who before the meeting!
4_Merging codebooks (10 minutes)
We will create a procedure for this and if there is no time remaining, do it asynchronously.
Because codes are identified not just by their name, but by their full path. To code with Inga’s code, you’d have to enter or select “spotTheFuture → assets → tourism” in the annotation popup. Nermine’s “tourism” code is the first code indeed named just “tourism”.
That said, I think two codes with exactly the same name and path (like here “tourism” and “tourism”) are not supposed to exist. I recorded that now as issue #172.
That’s another issue: if the code is not in the suggestions but already exists, what should happen?
1 Like
We can use my zoom:
Topic: Zdeněk Sloboda’s Personal Meeting Room
Join Zoom Meeting
Meeting ID: 457 123 1537
Passcode: 3xtFdY
1 Like
Hmm…define “should”
As you wrote earlier, the annotations I make will just be assigned to the already existing code. I’d rather it didn’t happen since I don’t really know if the person who created it had the same idea about, say, “social support”.
Besides, if I later decide to change the code’s name, and my annotations are already there, I’ll probably have to, as you suggested, copy the code and assign my coded fragments to that copy and then rename it. Am I right?
-
What is the goal of our work/coding? For coding and building codebooks we need to keep in mind the goal of the project: “why do people like (or not) right-wing populists”? What features of people or conditions of the world are associated with the higher or lower levels of support for (right-wing) populists?
-
Historical ideas, as a separate category. So, break down historical-political (so, political ideas/ideologies are “on their own”)?
Also: maybe “History” + subcategories?
-
Socioeconomic: how is it understood: Social OR Economic or social AND economic topics (Boolean sum or multiplication?
-
Maybe move our housing-related codes (in Socioeconomic category) to housing
-
People->homosexuality - includes homosexuals, should we keep them separate, or is it unnecessary proliferation?
-
In the codebook - can we have certain codes appear under more than one category?
Would be great if we could, later, if possible, if we are able to create more than one parent in hierarchies that will facilitate the p;rocess.
-
Freedom - emotion, value, political? All?
-
Explain again versus single and double quotes rule, please.
-
Maybe change the name of the category Community to Sociability?
-
Hey, Amelia, why put “debt” under Labour?
-
Czech’s time perspective - merge with our History?
-
Create a new general category: Identity
-
A new code “urban-rural comparison”? (this is important from the point of view of our project goals.
@matthias @alberto the backend functionality is down (it looks like an HTML page and the merge function isn’t accessible). can you advise? We are on a coding call for merging so it’s urgent. Thank you!
Yeah 
Daniel is repairing things since four hours already, still could not find the error. You probably have to re-schedule your call, I believe. For these calls, demos, or other critical times when you want to have a guarantee that Open Ethnographer works, in the future please tell @daniel about the start and end time.
Things broke today while Daniel was deploying a new version of Open Ethnographer. He’s testing changes locally first, so usually this does not happen (and it’s the first time it happened to Open Ethnographer, to my knowledge). In this case, the deployment relied on a feature that had been broken on edgeryders.eu for months already, without anyone noticing because it was not used during that time.