This graph is after my coding. Looks interesting!
Re: In-vivo codes. Changed to double quotes now.
Notes after Codebook Category First Pass (for meeting tomorrow):
- Many, many codes need forking (there are too many compound codes that won’t occur more than once or twice).
- Create parent-child relations.
- Too many meaningless invivo codes (only use invivo if they capture something unique and interesting)
- Fix capitalisation (only proper nouns should be capitalised).
- Fix invivo designations (double quote for invivo, single quotes for concepts).
- Be more parsimonious – most of these codes won’t occur multiple times. Think about the SSNA – what will be likely to meaningfully co-occur? This means a) assigning less only slightly different and synonymous codes but also b) assigning more high-value codes that will ultimately co-occur with more concepts, and therefore produce richer codes in interaction with each other. By assigning lots of very specific codes, you miss the opportunity to see the meaningful interactions created by participants.
It might seem counterintuitive that forking codes will lead to more parsimony, but once you fork the codes you’ll see that they then will be mergeable with other codes, creating less codes with more co-occurrences (rather than lots of codes with very few occurrences or co-occurrences).
Tomorrow we’ll make a start on this together and I’ll show you what I mean through examples, and then we can continue the work asynchronously. Please do not code any new threads until this is done and use your hours to do this code refining work — we need to up the code quality before we proliferate more codes.
As a brief example:
Co-code “future” + “internet” rather than creating lots of codes like “future of the internet” “future of technology” “future of everyday life”.
The first approach will give you a semantic web of future + all the concepts related to the future. the second method/process won’t ever show up on the SSNA.
Coding in the former way will also allow you to see the global concepts that you’d miss otherwise — otherwise, the codes won’t show you much about the collective.
1 Like
While you’re making the merges and forks to the codes based on the categories we defined, please also fix any issues you see as you go – spelling errors, lack of definitions, etc.
We have a huge problem right now with duplicate codes due to capitalisation errors. I’ve responded to and marked as important @matthias suggestion on GitHub to automatically merge any codes of the same name of the same case (thank you!), but we can’t do this for codes of a different case as we risk merging codes with different meanings that way. So I need the following:
Using the new “tree” display for speed, go through and make all non-proper nouns lowercase. I’d filter by user @CCS to start out with since it’s mostly those that are in uppercase. Once those codes are in lowercase and we have the automerge function in place, they should then be automatically merged into the other lowercase code, saving us time. This is important so please prioritise it – it shouldn’t take more than an hour. I recommend splitting the alphabet between the two of you. I’ve done a lot already but there’s quite a bit more to go.
Going forward, this is instructive. Please make sure both of you do code review after every coding session and clean your codes — make sure they fit the coding conventions both technically (in terms of case, invivo designation, etc) and semantically (that they aren’t a synonym of existing codes, that they aren’t compound codes, etc). We will save ourselves a lot of headache going forward if we do this while we work instead of trying to go through 1000s of codes retroactively.
Thanks!
1 Like
Just finished this so please disregard.
As I make these changes, I want to reiterate something we discussed in the last meeting we had.
I’m noticing that the coding thus far is very literal but largely not very descriptive. When you code, don’t code for “content”. If a machine could assign the same code as you’re assigning, that’s a good sign that you need to rethink how you’re coding. As an example of this, I’m seeing a lot of invivo codes (where you use the same terminology as the participant) used when the term itself isn’t special, rather than thinking about what they mean and finding the right code to describe that meaning, in line with the codes you’ve used previously if the concept has come up before. See your desire to automatically assign an invivo code as a red flag going forward, and ask yourself if you’re using their exact word because it’s the word that saliently captures the concept (and the one you’ve been using thus far to capture that same concept) or because it’s the easiest thing to do in the moment. We code for meaning — what is the point of what this person is trying to say? What are they trying to get across? What values and worldview are they putting forward?
This means assigning more descriptive codes (like seeking purpose or defining justice or building inclusivity; access and education; complexity and asking experts) rather than codes like limiting or involvement, which have no real meaning. This also helps you not overassign codes or create overly compound or vague codes. @Leonie @katejsim. Think – if the codes I assigned to this post or comment were assembled together by themselves, would the viewer be able to tell the story of what this person is thinking or feeling?
2 Likes
And once you’ve assigned a code for a concept, stay with it (or edit/update it across the corpus). The reason we call our codebook an “ontology” is that it’s more than a list of codes — it’s a compendium of participant meaning. If I call in-person human interaction face-to-face then I need to continue to use that phrase, rather than also assigning codes physical human interaction, real-life contact, and so on.
If I use the connection between the codes built to last and legacy, I need to not then also assign codes longevity and making one's mark or even longevity and legacy to a different story later in the month. You can see that this consistency goes beyond not assigning single codes with the same meaning – it also requires being consistent with the co-occurrences you use to capture when people express the same sentiment (e.g. people expressing that they want to leave something material behind that outlives them, that stands in testament to their memory).
Let’s try really hard going forward to be diligent about our coding practice, because this is the only way those codes will meaningfully capture what our participants are expressing.
1 Like
@Wojt, @Jan @Jirka_Kocian @SZdenek @Richard this applies to POPREBEL too, so please take note of the comments I’ve made in the previous 2 comments on this thread.
1 Like
@amelia: Sorry, I accepted your invitation to the next coding meeting before I checked my diary. I have an online Meet-the-Freshers meeting at the same time. R
1 Like
No worries! We’ll keep track of our progress (all changes will be reflected in the codebook on OE now).
I’ve now updated the Open Ethnographer Manual with this information, so please use it for reference.
Wow, this is gold. 
2 Likes
It’s in the manual now, under “Big Picture” 
2 Likes
@katejsim and @Leonie, I suggest a division of labour until we meet again 21st September.
Based on the above principles, I’d like you two to focus on taking a second pass and recoding the threads that have already been coded, cleaning up and fixing the coding on those threads so they more closely conform to these coding standards.
In the meantime, I will work on coding new threads. My goal is to code at least 14 full threads by our meeting time.
Looking forward to speaking in September, and let me know if you need anything in the meantime.
Morning!
If you need a Zoom link for this afternoon’s meeting, we can use this one: https://zoom.us/j/4149496930
R
1 Like
Hi @katejsim and @Leonie! As we talked about, in order to make sure our codes stay tidy going forward (and we don’t have to do another epic week of 2-3 hour meetings) we will schedule a bi-weekly coding meeting for NGI.
The meeting structure will be straightforward – we will go through all the newly assigned codes since the last meeting (as in, all codes that have been newly created, not ones that have been reused) and make sure they aren’t duplicates of those which came before, as well as making sure we all know how to use them.
This will technically involve us all opening the ethno-NGI codes page and sorting by “newest”. The meetings will be an hour, less if we make it through all the codes. We will also of course open the floor to other questions, comments, and discussions.
Let’s set a recurring day and time for this – I propose 2-3pm on Mondays. Does this work for you all?
Sounds good. Monday 2-3pm works for me.
Sounds Good!
Fab. Calendar invite sent out with zoom link included in the invite.