Skip to main content

open-coding

Use when conducting line-by-line open coding, generating substantive codes, in vivo codes, and initial categories from qualitative data.

الانتقال إلى التثبيت

معلومات المصدر

المستودع
ccashwell/qualitative-research-pro
آخر نشاط في المصدر
١١ أبريل ٢٠٢٦ في ٠٢:١٠
لغة SKILL.md المكتشفة
الإنجليزية
النجوم
٠
التفرعات
٠

خيارات التثبيت

يُحدَّد Prompt الذي يراجع المصدر أولًا بشكل افتراضي. يمكنك التبديل إلى أمر مباشر أو تنزيل نسخة محلية.

مراجعة ملفات المصدر

اقرأ SKILL.md وأي ملفات مرافقة يعرضها SkillsMP قبل أن تقرر التثبيت.

عرض SKILL.md

SKILL.md
تعليمات المصدر · معاينة للقراءة فقط
name
open-coding
description
Use when conducting line-by-line open coding, generating substantive codes, in vivo codes, and initial categories from qualitative data.
# Open Coding (Classic Grounded Theory) Open coding is the **first major analytic move** in classic grounded theory: you fracture qualitative data into **incidents** and label them with **codes** that stand for **conceptual** meanings. The goal is not to summarize paragraphs but to **generate concepts** that can be compared, refined, and later integrated around an emergent **core category**. Use this skill whenever you are beginning analysis, returning to fresh data after a break, or deliberately **re-opening** coding after discovering a better fit. --- ## Purpose and outcomes **Purpose**: Turn raw data into **discrete conceptual indicators** that can enter **constant comparison**. **Typical outputs**: - A working **code list** (codes with short definitions and examples). - **Annotated data** (tags, margin notes, or software-linked segments). - **Memos** capturing hypotheses about meaning, relationships, and puzzles. - **Early categories** (higher-level groupings of codes with properties/dimensions beginning to appear). --- ## Line-by-line and incident-to-incident technique ### Line-by-line (dense passages) For rich narrative segments, move **line by line** (or sentence by sentence) asking: 1. **What is going on here?** (substantive meaning) 2. **What category(ies) does this indicate?** (conceptual label) 3. **What other incidents compare/contrast?** (comparison cue) Do **not** code “the whole paragraph” as one blob unless it truly expresses **one** incident. ### Incident-to-incident comparison An **incident** is a **meaningful chunk** of data that can be compared: an event, action, feeling, statement, turning point, or interactional move. After coding an incident: - Ask: “What is this incident like? Unlike?” - Pull **another incident** (same interview, different interview, different source) and compare at the **conceptual** level. - Refine code definitions when comparisons reveal **properties** (attributes) and **dimensions** (ranges). --- ## Types of codes you will use ### Substantive codes Conceptual labels derived from **what the data is about**. Examples (illustrative only): *shielding credibility*, *deferring decisions*, *patching workflow*. These should be **abstract enough** to travel across interviews, yet **faithful** to data. ### In vivo codes Use participants’ **own terms** when they **condense meaning** powerfully. In vivo codes keep you close to **emic** language while still enabling comparison. **Caution**: Not every catchy phrase is conceptual. If an in vivo term is **too idiosyncratic**, translate it into a **more general** substantive code while preserving the participant language in a memo. ### Gerund coding (“-ing”) Glaser often recommends **gerunds** to keep **process** in view: *managing time*, *containing conflict*, *signaling competence*. This helps you see **action/interaction** rather than static nouns. ### Provisional “hypothesis codes” Early codes that may be wrong are fine. Classic GT **expects** code churn. Rename, split, merge—**document** changes in memos. --- ## Fracturing data (practical moves) - **Break on shifts**: new topic, new actor, new emotion, new tactic, new consequence. - **Break on strong lines**: especially vivid, repeated, or consequential moments. - **Break on comparisons** you can already imagine: “This sounds like X, but also unlike X because…” - **Tag “don’t know yet”**: if unsure, use a temporary label + memo the uncertainty. --- ## Worked example (abbreviated) **Data excerpt (fictional)**: > “I didn’t tell my manager about the side project at first. I needed to see if it would even work. Once it looked real, I scheduled a short chat and framed it as ‘experiment’ not ‘commitment.’” **Possible open codes (illustrative)**: - *delaying disclosure* (substantive) - *probing viability privately* (substantive) - *softening risk framing* (substantive; gerund-friendly: *framing-as-experiment*) - *staging legitimacy* (hypothesis code—might merge/split later) **Comparison prompts**: - Compare to another incident where the participant **disclosed immediately**—what conditions differ? - Compare to an incident of **never disclosing**—what consequences differ? **Memo seed**: > “Hypothesis: disclosure timing is managed through **viability thresholds** + **linguistic risk reduction**. Need more negative cases where disclosure backfired.” --- ## Output format (recommended) ### 1) Code entry template ```text Code name: Definition (1–3 sentences): Inclusion criteria: Exclusion criteria (common confusions): Example incidents (2–3 brief quotes with source IDs): Related codes (merge/split notes): Open questions: ``` ### 2) Session log (audit trail) ```text Date / dataset: Incidents coded (count) + IDs: New codes added: Codes renamed/merged/split (why): Memos written (titles): Next comparison targets: ``` --- ## Quality checks during open coding - **Abstract enough** to compare across cases, **concrete enough** to trace to incidents. - **Avoid laundry lists** of topics; aim for **analytic** codes. - **Memo** whenever you claim a relationship (“because,” “in order to,” “leads to”). - **Seek negative cases** early: incidents that seem to contradict your “favorite” code. --- ## When to move toward selective coding You are **not** finished with open coding in a single week; it matures through comparison. Move toward **selective coding** when: 1. A **core category** candidate **recurs**, **explains** a wide swath of variation, and **connects** many other categories. 2. You can **delimit**: additional open coding feels **redundant** relative to the emerging integrated story. 3. **Theoretical sampling** questions become **targeted** at the core and its related conditions/strategies/consequences. If you move too early, you risk **forcing** a core. If you move too late, you risk **endless sprawl**. Let **comparison + memo sorting** guide the transition. --- ## Common pitfalls - **Paraphrasing** instead of conceptualizing. - **Over-coding** with synonyms; **merge** aggressively after comparison. - **Under-memoing**; losing the trail of theoretical reasoning. - **Theme sorting** without comparison (categories that “sound nice” but don’t explain). - **Premature literature import** that names your phenomenon before you’ve earned concepts. --- ## Key references - Glaser, B. G. (1992). *Basics of grounded theory analysis*. Sociology Press. - Glaser, B. G. (1978). *Theoretical sensitivity*. Sociology Press. - Glaser, B. G. (1998). *Doing grounded theory*. Sociology Press. --- ## Companion skills - `constant-comparison`, `memo-writing`, `theoretical-sensitivity` - `selective-coding` (next major transition) - `glaserian-grounded-theory` (full process map)
عرض على GitHub