diff --git a/README.md b/README.md
index f706b05..cf47617 100644
--- a/README.md
+++ b/README.md
@@ -72,6 +72,7 @@ See [Prerequisites Guide](docs/PREREQUISITES.md) for detailed installation instr
- π [Getting Started Guide](GETTING_STARTED.md) - Comprehensive setup and usage
- π§ [Prerequisites](docs/PREREQUISITES.md) - Installation and system requirements
- π [Troubleshooting](docs/TROUBLESHOOTING.md) - Common issues and solutions
+- π€ [Collaboration Guide](docs/COLLABORATION_GUIDE.md) - Working with non-technical collaborators
## Versioning
diff --git a/docs/COLLABORATION_GUIDE.md b/docs/COLLABORATION_GUIDE.md
new file mode 100644
index 0000000..44b1256
--- /dev/null
+++ b/docs/COLLABORATION_GUIDE.md
@@ -0,0 +1,7415 @@
+# Collaborating with Non-Technical Co-Authors
+
+Welcome! This guide helps you collaborate effectively with co-authors who use Microsoft Word instead of git and markdown. Whether you're working with advisors, domain experts, or research collaborators, this guide provides practical workflows for seamlessly incorporating their feedback into your Quarto-based research papers.
+
+---
+
+## π Overview
+
+One of the most common challenges when using Quarto for academic writing is collaborating with co-authors who prefer traditional tools like Microsoft Word. This guide solves that problem by providing:
+
+- **Word Export Workflows**: Convert your Quarto documents to fully-formatted Word files with preserved citations and formatting
+- **Track Changes Integration**: Handle Word's tracked changes and comments systematically
+- **Feedback Incorporation**: Merge edits from Word documents back into your markdown source
+- **Multi-Collaborator Management**: Organize and consolidate feedback from multiple reviewers
+- **Version Comparison**: Track what changed between versions using diff tools
+- **Platform-Specific Tips**: Instructions for macOS, Windows, and Linux
+
+This workflow is designed to be **practical and efficient**βyou maintain your source in markdown/Quarto while enabling collaborators to work in their preferred environment.
+
+---
+
+## π Table of Contents
+
+1. [Exporting to Microsoft Word](#1-exporting-to-microsoft-word)
+ - [Configuring Quarto for Word Export](#configuring-quarto-for-word-export)
+ - [Running the Export](#running-the-export)
+ - [What Gets Preserved](#what-gets-preserved)
+ - [Formatting Tips](#formatting-tips)
+
+2. [Sending to Collaborators](#2-sending-to-collaborators)
+ - [Preparing the Document](#preparing-the-document)
+ - [Communication Best Practices](#communication-best-practices)
+ - [Setting Expectations](#setting-expectations)
+
+3. [Importing Feedback from Word](#3-importing-feedback-from-word)
+ - [Understanding Tracked Changes](#understanding-tracked-changes)
+ - [Accepting/Rejecting Changes in Word](#acceptingrejecting-changes-in-word)
+ - [Converting Back to Markdown](#converting-back-to-markdown)
+ - [Manual Merge Strategies](#manual-merge-strategies)
+
+4. [Managing Multiple Collaborators](#4-managing-multiple-collaborators)
+ - [Version Naming Conventions](#version-naming-conventions)
+ - [Feedback Consolidation Workflow](#feedback-consolidation-workflow)
+ - [Git Branching for Reviews](#git-branching-for-reviews)
+ - [Handling Conflicting Feedback](#handling-conflicting-feedback)
+
+5. [Comparing Versions and Tracking Changes](#5-comparing-versions-and-tracking-changes)
+ - [Using Git Diff for Markdown](#using-git-diff-for-markdown)
+ - [Word's Compare Documents Feature](#words-compare-documents-feature)
+ - [Visual Diff Tools](#visual-diff-tools)
+ - [Command-Line Comparison](#command-line-comparison)
+
+6. [Practical Examples and Workflows](#6-practical-examples-and-workflows)
+ - [Example 1: PhD Student and Advisor](#example-1-phd-student-and-advisor)
+ - [Example 2: Research Team with Multiple Reviewers](#example-2-research-team-with-multiple-reviewers)
+ - [Example 3: Handling Conflicting Suggestions](#example-3-handling-conflicting-suggestions)
+ - [Quick Reference Commands](#quick-reference-commands)
+
+7. [Platform-Specific Instructions](#7-platform-specific-instructions)
+ - [macOS](#macos)
+ - [Windows](#windows)
+ - [Linux](#linux)
+
+8. [Troubleshooting Common Issues](#8-troubleshooting-common-issues)
+ - [Citations Not Rendering in Word](#citations-not-rendering-in-word)
+ - [Formatting Lost During Export](#formatting-lost-during-export)
+ - [Merge Conflicts](#merge-conflicts)
+ - [Large Files and Performance](#large-files-and-performance)
+
+9. [Best Practices and Tips](#9-best-practices-and-tips)
+ - [When to Use This Workflow](#when-to-use-this-workflow)
+ - [Communication Strategies](#communication-strategies)
+ - [Maintaining Quality Control](#maintaining-quality-control)
+
+---
+
+## 1. Exporting to Microsoft Word
+
+### Configuring Quarto for Word Export
+
+Quarto can export your research paper to Microsoft Word format (`.docx`) with citations, formatting, and structure preserved. To enable Word export, you need to add the `docx` format to your project's `_quarto.yml` configuration file.
+
+**Step 1: Open your project's configuration**
+
+Navigate to your research paper directory and open `_quarto.yml`:
+
+```bash
+cd research_paper
+# Open _quarto.yml in your preferred editor
+```
+
+**Step 2: Add the docx format**
+
+In the `format:` section of `_quarto.yml`, add a `docx:` subsection alongside your existing formats (like `html:` and `pdf:`). Here's an example configuration:
+
+```yaml
+format:
+ html:
+ toc: true
+ theme: cosmo
+ pdf:
+ documentclass: report
+ toc: true
+ number-sections: true
+ docx:
+ toc: true
+ number-sections: true
+ highlight-style: github
+ reference-doc: custom-reference.docx # Optional: use a custom Word template
+```
+
+**Key docx format options:**
+
+- `toc: true` - Includes a table of contents
+- `number-sections: true` - Automatically numbers headings (1, 1.1, 1.2, etc.)
+- `highlight-style: github` - Syntax highlighting style for code blocks
+- `reference-doc: custom-reference.docx` - (Optional) Use a custom Word template for styling
+- `fig-width: 6.5` - Default width for figures in inches
+- `fig-height: 4.5` - Default height for figures in inches
+
+**Step 3: Save the configuration**
+
+Save your changes to `_quarto.yml`. Your project is now configured to export to Word format.
+
+> **Tip**: If you want to customize the styling of your Word exports (fonts, heading styles, margins), create a custom reference document. See [Quarto's documentation](https://quarto.org/docs/output-formats/ms-word.html#custom-styles) for details.
+
+### Running the Export
+
+Once your project is configured for Word export, rendering to `.docx` is straightforward.
+
+**From the command line:**
+
+Navigate to your research paper directory and run:
+
+```bash
+cd research_paper
+quarto render --to docx
+```
+
+This command:
+1. Processes all `.qmd` (Quarto markdown) files
+2. Resolves citations from your bibliography
+3. Generates a Word document with proper formatting
+4. Saves the output to the `_book/` directory
+
+**Output location:**
+
+The generated Word file will be located at:
+
+```
+research_paper/_book/Research-Paper-Title.docx
+```
+
+The filename is derived from the `title:` field in your `_quarto.yml` file, with spaces replaced by hyphens.
+
+**Rendering options:**
+
+```bash
+# Render only to Word format
+quarto render --to docx
+
+# Render to all configured formats (HTML, PDF, Word)
+quarto render
+
+# Render a specific chapter only
+quarto render chapters/introduction.qmd --to docx
+```
+
+**Verifying the export:**
+
+After rendering, check that the file was created:
+
+```bash
+ls -lh _book/*.docx
+```
+
+You should see output similar to:
+
+```
+-rw-r--r-- 1 user staff 245K Jan 24 10:30 _book/Research-Paper-Title.docx
+```
+
+### What Gets Preserved
+
+Quarto does an excellent job of preserving most document elements when exporting to Word. Here's what you can expect:
+
+**β
Fully Preserved:**
+
+- **Text formatting**: Bold, italic, underline, strikethrough
+- **Headings**: All heading levels (H1-H6) with proper hierarchy
+- **Lists**: Ordered (numbered) and unordered (bulleted) lists, including nested lists
+- **Links**: Hyperlinks and cross-references
+- **Citations**: Bibliography entries rendered in your specified citation style (e.g., IEEE, APA)
+- **Tables**: Table structure, borders, and content
+- **Images**: Embedded figures with captions
+- **Footnotes**: Rendered at the bottom of pages
+- **Code blocks**: Syntax-highlighted code with proper formatting
+- **Mathematical equations**: Converted to Word's native equation format
+- **Section numbering**: If enabled in your configuration
+
+**β οΈ Partially Preserved (May Require Adjustment):**
+
+- **Complex tables**: Tables with merged cells or advanced formatting may need manual adjustment
+- **Custom CSS/styling**: HTML-specific styling doesn't translate directly to Word
+- **Page breaks**: Automatic page breaks may differ from PDF output
+- **Margins and spacing**: May require tweaking in Word after export
+
+**β Not Preserved:**
+
+- **Interactive elements**: Features like collapsible sections or interactive plots (HTML-only)
+- **Custom Lua filters**: Quarto extensions that modify rendering behavior
+- **Mermaid diagrams**: May need to be exported as images separately (or use `mermaid-format: png`)
+
+**Citations and Bibliography:**
+
+Quarto processes your citations during rendering, so they appear as formatted text in the Word document (e.g., "[1]" or "(Smith et al., 2023)"). The bibliography is included as a formatted references section at the end of the document.
+
+> **Note**: Citations in the Word document are **not** linked to a citation manager like Zotero or Mendeley. They are rendered as plain text based on your `.bib` file and CSL style.
+
+### Formatting Tips
+
+Follow these best practices to ensure your Word exports look professional and require minimal post-export adjustments:
+
+#### 1. Use Semantic Markdown
+
+Write clean, semantic markdown instead of relying on custom HTML or CSS:
+
+```markdown
+# Good: Semantic markdown
+**Key Finding**: This is important.
+
+# Avoid: Custom HTML (doesn't export well)
+Key Finding: This is important.
+```
+
+#### 2. Leverage Quarto's Cross-References
+
+Use Quarto's built-in cross-referencing instead of manual numbering:
+
+```markdown
+# Good: Automatic cross-reference
+See @fig-results for details.
+
+{#fig-results}
+
+# Avoid: Manual numbering
+See Figure 3 for details.
+
+
+```
+
+#### 3. Use Reference Styles for Consistency
+
+Create a custom Word reference document to control styling:
+
+```bash
+# Generate a reference document
+quarto pandoc -o custom-reference.docx --print-default-data-file reference.docx
+```
+
+Edit `custom-reference.docx` to set your preferred fonts, colors, and heading styles, then reference it in `_quarto.yml`:
+
+```yaml
+format:
+ docx:
+ reference-doc: custom-reference.docx
+```
+
+#### 4. Optimize Images for Word
+
+Use appropriate image formats and sizes:
+
+```markdown
+# Specify image dimensions in your markdown
+{width=6.5in}
+
+# Or set defaults in _quarto.yml
+format:
+ docx:
+ fig-width: 6.5
+ fig-height: 4.5
+```
+
+**Recommended formats:**
+- **Photos/screenshots**: PNG or JPEG
+- **Diagrams/charts**: PNG with transparent backgrounds
+- **Vector graphics**: SVG (will be converted to PNG automatically)
+
+#### 5. Handle Tables Carefully
+
+For complex tables, use simple markdown tables or Quarto's table features:
+
+```markdown
+| Algorithm | Accuracy | Runtime |
+|-----------|----------|---------|
+| Method A | 94.2% | 1.2s |
+| Method B | 96.8% | 2.4s |
+
+: Comparison of Methods {#tbl-comparison}
+```
+
+For advanced tables, consider creating them directly in Word after export.
+
+#### 6. Test Your Export Early and Often
+
+Don't wait until your paper is complete to test Word export:
+
+```bash
+# Render to Word frequently during writing
+quarto render --to docx
+```
+
+This helps you catch formatting issues early and adjust your markdown accordingly.
+
+#### 7. Use Page Breaks Strategically
+
+Force page breaks where needed:
+
+```markdown
+# Introduction
+
+Content here...
+
+{{< pagebreak >}}
+
+# Background
+
+Content here...
+```
+
+#### 8. Keep Citations Clean
+
+Ensure your `.bib` file is well-formatted and complete:
+
+```bibtex
+@article{smith2023,
+ author = {Smith, John and Doe, Jane},
+ title = {Example Research Paper},
+ journal = {Journal of Examples},
+ year = {2023},
+ volume = {10},
+ pages = {123--145}
+}
+```
+
+Incomplete entries may cause rendering issues or poorly formatted citations.
+
+---
+
+## 2. Sending to Collaborators
+
+### Preparing the Document
+
+Before sending your Word document to collaborators, take a few minutes to prepare it properly. This ensures a smooth review process and reduces back-and-forth communication.
+
+**Step 1: Generate a clean export**
+
+Render your latest changes to Word format:
+
+```bash
+cd research_paper
+quarto render --to docx
+```
+
+**Step 2: Review the document yourself**
+
+Open the generated `.docx` file and do a quick quality check:
+
+```bash
+# macOS
+open _book/Research-Paper-Title.docx
+
+# Linux
+xdg-open _book/Research-Paper-Title.docx
+
+# Windows
+start _book/Research-Paper-Title.docx
+```
+
+**Check for:**
+- β
All sections are present and in the correct order
+- β
Citations are properly formatted
+- β
Figures and tables display correctly with captions
+- β
Headings follow a logical hierarchy
+- β
Page breaks are reasonable (adjust with `{{< pagebreak >}}` if needed)
+- β
No rendering artifacts or formatting glitches
+
+**Step 3: Enable Track Changes**
+
+Before sending, enable Track Changes in Word so collaborators can easily mark their edits:
+
+**In Microsoft Word:**
+1. Open the document
+2. Go to **Review** β **Track Changes**
+3. Ensure it's enabled (button should be highlighted)
+4. Save the document
+
+**Step 4: Use a clear filename**
+
+Rename the file with a descriptive version identifier:
+
+```bash
+# Navigate to the output directory
+cd research_paper/_book
+
+# Rename with version and date
+mv Research-Paper-Title.docx "Paper-v1.0-for-review-2026-01-24.docx"
+
+# Or create a copy for versioning
+cp Research-Paper-Title.docx "Paper-v1.0-Dr-Smith-review.docx"
+```
+
+**Recommended naming conventions:**
+- `Paper-v1.0-for-review-YYYY-MM-DD.docx` - General review
+- `Paper-v1.0-DrSmith-review.docx` - Reviewer-specific copy
+- `Paper-draft-intro-feedback.docx` - Section-specific feedback
+
+**Step 5: Create a review checklist (optional but helpful)**
+
+Add a brief note at the top of the document or in an email outlining what you'd like reviewed:
+
+**Example checklist:**
+```
+REVIEW REQUESTED:
+[ ] Overall structure and flow
+[ ] Technical accuracy (especially Sections 3-4)
+[ ] Clarity of explanations
+[ ] Grammar and style
+[ ] Figures and captions
+[ ] Conclusion and future work
+
+Please use Track Changes for all edits.
+Target return date: February 7, 2026
+```
+
+### Communication Best Practices
+
+Effective communication with non-technical collaborators ensures a smooth review process. Follow these guidelines to set clear expectations and make the workflow efficient for everyone.
+
+#### 1. Set Clear Deadlines
+
+Be explicit about when you need feedback:
+
+**Example email:**
+
+> Subject: Research Paper Draft for Review - Deadline Feb 7
+>
+> Hi Dr. Smith,
+>
+> I've attached the latest draft of our paper for your review. I'd greatly appreciate your feedback, particularly on:
+> - Technical accuracy of the methodology (Section 3)
+> - Clarity of the results section (Section 4)
+> - Overall conclusions and implications
+>
+> **Deadline**: Please return your comments by **February 7, 2026** so I can incorporate them before the conference submission deadline (Feb 15).
+>
+> **How to provide feedback**: Please use Track Changes in Word to mark any edits, and add comments for broader suggestions or questions.
+>
+> Thank you!
+
+#### 2. Provide Context
+
+Help your collaborators understand where this draft fits in the overall timeline:
+
+- **First draft**: "This is a rough first draft focusing on structure. Don't worry about polishing yet."
+- **Revision**: "This addresses your previous comments. Please focus on Sections 3-4 which were heavily revised."
+- **Final review**: "This is our final draft before submission. Please focus on critical issues only."
+
+#### 3. Specify What Kind of Feedback You Need
+
+Be explicit about the type of review you're requesting:
+
+**Content review:**
+> "Please focus on technical accuracy, argumentation, and whether the conclusions are well-supported."
+
+**Style and clarity review:**
+> "The content is solidβI'm looking for feedback on readability, grammar, and whether explanations are clear to a general audience."
+
+**Final proofread:**
+> "This is our final version. Please catch any typos, citation errors, or formatting issues."
+
+#### 4. Explain Your Workflow (Once)
+
+For collaborators new to your workflow, send a brief explanation:
+
+> **About Our Workflow**
+>
+> I use Quarto (a modern publishing system) to write the paper in plain text with version control. This lets me track every change and manage citations automatically.
+>
+> For your review, I've exported the paper to Word so you can use Track Changes and comments. Once you return it, I'll merge your edits back into my source files.
+>
+> This workflow gives you the familiar Word interface while giving me powerful version control behind the scenes.
+
+#### 5. Use Email Subject Lines Effectively
+
+Make it easy to track versions and reviews:
+
+```
+β
Good subject lines:
+- "Paper Draft v1.0 - Review by Feb 7"
+- "Revised Paper (addressing your comments) - Quick check requested"
+- "Final Paper for Submission - Proofread needed"
+
+β Vague subject lines:
+- "Paper"
+- "Draft"
+- "Can you review this?"
+```
+
+#### 6. Follow Up Appropriately
+
+If you don't hear back by the deadline:
+
+**First follow-up** (1-2 days after deadline):
+> "Hi Dr. Smith, just following up on the paper draft I sent last week. Have you had a chance to review it? The submission deadline is approaching on Feb 15. Please let me know if you need more time or if I can help prioritize specific sections."
+
+**Second follow-up** (if urgent):
+> "Hi Dr. Smith, as we're very close to the deadline, would it be possible to get your feedback by EOD tomorrow? If time is tight, even high-level comments on the methodology and conclusions would be incredibly helpful."
+
+#### 7. Thank Your Collaborators
+
+Always acknowledge and thank reviewers for their time:
+
+> "Thank you so much for your detailed feedback! Your suggestions on the methodology section really strengthened the argument. I've incorporated all your changes and addressed your commentsβI'll send you the revised version tomorrow."
+
+### Setting Expectations
+
+Managing expectations upfront prevents misunderstandings and ensures a smooth collaboration. Here's what to communicate to your collaborators:
+
+#### What Collaborators Should Know
+
+**1. How to provide feedback:**
+
+```
+Please use Microsoft Word's Track Changes feature:
+- Review tab β Track Changes β Enable
+- Make edits directly in the document (they'll be tracked)
+- Add comments for questions or broader suggestions
+- Save the document and return it via email
+```
+
+**2. What will happen to their feedback:**
+
+```
+What happens next:
+1. I'll review your tracked changes in Word
+2. I'll merge accepted changes back into my markdown source files
+3. I'll regenerate the PDF and Word versions
+4. If needed, I'll send you a revised version for another round
+
+Your edits will be preserved in my version control system (git),
+so we have a complete history of all changes.
+```
+
+**3. File format and compatibility:**
+
+```
+The attached file is in .docx format (Microsoft Word 2010+).
+It should open in:
+- Microsoft Word (Windows/Mac)
+- Google Docs (upload to Google Drive)
+- LibreOffice Writer (free, open-source)
+- Apple Pages (Mac)
+
+If you have trouble opening it, please let me know and I can
+send a PDF for comments instead.
+```
+
+**4. Timeline expectations:**
+
+```
+Timeline:
+- Review deadline: February 7, 2026
+- My revision: February 8-10
+- Final version: February 12
+- Submission: February 15
+
+Please let me know if this timeline doesn't work for you.
+```
+
+#### Common Questions and Answers
+
+Prepare for these common questions from collaborators:
+
+**Q: "Can I edit the document directly, or should I only use comments?"**
+
+A: Please edit directly using Track Changes! I can see exactly what you changed and easily accept or reject each edit. Use comments for questions or suggestions that require discussion.
+
+---
+
+**Q: "I made extensive changes. Should I return the whole document or just notes?"**
+
+A: Please return the whole document with Track Changes enabled. This makes it much easier for me to see your edits in context and merge them back into my source files.
+
+---
+
+**Q: "What if I disagree with something but I'm not sure how to fix it?"**
+
+A: Add a comment highlighting the issue and explaining your concern. For example: "This explanation is unclearβcan you elaborate on how X relates to Y?" I'll revise it and send you an updated version.
+
+---
+
+**Q: "Can I share this draft with someone else for feedback?"**
+
+A: [Choose your policy]
+- "Yes, please feel free to share with [specific people]."
+- "Please check with me first before sharing outside our core team."
+- "This is confidential until we submitβplease don't share yet."
+
+---
+
+**Q: "Do I need to fix citations or formatting?"**
+
+A: No need! Citations and formatting are managed automatically by my publishing system. Focus on content, clarity, and accuracy. I'll handle the technical details.
+
+---
+
+**Q: "I prefer to print and mark up by hand. Is that okay?"**
+
+A: Of course! If you prefer to annotate a printed copy, please:
+1. Mark your changes clearly
+2. Scan or photograph the annotated pages
+3. Send them to meβI'll transcribe your edits
+
+Alternatively, I can set up a quick call to go through your feedback together.
+
+---
+
+#### Document Your Workflow
+
+For frequent collaborators, create a short reference document (1 page) explaining your workflow and how they can help. Include:
+
+1. **How you write**: Brief explanation of Quarto/markdown
+2. **How to review**: Instructions for Track Changes
+3. **How to ask questions**: Use comments in Word
+4. **Timeline**: Typical review cycles
+5. **Contact**: How to reach you with questions
+
+Save this as `Collaboration-Workflow-Reference.pdf` and attach it to your first email with a collaborator.
+
+**Example snippet:**
+
+> **How We Collaborate on Papers**
+>
+> I write papers using Quarto (a publishing system) which gives us version control and automated citations. For your review, I export to Word so you can use familiar tools.
+>
+> **Your part**: Review the Word document with Track Changes enabled
+> **My part**: Merge your edits back into my source files
+> **Benefit**: You use Word, I use version controlβeveryone's happy!
+>
+> Questions? Email me or let's schedule a quick call.
+
+---
+
+By following these practices, you'll create a professional, efficient workflow that respects your collaborators' time and preferred tools while maintaining control over your source files and version history.
+
+---
+
+## 3. Importing Feedback from Word
+
+Once your collaborators return the Word document with tracked changes and comments, you'll need to incorporate their feedback back into your markdown source files. This section covers the complete workflow for reviewing changes, converting them back to markdown, and handling edge cases.
+
+### Understanding Tracked Changes
+
+Microsoft Word's Track Changes feature records all edits made to a document, including insertions, deletions, formatting changes, and comments. Understanding how these changes are stored and displayed is essential for efficiently reviewing and incorporating feedback.
+
+#### What Are Tracked Changes?
+
+When Track Changes is enabled in Word, every modification is recorded with:
+
+- **Who made the change**: Author name (from Word's user settings)
+- **When it was made**: Timestamp of the edit
+- **Type of change**:
+ - **Insertion**: New text added (usually underlined or in color)
+ - **Deletion**: Text removed (usually struck through)
+ - **Formatting**: Style or formatting changes (e.g., bold, italic)
+ - **Comment**: Annotations attached to specific text
+
+**Visual appearance:**
+
+```
+Original text: "The algorithm achieves 85% accuracy."
+
+With tracked changes:
+- Insertion: "The algorithm achieves 85% 92% accuracy."
+ ^^^^
+ (underlined, colored)
+- Deletion: "The algorithm achieves 85% accuracy."
+ ^^^
+ (struck through)
+- Comment: "The algorithm achieves 85% accuracy." [Comment: "Can we add confidence intervals?"]
+```
+
+#### Viewing Tracked Changes
+
+**In Microsoft Word:**
+
+1. **Open the document** with tracked changes
+2. **Review tab** β **Display for Review** dropdown
+3. Choose your view mode:
+ - **All Markup**: Shows all changes inline (recommended for review)
+ - **Simple Markup**: Shows changes with a red sidebar (cleaner view)
+ - **No Markup**: Shows the document as if all changes were accepted (preview)
+ - **Original**: Shows the document before any changes
+
+**Recommended workflow:**
+- Start with **All Markup** to see everything
+- Use **No Markup** to preview the final result
+- Use **Original** to compare against your starting point
+
+#### Types of Feedback You'll Encounter
+
+**1. Direct Text Edits (Tracked Changes)**
+
+Simple insertions and deletions:
+```
+- "machine learning" β "deep learning" (deletion + insertion)
+- Added sentence: "This approach reduces training time by 40%."
+- Removed paragraph: [entire paragraph struck through]
+```
+
+**2. Comments and Suggestions**
+
+Questions or discussion points:
+```
+[Comment on "Results section"]: "Can you add statistical significance tests here?"
+[Comment on "Figure 3"]: "Consider adding error bars to this plot"
+```
+
+**3. Formatting Changes**
+
+Style modifications (less common in academic writing):
+```
+- Bold added to key terms
+- Heading level changed (H2 β H3)
+- List formatting adjusted
+```
+
+#### Navigating Tracked Changes Efficiently
+
+**Keyboard shortcuts (Microsoft Word):**
+
+- **Next change**: `Ctrl+Shift+>` (Windows) / `Cmd+Shift+>` (Mac)
+- **Previous change**: `Ctrl+Shift+<` (Windows) / `Cmd+Shift+<` (Mac)
+- **Accept change**: `Ctrl+Shift+=` (Windows) / `Cmd+Shift+=` (Mac)
+- **Reject change**: `Ctrl+Shift+-` (Windows) / `Cmd+Shift+-` (Mac)
+
+**Review panel:**
+
+The Review Panel (right sidebar in Word) shows:
+- List of all changes in order
+- Comments attached to specific locations
+- Revision history details
+
+**Pro tip:** Use the Review Panel to get an overview of all changes before diving into detailed review.
+
+### Accepting/Rejecting Changes in Word
+
+Before converting your feedback back to markdown, it's often easiest to review and accept/reject changes directly in Microsoft Word. This gives you a visual interface and lets you make decisions quickly.
+
+#### Step-by-Step Review Process
+
+**Step 1: Open the returned document**
+
+```bash
+# macOS
+open Paper-v1.0-DrSmith-review-RETURNED.docx
+
+# Linux
+xdg-open Paper-v1.0-DrSmith-review-RETURNED.docx
+
+# Windows
+start Paper-v1.0-DrSmith-review-RETURNED.docx
+```
+
+**Step 2: Enable Review Mode**
+
+1. Go to the **Review** tab
+2. Set **Display for Review** to **All Markup**
+3. Open the **Reviewing Pane** (Review β Reviewing Pane) for a full list of changes
+
+**Step 3: Review Each Change**
+
+Navigate through changes one by one:
+
+**Option A: Manual review (recommended for careful review)**
+
+1. Click **Next** in the Review tab to jump to the first change
+2. Read the change in context
+3. Decide to **Accept** or **Reject**:
+ - **Accept**: Click "Accept" or press `Ctrl+Shift+=` (Windows) / `Cmd+Shift+=` (Mac)
+ - **Reject**: Click "Reject" or press `Ctrl+Shift+-` (Windows) / `Cmd+Shift+-` (Mac)
+4. Move to the next change and repeat
+
+**Option B: Batch accept/reject (for trusted collaborators)**
+
+If you trust the reviewer and want to accept all changes:
+
+1. Review β **Accept** dropdown β **Accept All Changes**
+2. Verify the result using **Display for Review** β **No Markup**
+
+β οΈ **Warning**: Only use "Accept All Changes" if you've reviewed the document first or trust the reviewer completely. Always keep a backup!
+
+**Step 4: Address Comments**
+
+Comments require manual actionβthey won't be automatically resolved:
+
+1. Read each comment
+2. Make the suggested edit (if applicable)
+3. Right-click the comment β **Resolve** or **Delete**
+4. Add a reply if you need clarification
+
+**Example workflow for a comment:**
+
+```
+Comment: "Can you add error bars to Figure 3?"
+
+Your action:
+1. Note this in a separate task list
+2. Update the figure in your source files
+3. Re-render the document
+4. Mark the comment as resolved
+```
+
+**Step 5: Save the reviewed document**
+
+Once you've accepted/rejected all changes:
+
+1. **File** β **Save As**
+2. Rename to indicate it's been reviewed:
+ ```
+ Paper-v1.0-DrSmith-REVIEWED.docx
+ ```
+3. Keep the original file with tracked changes as a backup
+
+#### Tools for Accepting/Rejecting Changes
+
+**Built-in Word Tools:**
+
+| Tool | Purpose | When to Use |
+|------|---------|-------------|
+| **Accept** | Accept a single change | Reviewing carefully one-by-one |
+| **Reject** | Reject a single change | Dismissing unwanted edits |
+| **Accept All** | Accept all changes at once | Trusted reviewer, bulk approval |
+| **Reject All** | Reject all changes | Starting over, rejecting entire review |
+| **Next/Previous** | Navigate between changes | Systematic review |
+| **Reviewing Pane** | View all changes in a list | Overview of all feedback |
+
+**Common Review Patterns:**
+
+**Pattern 1: Accept most, reject a few**
+```
+1. Click "Accept All Changes"
+2. Undo (Ctrl+Z) to restore tracked changes
+3. Review and reject specific changes manually
+4. Accept remaining changes
+```
+
+**Pattern 2: Careful review**
+```
+1. Start at the beginning
+2. Use "Next" to jump through each change
+3. Accept or reject individually
+4. Address comments as you go
+```
+
+**Pattern 3: Section-by-section**
+```
+1. Review Introduction: Accept/reject changes
+2. Review Methods: Accept/reject changes
+3. Review Results: Accept/reject changes
+4. Repeat for each section
+```
+
+#### Handling Complex Edits
+
+**Conflicting changes:**
+
+If multiple reviewers edited the same sentence differently:
+1. Open both reviewed documents side-by-side
+2. Compare the suggested changes
+3. Manually synthesize the best version
+4. Type the final version directly
+
+**Large deletions:**
+
+If a reviewer deleted an entire paragraph:
+1. Read the deleted content carefully
+2. Check for a comment explaining why
+3. Decide:
+ - Accept: The content was redundant or incorrect
+ - Reject: The content is important; maybe revise instead
+ - Compromise: Move the content to an appendix or footnote
+
+**Formatting-only changes:**
+
+If changes are purely formatting (bold, italics):
+- Generally accept if they improve readability
+- Reject if they conflict with journal style guidelines
+- Remember: Markdown controls formatting, so these may not matter
+
+#### Common Pitfalls
+
+β οΈ **Pitfall 1: Accepting changes without reading them**
+
+**Problem**: Blindly clicking "Accept All" without reviewing can introduce errors.
+
+**Solution**: Always do a quick skim of all changes before accepting in bulk.
+
+---
+
+β οΈ **Pitfall 2: Forgetting to address comments**
+
+**Problem**: Comments are suggestions, not tracked changesβthey won't auto-apply.
+
+**Solution**: Create a checklist of all comments and address them separately in your source files.
+
+---
+
+β οΈ **Pitfall 3: Losing track of which version you're working on**
+
+**Problem**: Multiple files with similar names cause confusion.
+
+**Solution**: Use clear naming conventions and timestamps:
+```
+Paper-v1.0-for-review-2026-01-24.docx (sent to reviewer)
+Paper-v1.0-DrSmith-RETURNED-2026-01-28.docx (received back)
+Paper-v1.0-DrSmith-REVIEWED-2026-01-28.docx (after you reviewed)
+```
+
+---
+
+β οΈ **Pitfall 4: Modifying the Word document instead of markdown**
+
+**Problem**: Editing the `.docx` file directly creates divergence from your source files.
+
+**Solution**: Treat the Word document as a **review artifact**, not the source of truth. Always apply changes to your `.qmd` markdown files and regenerate the Word export.
+
+### Converting Back to Markdown
+
+After reviewing and accepting changes in Word, you need to incorporate the edits back into your markdown source files. There are two main approaches: automated conversion with `pandoc` and manual transcription.
+
+#### Approach 1: Automated Conversion with Pandoc (Recommended for Major Edits)
+
+Pandoc is a universal document converter that can translate Word documents back to markdown. This is the fastest method for large-scale changes.
+
+**Prerequisites:**
+
+Install Pandoc if you haven't already:
+
+```bash
+# macOS
+brew install pandoc
+
+# Linux
+sudo apt-get install pandoc
+
+# Windows (using Chocolatey)
+choco install pandoc
+
+# Or download from: https://pandoc.org/installing.html
+```
+
+**Verify installation:**
+
+```bash
+pandoc --version
+```
+
+**Step 1: Convert the reviewed Word document to markdown**
+
+```bash
+# Basic conversion
+pandoc Paper-v1.0-DrSmith-REVIEWED.docx -o reviewed-draft.md
+
+# Preserve as much structure as possible
+pandoc Paper-v1.0-DrSmith-REVIEWED.docx \
+ -f docx \
+ -t markdown \
+ --wrap=none \
+ --extract-media=./images \
+ -o reviewed-draft.md
+```
+
+**Explanation of flags:**
+- `-f docx`: Input format is Word
+- `-t markdown`: Output format is markdown
+- `--wrap=none`: Don't wrap long lines (preserves formatting)
+- `--extract-media=./images`: Extract images to a folder
+- `-o reviewed-draft.md`: Output filename
+
+**Step 2: Compare the converted markdown with your original**
+
+Use `git diff` or a visual diff tool to see what changed:
+
+```bash
+# View differences in the terminal
+git diff chapters/introduction.qmd reviewed-draft.md
+
+# Or use a visual diff tool (see Section 5 for more)
+# macOS
+opendiff chapters/introduction.qmd reviewed-draft.md
+
+# Linux
+meld chapters/introduction.qmd reviewed-draft.md
+
+# Windows
+# Use a tool like WinMerge or VS Code's diff viewer
+```
+
+**Step 3: Merge the changes**
+
+**Option A: Manual merge (recommended for precision)**
+
+Open both files side-by-side and manually copy accepted changes from `reviewed-draft.md` into your original `.qmd` files:
+
+```bash
+# Open in VS Code with split view
+code --diff chapters/introduction.qmd reviewed-draft.md
+
+# Or use your preferred editor
+```
+
+**Option B: Automated merge (for advanced users)**
+
+Use git's merge tools if you've committed your changes:
+
+```bash
+# Copy converted markdown over your source
+cp reviewed-draft.md chapters/introduction.qmd
+
+# Review the diff
+git diff chapters/introduction.qmd
+
+# If satisfied, commit
+git add chapters/introduction.qmd
+git commit -m "Incorporate feedback from Dr. Smith"
+```
+
+**Step 4: Verify the merge**
+
+Re-render your document to ensure nothing broke:
+
+```bash
+cd research_paper
+quarto render --to docx
+```
+
+Open the generated Word document and verify:
+- All accepted changes are present
+- Formatting is correct
+- Citations still work
+- Figures and tables are intact
+
+#### Approach 2: Manual Transcription (Recommended for Small Edits)
+
+For minor changes (typos, sentence rewording, small additions), it's often faster to manually transcribe edits from the Word document into your markdown files.
+
+**Step 1: Open Word document and markdown side-by-side**
+
+```bash
+# Open the reviewed Word document
+open Paper-v1.0-DrSmith-REVIEWED.docx
+
+# Open your markdown source in an editor
+code chapters/introduction.qmd
+```
+
+**Step 2: Navigate through the Word document**
+
+Use Word's **Display for Review** β **No Markup** mode to see the final text with all accepted changes.
+
+**Step 3: Manually apply changes**
+
+For each accepted change:
+
+1. Locate the corresponding section in your `.qmd` file
+2. Make the same edit in markdown
+3. Mark the change as completed (e.g., highlight or check off in Word)
+
+**Example:**
+
+**Word document shows:**
+```
+The algorithm achieves 92% accuracy on the test set.
+ ^^^ (was 85%, changed to 92%)
+```
+
+**Apply to markdown:**
+```markdown
+
+The algorithm achieves 85% accuracy on the test set.
+
+
+The algorithm achieves 92% accuracy on the test set.
+```
+
+**Step 4: Address comments from Word**
+
+For each comment in the Word document:
+
+1. Read the comment
+2. Determine the action needed
+3. Apply the change in your `.qmd` file
+4. Check off the comment
+
+**Example:**
+
+**Word comment:**
+```
+[Comment]: "Can you add a citation for this claim?"
+```
+
+**Apply to markdown:**
+```markdown
+
+Deep learning has revolutionized computer vision.
+
+
+Deep learning has revolutionized computer vision [@lecun2015deep].
+```
+
+#### Approach 3: Hybrid Approach (Best for Most Cases)
+
+Combine automated conversion for bulk changes with manual transcription for precision:
+
+**Workflow:**
+
+1. **Use Pandoc** to convert the reviewed Word document to markdown
+2. **Use `git diff`** or a visual diff tool to see all changes
+3. **Manually review** each change and apply selectively to your source files
+4. **Test frequently** by re-rendering after each section
+
+**Example workflow:**
+
+```bash
+# Step 1: Convert Word to markdown
+pandoc Paper-v1.0-DrSmith-REVIEWED.docx -o reviewed.md
+
+# Step 2: See what changed
+git diff --no-index chapters/introduction.qmd reviewed.md > changes.diff
+
+# Step 3: Review changes and apply manually
+code --diff chapters/introduction.qmd reviewed.md
+
+# Step 4: Test after making changes
+quarto render chapters/introduction.qmd --to html
+```
+
+#### Tools for Comparing Versions
+
+**Command-line tools:**
+
+| Tool | Purpose | Installation |
+|------|---------|--------------|
+| `pandoc` | Convert Word β Markdown | `brew install pandoc` (macOS) |
+| `git diff` | Compare two text files | Built into git |
+| `diff` | Basic file comparison | Pre-installed on Unix |
+| `wdiff` | Word-by-word diff | `brew install wdiff` (macOS) |
+
+**Visual diff tools:**
+
+| Tool | Platform | Best For |
+|------|----------|----------|
+| VS Code | All | Built-in diff viewer, side-by-side |
+| Meld | Linux/macOS | Three-way merge, visual |
+| Beyond Compare | Windows | Professional diff/merge |
+| opendiff | macOS | Built-in macOS tool |
+| WinMerge | Windows | Free, open-source |
+
+**Example: Using VS Code's diff viewer**
+
+```bash
+# Open files in diff mode
+code --diff original.qmd reviewed.md
+```
+
+This shows:
+- **Red** (left): Original version
+- **Green** (right): Reviewed version
+- **Side-by-side view**: Easy to see changes
+
+#### Common Pitfalls When Converting
+
+β οΈ **Pitfall 1: Pandoc doesn't preserve Quarto-specific syntax**
+
+**Problem**: Quarto uses special syntax that Pandoc might not preserve:
+```markdown
+{{< pagebreak >}}
+@fig-results
+```
+
+**Solution**: Manually re-add Quarto-specific elements after conversion.
+
+---
+
+β οΈ **Pitfall 2: Citations get converted to plain text**
+
+**Problem**: Pandoc converts rendered citations back to plain text instead of citation keys:
+```markdown
+# In Word: "Smith et al. (2023)"
+# Pandoc converts to: "Smith et al. (2023)"
+# But you need: [@smith2023]
+```
+
+**Solution**: Manually restore citation keys in your markdown after conversion. Keep your original `.qmd` file open for reference.
+
+---
+
+β οΈ **Pitfall 3: Formatting differences cause noise in diffs**
+
+**Problem**: Line wrapping differences make diffs hard to read:
+```diff
+- This is a very long sentence that wraps
+- across multiple lines in the original file.
++ This is a very long sentence that wraps across multiple lines in the original file.
+```
+
+**Solution**: Use `pandoc --wrap=none` to avoid line wrapping, or use `git diff --word-diff` for word-level diffs.
+
+---
+
+β οΈ **Pitfall 4: Images and figures lose their Quarto attributes**
+
+**Problem**: Quarto figure syntax gets simplified:
+```markdown
+# Original Quarto:
+{#fig-results width=6in}
+
+# After Pandoc:
+
+```
+
+**Solution**: Manually restore Quarto attributes after conversion using your original file as reference.
+
+### Manual Merge Strategies
+
+When automated conversion isn't feasible or you need fine-grained control, manual merging is the way to go. This section covers practical strategies for efficiently incorporating Word feedback into your markdown source files.
+
+#### Strategy 1: Side-by-Side Review
+
+**Best for**: Small to medium documents, careful review
+
+**Setup:**
+
+```bash
+# Open Word document (accepted changes, "No Markup" view)
+open Paper-v1.0-DrSmith-REVIEWED.docx
+
+# Open markdown source in editor with split view
+code chapters/introduction.qmd chapters/methods.qmd
+```
+
+**Process:**
+
+1. **Start at the top**: Begin with the first section
+2. **Scan for differences**: Look for changes in the Word document
+3. **Apply to markdown**: Type or copy-paste the change into your `.qmd` file
+4. **Mark as done**: Highlight or check off in a printed copy
+5. **Move to next section**: Repeat systematically
+
+**Pro tip**: Print a copy of the Word document with accepted changes and physically check off sections as you complete them.
+
+#### Strategy 2: Change Log Method
+
+**Best for**: Documents with many reviewers, complex edits
+
+**Process:**
+
+**Step 1: Create a change log**
+
+Export all tracked changes to a text file for reference:
+
+1. In Word, go to **Review** β **Reviewing Pane**
+2. Copy all changes to a text document
+3. Save as `changes-log-DrSmith.txt`
+
+**Example change log:**
+
+```
+changes-log-DrSmith.txt
+-----------------------
+Page 3, Intro, Para 2:
+ - Changed "85%" to "92%"
+ - Added: "with 95% confidence intervals"
+
+Page 5, Methods, Para 1:
+ - Deleted sentence: "We used a simple baseline."
+ - Added: "We compared against state-of-the-art baselines."
+
+Page 8, Results, Figure 3:
+ - Comment: "Add error bars to this figure"
+```
+
+**Step 2: Work through the log**
+
+For each item in the log:
+1. Find the location in your `.qmd` file
+2. Apply the change
+3. Check off the item in your log
+
+**Step 3: Verify completeness**
+
+```bash
+# Count checked-off items
+grep "β" changes-log-DrSmith.txt | wc -l
+
+# Ensure all items are addressed
+```
+
+#### Strategy 3: Section-by-Section Merge
+
+**Best for**: Long documents with clear section boundaries
+
+**Process:**
+
+**Step 1: Break the work into sections**
+
+```bash
+# List your chapters/sections
+ls chapters/
+# introduction.qmd
+# methods.qmd
+# results.qmd
+# discussion.qmd
+```
+
+**Step 2: Merge one section at a time**
+
+```bash
+# Work on introduction
+code chapters/introduction.qmd
+
+# Compare against Word document
+# Apply all changes for this section
+
+# Test the section
+quarto render chapters/introduction.qmd --to html
+
+# Move to next section
+code chapters/methods.qmd
+```
+
+**Step 3: Track progress**
+
+Create a checklist:
+
+```markdown
+## Merge Progress
+
+- [x] Introduction - merged and tested
+- [x] Methods - merged and tested
+- [ ] Results - in progress
+- [ ] Discussion - not started
+- [ ] Conclusion - not started
+```
+
+**Pro tip**: Commit each section to git as you complete it:
+
+```bash
+# After merging introduction
+git add chapters/introduction.qmd
+git commit -m "Merge Dr. Smith feedback: Introduction section"
+
+# After merging methods
+git add chapters/methods.qmd
+git commit -m "Merge Dr. Smith feedback: Methods section"
+```
+
+This creates a granular history and makes it easy to revert if needed.
+
+#### Strategy 4: Two-Pass Review
+
+**Best for**: Complex documents, multiple types of feedback
+
+**Pass 1: Quick wins**
+
+Tackle easy, non-controversial changes first:
+- Typo fixes
+- Grammar corrections
+- Simple word substitutions
+
+```bash
+# Open source file
+code chapters/introduction.qmd
+
+# Make quick, obvious changes
+# Commit frequently
+git add chapters/introduction.qmd
+git commit -m "Fix typos and grammar (Dr. Smith feedback)"
+```
+
+**Pass 2: Complex changes**
+
+Address substantial edits that require thought:
+- Rewritten paragraphs
+- Structural changes
+- Content additions/deletions
+- Comments requiring new work
+
+```bash
+# Work on complex changes
+code chapters/results.qmd
+
+# May need to:
+# - Rerun analyses
+# - Generate new figures
+# - Add citations
+
+# Commit when complete
+git add chapters/results.qmd
+git commit -m "Revise results section per Dr. Smith suggestions"
+```
+
+#### Strategy 5: Diff-Driven Merge
+
+**Best for**: Technical users comfortable with command-line tools
+
+**Process:**
+
+**Step 1: Convert Word to markdown**
+
+```bash
+pandoc Paper-v1.0-DrSmith-REVIEWED.docx -o reviewed.md
+```
+
+**Step 2: Generate a diff**
+
+```bash
+# Create a unified diff
+git diff --no-index chapters/introduction.qmd reviewed.md > changes.diff
+
+# Or a word-level diff
+git diff --no-index --word-diff chapters/introduction.qmd reviewed.md > changes-word.diff
+```
+
+**Step 3: Review the diff file**
+
+```bash
+# View in terminal
+less changes.diff
+
+# Or open in editor
+code changes.diff
+```
+
+**Step 4: Apply changes selectively**
+
+Use the diff as a guide, manually applying each change to your source files:
+
+```diff
+# Example diff:
+-The algorithm achieves 85% accuracy.
++The algorithm achieves 92% accuracy.
+```
+
+Apply to your `.qmd` file:
+```markdown
+The algorithm achieves 92% accuracy.
+```
+
+**Step 5: Mark changes as applied**
+
+```bash
+# Annotate your diff file
+# Add "β" or "DONE" next to applied changes
+```
+
+#### Handling Comments and Suggestions
+
+Comments in Word documents require special attention since they're not direct text edits.
+
+**Step 1: Extract all comments**
+
+**Manual method:**
+1. Open Word document
+2. Review tab β Reviewing Pane
+3. Copy each comment to a text file
+
+**Automated method (Windows PowerShell):**
+```powershell
+# Extract comments to text (requires Word)
+$word = New-Object -ComObject Word.Application
+$doc = $word.Documents.Open("C:\path\to\Paper-REVIEWED.docx")
+$doc.Comments | ForEach-Object {
+ Write-Output "Page $($_.Scope.Information(1)): $($_.Range.Text) - $($_.Range.Text)"
+}
+$doc.Close()
+$word.Quit()
+```
+
+**Step 2: Categorize comments**
+
+Sort comments into action types:
+
+**Type A: Direct action items**
+```
+[Comment]: "Add a citation for this claim"
+β Action: Find and add citation in markdown
+```
+
+**Type B: Discussion points**
+```
+[Comment]: "Should we mention the limitations of this approach?"
+β Action: Write new paragraph about limitations
+```
+
+**Type C: Questions**
+```
+[Comment]: "What about the baseline comparison?"
+β Action: Clarify in text or respond to reviewer
+```
+
+**Step 3: Address each comment**
+
+Create a task list:
+
+```markdown
+## Comments to Address
+
+- [x] Page 3: Add citation for deep learning claim β Added [@lecun2015deep]
+- [x] Page 5: Mention baseline comparison β Added new paragraph
+- [ ] Page 8: Regenerate Figure 3 with error bars β Need to rerun analysis
+- [ ] Page 12: Clarify limitations section β Draft in progress
+```
+
+**Step 4: Respond to comments (optional)**
+
+For collaborative documents, you may want to respond to comments:
+
+1. Open the reviewed Word document
+2. Right-click on each comment
+3. Select **Reply**
+4. Explain what you did or ask for clarification
+
+**Example:**
+```
+Original comment: "Can you add error bars to Figure 3?"
+Your reply: "Done! I've regenerated Figure 3 with 95% confidence intervals. See revised draft."
+```
+
+#### Common Manual Merge Pitfalls
+
+β οΈ **Pitfall 1: Losing track of progress**
+
+**Problem**: Forgetting which changes you've already applied.
+
+**Solution**: Use a systematic approach:
+- Print the Word document and physically check off sections
+- Keep a checklist in a text file
+- Commit to git frequently with descriptive messages
+
+---
+
+β οΈ **Pitfall 2: Introducing new errors during transcription**
+
+**Problem**: Typos or copy-paste errors when manually applying changes.
+
+**Solution**:
+- Copy-paste directly from Word when possible (reduces typos)
+- Re-render frequently to catch errors early
+- Use git diff to review your changes before committing
+
+---
+
+β οΈ **Pitfall 3: Forgetting to handle comments**
+
+**Problem**: Comments aren't "changes" so they're easy to overlook.
+
+**Solution**: Create a separate checklist for comments and track them explicitly.
+
+---
+
+β οΈ **Pitfall 4: Inconsistent citation restoration**
+
+**Problem**: Forgetting to restore citation keys after manual edits.
+
+**Solution**: Search for common citation patterns and verify:
+```bash
+# Search for potential citations that need keys
+grep -E "\([A-Z][a-z]+ et al\., [0-9]{4}\)" chapters/*.qmd
+```
+
+If you find rendered citations like "(Smith et al., 2023)", replace with markdown keys like "[@smith2023]".
+
+---
+
+β οΈ **Pitfall 5: Skipping verification**
+
+**Problem**: Assuming your manual merge is correct without testing.
+
+**Solution**: Always re-render after merging:
+```bash
+quarto render --to docx
+# Open and verify the output matches expectations
+```
+
+#### Best Practices for Manual Merging
+
+β
**Work in small batches**
+- Merge 1-2 sections at a time
+- Test after each batch
+- Commit to git frequently
+
+β
**Use version control effectively**
+```bash
+# Before starting
+git checkout -b merge-drsmith-feedback
+
+# After each section
+git add chapters/introduction.qmd
+git commit -m "Merge intro: fix typos and add citations"
+
+# When done
+git checkout main
+git merge merge-drsmith-feedback
+```
+
+β
**Keep original files**
+- Don't delete the reviewed Word document
+- Keep your original markdown as reference
+- Use git to preserve history
+
+β
**Test incrementally**
+```bash
+# After each significant change
+quarto render --to html
+# Check that citations, figures, and formatting are intact
+```
+
+β
**Document your decisions**
+
+If you reject a reviewer's suggestion, document why:
+
+```markdown
+
+```
+
+---
+
+By following these manual merge strategies, you can efficiently and accurately incorporate Word feedback into your markdown source files while maintaining control and quality.
+
+---
+
+## 4. Managing Multiple Collaborators
+
+### Version Naming Conventions
+
+When working with multiple collaborators, a clear and consistent file naming convention is essential to avoid confusion and ensure you can track which version came from whom. This section provides practical naming strategies and organizational tips.
+
+#### Why Version Naming Matters
+
+**The problem:**
+Without a systematic naming convention, you'll quickly accumulate files like:
+```
+Paper.docx
+Paper-final.docx
+Paper-final-v2.docx
+Paper-REAL-final.docx
+Paper-draft-DrSmith.docx
+Paper-reviewed.docx
+```
+
+This chaos makes it impossible to know:
+- Which version is the latest?
+- Who reviewed each version?
+- When was each version created?
+- Which changes have been incorporated?
+
+**The solution:**
+A structured naming convention that includes:
+1. **Base name**: Consistent project/paper identifier
+2. **Version number**: Semantic versioning (v1.0, v1.1, v2.0)
+3. **Reviewer identifier**: Who is reviewing or has reviewed
+4. **Status**: Stage in the review process
+5. **Date**: ISO 8601 format (YYYY-MM-DD)
+
+#### Recommended Naming Convention
+
+**Template:**
+```
+[ProjectName]-[Version]-[ReviewerName]-[Status]-[Date].docx
+```
+
+**Examples:**
+```
+NeuralNet-Paper-v1.0-DrSmith-for-review-2026-01-24.docx
+NeuralNet-Paper-v1.0-DrSmith-RETURNED-2026-01-28.docx
+NeuralNet-Paper-v1.0-DrSmith-REVIEWED-2026-01-29.docx
+NeuralNet-Paper-v1.1-DrJones-for-review-2026-01-30.docx
+```
+
+**Component breakdown:**
+
+| Component | Purpose | Format | Example |
+|-----------|---------|--------|---------|
+| **ProjectName** | Identifies the paper/project | Short, no spaces | `NeuralNet-Paper` |
+| **Version** | Tracks major/minor revisions | `vX.Y` | `v1.0`, `v1.1`, `v2.0` |
+| **ReviewerName** | Who is reviewing/has reviewed | CamelCase or initial | `DrSmith`, `JDoe` |
+| **Status** | Stage in review process | See table below | `for-review`, `RETURNED` |
+| **Date** | When file was created/sent | `YYYY-MM-DD` | `2026-01-24` |
+
+**Status indicators:**
+
+| Status | Meaning | Who has the file |
+|--------|---------|------------------|
+| `for-review` | Sent to reviewer, awaiting feedback | Reviewer |
+| `RETURNED` | Reviewer has returned with changes | You (needs processing) |
+| `REVIEWED` | You've reviewed/accepted changes | You (ready to merge) |
+| `MERGED` | Changes incorporated into source | Archive (done) |
+| `revised` | Updated version after feedback | Ready for next round |
+
+#### Version Number Strategy
+
+Use semantic versioning to communicate the magnitude of changes:
+
+**Major version (X.0):**
+- Significant structural changes
+- Complete rewrites of sections
+- Major revisions requested by reviewers
+
+**Examples:**
+```
+v1.0 β v2.0 (Major revision after peer review)
+v2.0 β v3.0 (Restructured based on committee feedback)
+```
+
+**Minor version (X.Y):**
+- Small edits and refinements
+- Typo fixes and clarifications
+- Incremental improvements
+
+**Examples:**
+```
+v1.0 β v1.1 (Minor edits from co-author)
+v1.1 β v1.2 (Fixed typos and added one citation)
+```
+
+**When to increment:**
+
+```
+First draft to collaborators: v1.0
+After incorporating their feedback: v1.1 (if minor) or v2.0 (if major)
+Sent to second reviewer: v1.1 or v2.0 (reuse, add reviewer name)
+After incorporating second feedback: v1.2 or v2.1
+Final version for submission: v3.0 (or next major milestone)
+```
+
+#### Naming Convention for Multiple Reviewers
+
+**Scenario 1: Sequential reviews (one after another)**
+
+```
+NeuralNet-Paper-v1.0-DrSmith-for-review-2026-01-24.docx (sent to Dr. Smith)
+NeuralNet-Paper-v1.0-DrSmith-RETURNED-2026-01-28.docx (received back)
+NeuralNet-Paper-v1.1-DrJones-for-review-2026-01-30.docx (incorporated Smith's feedback, sent to Dr. Jones)
+NeuralNet-Paper-v1.1-DrJones-RETURNED-2026-02-03.docx (received back from Jones)
+NeuralNet-Paper-v1.2-for-submission-2026-02-05.docx (final version)
+```
+
+**Scenario 2: Parallel reviews (sent simultaneously)**
+
+```
+NeuralNet-Paper-v1.0-DrSmith-for-review-2026-01-24.docx (sent to Dr. Smith)
+NeuralNet-Paper-v1.0-DrJones-for-review-2026-01-24.docx (sent to Dr. Jones, same day)
+NeuralNet-Paper-v1.0-DrBrown-for-review-2026-01-24.docx (sent to Dr. Brown, same day)
+
+# When returned:
+NeuralNet-Paper-v1.0-DrSmith-RETURNED-2026-01-28.docx
+NeuralNet-Paper-v1.0-DrJones-RETURNED-2026-01-29.docx
+NeuralNet-Paper-v1.0-DrBrown-RETURNED-2026-01-30.docx
+
+# After consolidation:
+NeuralNet-Paper-v2.0-consolidated-2026-02-01.docx (all feedback merged)
+```
+
+**Scenario 3: Round-based reviews**
+
+Use round numbers for multiple review cycles:
+
+```
+NeuralNet-Paper-v1.0-Round1-DrSmith-for-review-2026-01-24.docx
+NeuralNet-Paper-v1.0-Round1-DrSmith-RETURNED-2026-01-28.docx
+NeuralNet-Paper-v2.0-Round2-DrSmith-for-review-2026-02-01.docx
+NeuralNet-Paper-v2.0-Round2-DrSmith-RETURNED-2026-02-05.docx
+```
+
+#### Directory Organization
+
+Keep your Word exports organized in a dedicated directory:
+
+**Recommended structure:**
+
+```
+research_paper/
+βββ _book/ # Quarto output directory
+β βββ Research-Paper.docx # Latest generated version
+βββ reviews/ # Dedicated review directory
+β βββ v1.0/ # Version 1.0 reviews
+β β βββ sent/ # Versions sent to reviewers
+β β β βββ Paper-v1.0-DrSmith-for-review-2026-01-24.docx
+β β β βββ Paper-v1.0-DrJones-for-review-2026-01-24.docx
+β β βββ returned/ # Versions returned by reviewers
+β β β βββ Paper-v1.0-DrSmith-RETURNED-2026-01-28.docx
+β β β βββ Paper-v1.0-DrJones-RETURNED-2026-01-29.docx
+β β βββ reviewed/ # Versions after your review
+β β βββ Paper-v1.0-DrSmith-REVIEWED-2026-01-29.docx
+β β βββ Paper-v1.0-DrJones-REVIEWED-2026-01-30.docx
+β βββ v2.0/ # Version 2.0 reviews (after major revision)
+β β βββ ...
+β βββ README.md # Review tracking log
+βββ chapters/ # Your markdown source files
+ βββ introduction.qmd
+ βββ ...
+```
+
+**Create the structure:**
+
+```bash
+# Create review directory structure
+cd research_paper
+mkdir -p reviews/v1.0/{sent,returned,reviewed}
+mkdir -p reviews/v2.0/{sent,returned,reviewed}
+
+# Create a review log
+cat > reviews/README.md << 'EOF'
+# Review Tracking Log
+
+## Version 1.0 (January 2026)
+
+- **Sent to Dr. Smith**: 2026-01-24
+ - Status: Returned 2026-01-28
+ - Changes: Minor typos, methodology clarifications
+ - Incorporated: 2026-01-29
+
+- **Sent to Dr. Jones**: 2026-01-24
+ - Status: Returned 2026-01-29
+ - Changes: Major revisions to results section
+ - Incorporated: 2026-01-30
+
+## Version 2.0 (February 2026)
+
+- **Consolidated version**: 2026-02-01
+ - Changes from both reviewers merged
+ - Major revision: Results section rewritten
+EOF
+```
+
+#### Tracking Versions in Git
+
+Use git tags to mark important milestones:
+
+```bash
+# Tag when sending for review
+git tag -a v1.0-sent-for-review -m "Version 1.0 sent to Dr. Smith and Dr. Jones for review"
+git push origin v1.0-sent-for-review
+
+# Tag after incorporating feedback
+git tag -a v1.1-reviews-merged -m "Incorporated feedback from Dr. Smith and Dr. Jones"
+git push origin v1.1-reviews-merged
+
+# Tag final submission version
+git tag -a v2.0-final-submission -m "Final version submitted to conference"
+git push origin v2.0-final-submission
+```
+
+**View your tags:**
+
+```bash
+# List all tags
+git tag -l
+
+# Show tag details
+git show v1.0-sent-for-review
+```
+
+#### Quick Reference: File Lifecycle
+
+**Complete lifecycle for a single reviewer:**
+
+```
+1. Generate: research_paper/_book/Research-Paper.docx
+ β
+2. Rename: reviews/v1.0/sent/Paper-v1.0-DrSmith-for-review-2026-01-24.docx
+ β (send to reviewer)
+3. Receive: reviews/v1.0/returned/Paper-v1.0-DrSmith-RETURNED-2026-01-28.docx
+ β (review and accept/reject changes)
+4. Process: reviews/v1.0/reviewed/Paper-v1.0-DrSmith-REVIEWED-2026-01-29.docx
+ β (merge into markdown source)
+5. Archive: reviews/v1.0/reviewed/ (keep for records)
+ β
+6. Re-render: research_paper/_book/Research-Paper.docx (now v1.1)
+```
+
+#### Automation Script
+
+Create a helper script to automate file naming:
+
+**`scripts/prepare-review.sh`:**
+
+```bash
+#!/bin/bash
+# prepare-review.sh - Prepare a paper for review with proper naming
+
+# Usage: ./prepare-review.sh
+# Example: ./prepare-review.sh v1.0 DrSmith 2026-01-24
+
+VERSION=$1
+REVIEWER=$2
+DATE=$3
+
+if [ -z "$VERSION" ] || [ -z "$REVIEWER" ] || [ -z "$DATE" ]; then
+ echo "Usage: $0 "
+ echo "Example: $0 v1.0 DrSmith 2026-01-24"
+ exit 1
+fi
+
+# Project name (customize this)
+PROJECT="NeuralNet-Paper"
+
+# Source file (latest Quarto export)
+SOURCE="research_paper/_book/Research-Paper.docx"
+
+# Destination
+DEST_DIR="research_paper/reviews/${VERSION}/sent"
+DEST_FILE="${DEST_DIR}/${PROJECT}-${VERSION}-${REVIEWER}-for-review-${DATE}.docx"
+
+# Create directory if it doesn't exist
+mkdir -p "$DEST_DIR"
+
+# Copy file
+cp "$SOURCE" "$DEST_FILE"
+
+echo "β Review copy created: $DEST_FILE"
+echo ""
+echo "Next steps:"
+echo "1. Open the file and enable Track Changes"
+echo "2. Send to $REVIEWER"
+echo "3. Wait for feedback"
+```
+
+**Make it executable:**
+
+```bash
+chmod +x scripts/prepare-review.sh
+```
+
+**Use it:**
+
+```bash
+# Prepare file for Dr. Smith
+./scripts/prepare-review.sh v1.0 DrSmith 2026-01-24
+
+# Prepare file for Dr. Jones (same version, parallel review)
+./scripts/prepare-review.sh v1.0 DrJones 2026-01-24
+```
+
+#### Best Practices
+
+β
**Be consistent**
+- Choose one naming convention and stick to it
+- Document your convention in your project README
+- Share it with your collaborators
+
+β
**Include dates**
+- Always use ISO 8601 format (YYYY-MM-DD)
+- Makes chronological sorting easy
+- Avoids ambiguity (is 03/04/26 March 4 or April 3?)
+
+β
**Use reviewer identifiers**
+- Helps track who provided what feedback
+- Makes consolidation easier
+- Useful for attribution and acknowledgments
+
+β
**Keep originals**
+- Never delete original review files
+- Archive completed reviews in dedicated directories
+- Disk space is cheap; lost work is expensive
+
+β
**Document your workflow**
+- Create a `reviews/README.md` file tracking all reviews
+- Note what changed in each version
+- Record reviewer names and dates
+
+β **Avoid**
+- Generic names like `draft.docx` or `final.docx`
+- Spaces in filenames (use hyphens or underscores)
+- Ambiguous dates (use YYYY-MM-DD, not MM/DD/YY)
+- Deleting old versions prematurely
+
+### Feedback Consolidation Workflow
+
+When multiple collaborators provide feedback on the same document version, you need a systematic workflow to consolidate their suggestions without losing track of changes or introducing conflicts. This section provides practical strategies for merging feedback from multiple reviewers.
+
+#### The Consolidation Challenge
+
+**Scenario:**
+You send version 1.0 of your paper to three reviewers simultaneously:
+- Dr. Smith (methodology expert)
+- Dr. Jones (domain expert)
+- Dr. Brown (writing/clarity review)
+
+A week later, you receive three Word documents back, each with tracked changes and comments. Now what?
+
+**Problems you'll face:**
+- **Overlapping edits**: Multiple reviewers edit the same paragraph differently
+- **Conflicting suggestions**: One reviewer says "add more detail," another says "be more concise"
+- **Redundant feedback**: Two reviewers catch the same typo
+- **Prioritization**: Which feedback is most important?
+
+**Goal:**
+Systematically review all feedback, make informed decisions, and merge everything back into your markdown source without losing any suggestions.
+
+#### Step-by-Step Consolidation Workflow
+
+Follow this proven workflow to efficiently consolidate feedback from multiple reviewers:
+
+##### Step 1: Organize Received Files
+
+As soon as you receive feedback, organize the files systematically:
+
+```bash
+# Create directory structure if not already present
+mkdir -p research_paper/reviews/v1.0/{sent,returned,reviewed,consolidated}
+
+# Move received files to the 'returned' directory
+mv ~/Downloads/Paper-DrSmith-comments.docx \
+ research_paper/reviews/v1.0/returned/Paper-v1.0-DrSmith-RETURNED-2026-01-28.docx
+
+mv ~/Downloads/Paper-DrJones-edits.docx \
+ research_paper/reviews/v1.0/returned/Paper-v1.0-DrJones-RETURNED-2026-01-29.docx
+
+mv ~/Downloads/Paper-DrBrown-review.docx \
+ research_paper/reviews/v1.0/returned/Paper-v1.0-DrBrown-RETURNED-2026-01-30.docx
+```
+
+##### Step 2: Create a Consolidation Tracking Document
+
+Before diving into reviews, create a central tracking document to record all feedback:
+
+**`research_paper/reviews/v1.0/consolidation-log.md`:**
+
+```markdown
+# Feedback Consolidation Log - Version 1.0
+
+**Review period**: 2026-01-24 to 2026-01-30
+**Reviewers**: Dr. Smith, Dr. Jones, Dr. Brown
+
+---
+
+## Summary of Feedback
+
+### Dr. Smith (Methodology)
+- **Received**: 2026-01-28
+- **Overall tone**: Positive, minor corrections
+- **Major points**:
+ - Add statistical significance tests (Results, Section 4.2)
+ - Clarify baseline selection criteria (Methods, Section 3.1)
+ - Fix citation formatting (throughout)
+- **Minor points**: ~15 typos and grammar fixes
+- **Status**: β³ In progress
+
+### Dr. Jones (Domain Expertise)
+- **Received**: 2026-01-29
+- **Overall tone**: Needs revision, substantial comments
+- **Major points**:
+ - Expand related work section (Introduction, Section 1.2)
+ - Rewrite discussion of implications (Discussion, Section 5.3)
+ - Add comparison with recent 2025 work
+- **Minor points**: ~8 clarification requests
+- **Status**: β³ In progress
+
+### Dr. Brown (Clarity and Writing)
+- **Received**: 2026-01-30
+- **Overall tone**: Well-written, small improvements
+- **Major points**:
+ - Simplify abstract (reduce jargon)
+ - Improve figure captions for clarity
+ - Restructure conclusion for impact
+- **Minor points**: ~20 writing/style improvements
+- **Status**: β³ In progress
+
+---
+
+## Conflicting Feedback
+
+| Location | Dr. Smith | Dr. Jones | Dr. Brown | Resolution |
+|----------|-----------|-----------|-----------|------------|
+| Abstract length | No comment | "Too short, add context" | "Too long, be concise" | Keep current, minor trim |
+| Results detail | "Add statistical tests" | "Add more examples" | "Current level is good" | Add stats, keep examples minimal |
+
+---
+
+## Consolidated Change List
+
+### Section 1: Introduction
+- [ ] Expand related work section (Jones)
+- [ ] Fix 3 typos (Smith, Brown)
+- [ ] Add recent 2025 citations (Jones)
+
+### Section 3: Methods
+- [ ] Clarify baseline selection (Smith)
+- [ ] Simplify technical jargon (Brown)
+
+### Section 4: Results
+- [ ] Add statistical significance tests (Smith)
+- [ ] Improve figure captions (Brown)
+
+### Section 5: Discussion
+- [ ] Rewrite implications paragraph (Jones)
+- [ ] Add limitations subsection (Jones)
+
+### Section 6: Conclusion
+- [ ] Restructure for impact (Brown)
+
+---
+
+## Notes and Decisions
+
+- **Decision 1**: Jones and Brown disagree about abstract length. Consulted with advisor; keeping current length with minor edits.
+- **Decision 2**: Smith's request for additional statistical tests is important; will rerun analysis and regenerate figures.
+- **Decision 3**: All three reviewers flagged the same typo in Section 2.3 ("teh" β "the"). Fixed.
+
+---
+
+**Status**: In progress (30% complete)
+**Target completion**: 2026-02-03
+```
+
+##### Step 3: Initial Triage (Priority Assessment)
+
+Before diving into detailed review, scan all three documents to prioritize feedback:
+
+**High priority (must address):**
+- β
Major methodological issues
+- β
Factual errors or incorrect claims
+- β
Missing citations or plagiarism risks
+- β
Structural problems affecting argumentation
+
+**Medium priority (should address):**
+- π‘ Clarifications and elaborations
+- π‘ Writing style improvements
+- π‘ Figure/table enhancements
+- π‘ Minor restructuring
+
+**Low priority (nice to have):**
+- βͺ Typos and grammar (if many reviewers agree)
+- βͺ Stylistic preferences
+- βͺ Optional additions
+
+**Create a priority list:**
+
+```markdown
+## Priority Action Items
+
+### Critical (must do before next round)
+1. Add statistical significance tests (Smith) - Requires analysis
+2. Expand related work with 2025 citations (Jones) - Requires research
+3. Fix factual error in Section 3.2 (Jones) - Immediate fix
+
+### Important (should do)
+4. Clarify baseline selection criteria (Smith)
+5. Improve figure captions (Brown)
+6. Rewrite implications paragraph (Jones)
+
+### Nice to have (if time permits)
+7. Simplify technical jargon (Brown)
+8. Restructure conclusion (Brown)
+9. Minor style improvements (all reviewers)
+```
+
+##### Step 4: Review Documents Sequentially
+
+Process each reviewer's feedback one at a time to avoid confusion:
+
+**Review #1: Dr. Smith (Methodology expert)**
+
+```bash
+# Open Dr. Smith's returned document
+open research_paper/reviews/v1.0/returned/Paper-v1.0-DrSmith-RETURNED-2026-01-28.docx
+
+# Open consolidation log for note-taking
+code research_paper/reviews/v1.0/consolidation-log.md
+```
+
+**Process:**
+1. Review tab β Display for Review β "All Markup"
+2. Read through all changes and comments
+3. Accept/reject changes in Word (saves for later reference)
+4. Document major points in consolidation log
+5. Note any items that require new work (analysis, figures, citations)
+6. Save reviewed version:
+
+```bash
+# Save as reviewed version
+# File β Save As β
+research_paper/reviews/v1.0/reviewed/Paper-v1.0-DrSmith-REVIEWED-2026-01-29.docx
+```
+
+**Repeat for each reviewer:**
+- Dr. Jones (domain expert)
+- Dr. Brown (clarity reviewer)
+
+##### Step 5: Identify Overlapping and Conflicting Feedback
+
+Create a comparison matrix for areas where multiple reviewers commented:
+
+**Example matrix:**
+
+| Section | Dr. Smith | Dr. Jones | Dr. Brown | Action |
+|---------|-----------|-----------|-----------|--------|
+| **Abstract** | No comment | "Add context about motivation" | "Remove jargon, simplify" | Simplify + add one sentence about motivation |
+| **Intro, Para 2** | "Fix typo: 'teh' β 'the'" | "Fix typo: 'teh' β 'the'" | "Fix typo: 'teh' β 'the'" | Fix typo (all agree) |
+| **Methods, Section 3.1** | "Clarify baseline selection" | "Baseline choice is fine" | No comment | Clarify (methodology expert takes priority) |
+| **Results, Figure 3** | "Add error bars" | "Add more data points" | "Caption is unclear" | Add error bars + improve caption (defer data points) |
+| **Discussion** | No comment | "Expand implications" | "Discussion is too long" | Expand implications selectively without adding length |
+
+**Strategies for resolving conflicts:**
+
+**Strategy 1: Expertise-based priority**
+- When experts disagree, defer to the person with relevant expertise
+- Example: Methodology expert's opinion on statistical tests > writing expert's opinion
+
+**Strategy 2: Majority rule**
+- If 2 out of 3 reviewers agree, follow the majority
+- Example: Two reviewers say "too verbose" β trim the section
+
+**Strategy 3: Synthesis**
+- Find a middle ground that addresses both concerns
+- Example: One says "add detail," another says "be concise" β add detail in a footnote or appendix
+
+**Strategy 4: Consult a tie-breaker**
+- For important disagreements, ask your advisor or a fourth party
+- Example: Structural disagreements about paper organization
+
+##### Step 6: Create a Master Change List
+
+Consolidate all feedback into a single, actionable checklist:
+
+**`research_paper/reviews/v1.0/master-changes.md`:**
+
+```markdown
+# Master Change List - Version 1.0 to 1.1
+
+## Changes Requiring New Work
+- [ ] Rerun analysis with statistical significance tests (Smith) - Est. 4 hours
+- [ ] Research and add 2025 citations (Jones) - Est. 2 hours
+- [ ] Regenerate Figure 3 with error bars (Smith) - Est. 1 hour
+- [ ] Create new limitations subsection (Jones) - Est. 1 hour
+
+## Direct Text Edits
+- [ ] Fix typo in Section 2.3: "teh" β "the" (all reviewers)
+- [ ] Simplify abstract: remove jargon (Brown)
+- [ ] Clarify baseline selection in Section 3.1 (Smith)
+- [ ] Improve caption for Figure 3 (Brown)
+- [ ] Rewrite implications paragraph in Section 5.3 (Jones)
+
+## Comments to Address
+- [ ] Jones: "Can you elaborate on how this relates to X?" (Section 4.2)
+- [ ] Brown: "Consider restructuring conclusion" (Section 6) - DEFER to next round
+- [ ] Smith: "Citation formatting is inconsistent" - Check CSL file
+
+## Deferred (Next Round)
+- [ ] Restructure conclusion (Brown) - Will do after major revisions
+- [ ] Add more examples to Results (Jones) - Not critical for this version
+
+---
+
+**Estimated time to complete**: 10-12 hours
+**Target completion**: 2026-02-03
+```
+
+##### Step 7: Apply Changes to Markdown Source
+
+Now that you have a consolidated master change list, apply changes to your `.qmd` markdown files:
+
+**Option A: Systematic section-by-section approach**
+
+```bash
+# Work through each section
+# 1. Introduction
+code chapters/introduction.qmd
+
+# Reference all three reviewed Word documents side-by-side
+# Apply all changes for Introduction
+# Test render
+
+quarto render chapters/introduction.qmd --to html
+
+# Commit
+git add chapters/introduction.qmd
+git commit -m "Consolidate intro feedback from Smith, Jones, Brown"
+
+# 2. Methods
+code chapters/methods.qmd
+# ... repeat process
+```
+
+**Option B: Priority-based approach**
+
+```bash
+# Address critical changes first across all sections
+# Then medium priority
+# Then low priority
+
+# Example: Fix all typos first (quick wins)
+# Then structural changes
+# Then new content additions
+```
+
+**Track your progress:**
+
+```bash
+# Update your master change list as you go
+# Mark items as completed: - [ ] β - [x]
+```
+
+##### Step 8: Handle New Work Items
+
+Some feedback requires generating new content (figures, analyses, citations):
+
+**Create a separate task list:**
+
+**`research_paper/reviews/v1.0/new-work-tasks.md`:**
+
+```markdown
+# New Work Required
+
+## Analysis and Data
+- [x] Rerun statistical significance tests - DONE 2026-02-01
+ - Results: All comparisons significant at p<0.01
+ - Updated: `analysis/stats.R`
+- [x] Regenerate Figure 3 with error bars - DONE 2026-02-01
+ - Saved to: `images/figure-3-updated.png`
+- [ ] Generate supplementary table (if requested)
+
+## Research and Citations
+- [x] Find 2025 papers on topic X - DONE 2026-02-02
+ - Added 3 papers to `references.bib`
+ - Papers: Smith2025, Johnson2025, Lee2025
+- [ ] Verify all citation formats
+
+## Writing
+- [x] Write limitations subsection - DONE 2026-02-02
+ - Added to `chapters/discussion.qmd`
+ - ~300 words
+- [ ] Revise implications paragraph
+```
+
+**Work on these in parallel:**
+- Research tasks (literature search)
+- Analysis tasks (rerun code, regenerate figures)
+- Writing tasks (new sections)
+
+##### Step 9: Create a Consolidated Version
+
+After incorporating all feedback into your markdown source, generate a new Word export:
+
+```bash
+# Render updated version
+cd research_paper
+quarto render --to docx
+
+# Create consolidated version for records
+cp _book/Research-Paper.docx \
+ reviews/v1.0/consolidated/Paper-v1.1-all-reviews-consolidated-2026-02-03.docx
+```
+
+This consolidated version:
+- β
Includes all accepted changes from all reviewers
+- β
Serves as a reference for what changed
+- β
Can be sent back to reviewers for verification (optional)
+- β
Becomes the basis for the next review round (v1.1)
+
+##### Step 10: Document Your Decisions
+
+Create a summary document explaining what you did and why:
+
+**`research_paper/reviews/v1.0/consolidation-summary.md`:**
+
+```markdown
+# Consolidation Summary: Version 1.0 β 1.1
+
+**Date**: 2026-02-03
+**Reviewers**: Dr. Smith, Dr. Jones, Dr. Brown
+
+## Changes Made
+
+### Major Revisions
+1. **Added statistical significance tests** (Smith)
+ - Reran all analyses with p-values
+ - Updated Results section (Section 4.2)
+ - Regenerated Figures 3 and 4
+
+2. **Expanded related work** (Jones)
+ - Added 3 recent 2025 citations
+ - Expanded Section 1.2 by ~400 words
+ - Improved context for our contributions
+
+3. **Rewrote implications paragraph** (Jones)
+ - Discussion section (5.3) completely rewritten
+ - Clearer connection to practical applications
+ - Added limitations subsection (5.4)
+
+### Minor Revisions
+- Fixed 23 typos across all sections (all reviewers)
+- Simplified abstract language (Brown)
+- Improved figure captions (Brown)
+- Clarified baseline selection criteria (Smith)
+
+## Conflicting Feedback - Resolutions
+
+### Conflict 1: Abstract length
+- **Jones**: "Too short, add context"
+- **Brown**: "Too long, remove jargon"
+- **Resolution**: Simplified jargon and added one sentence about motivation. Net change: +15 words
+
+### Conflict 2: Results detail level
+- **Smith**: "Add statistical tests"
+- **Jones**: "Add more examples"
+- **Brown**: "Current level is fine"
+- **Resolution**: Added statistical tests (critical for validity), kept example count the same
+
+## Deferred Items
+
+The following suggestions were noted but deferred to a future revision:
+- Restructure conclusion (Brown) - Will revisit after addressing peer review
+- Add supplementary examples (Jones) - Could go in appendix if needed
+
+## Statistics
+
+- **Total changes applied**: 89
+- **From Dr. Smith**: 32 changes (18 accepted, 12 modified, 2 deferred)
+- **From Dr. Jones**: 28 changes (22 accepted, 4 modified, 2 deferred)
+- **From Dr. Brown**: 29 changes (26 accepted, 3 modified, 0 deferred)
+- **Time spent**: ~11 hours
+
+## Next Steps
+
+1. Send v1.1 to reviewers for verification (optional)
+2. Incorporate any final feedback
+3. Proceed to submission (target: 2026-02-15)
+```
+
+#### Parallel Review Consolidation Matrix
+
+For complex projects with many reviewers, create a detailed matrix:
+
+**Example spreadsheet or table:**
+
+| Section | Para | Reviewer | Change Type | Description | Priority | Status | Notes |
+|---------|------|----------|-------------|-------------|----------|--------|-------|
+| Intro | 1 | Smith | Typo | "teh" β "the" | Low | β
Done | All reviewers agreed |
+| Intro | 2 | Jones | Addition | Add 2025 citation | High | β
Done | Added [@smith2025] |
+| Intro | 2 | Brown | Deletion | Remove redundant sentence | Medium | β
Done | Sentence 3 deleted |
+| Methods | 1 | Smith | Clarification | Explain baseline selection | High | β
Done | Added paragraph |
+| Methods | 1 | Jones | Rewording | Simplify jargon | Medium | β³ In progress | Partially done |
+| Results | 3 | Smith | Addition | Add p-values | Critical | β
Done | Reran analysis |
+| Results | 3 | Jones | Addition | Add more examples | Medium | β Deferred | Not critical now |
+| Results | 3 | Brown | Edit | Improve caption | Medium | β
Done | Caption rewritten |
+
+**Benefits of the matrix approach:**
+- Visual overview of all feedback
+- Easy to track completion status
+- Helps identify conflicts and overlaps
+- Can be shared with team/advisor
+
+#### Tools for Consolidation
+
+**Spreadsheet tools:**
+- Google Sheets: Collaborative, shareable with team
+- Excel: Local, powerful filtering and sorting
+- Airtable: Database-like, good for complex tracking
+
+**Document comparison tools:**
+- Word's "Compare Documents" feature (see Section 5)
+- Beyond Compare (Windows)
+- Meld (Linux/macOS)
+
+**Project management:**
+- Trello: Kanban-style task tracking
+- Notion: All-in-one workspace
+- Plain markdown checklists in git (simplest)
+
+#### Best Practices for Consolidation
+
+β
**Start with organization**
+- Set up directory structure before reviewing
+- Use consistent file naming
+- Create tracking documents upfront
+
+β
**Review sequentially, not simultaneously**
+- Process one reviewer's feedback completely before moving to the next
+- Prevents mental context switching
+- Ensures you don't miss anything
+
+β
**Document conflicts explicitly**
+- Don't ignore disagreements between reviewers
+- Record the conflict and your resolution
+- Helpful for explaining decisions later
+
+β
**Prioritize ruthlessly**
+- Not all feedback is equally important
+- Focus on critical issues first
+- Some suggestions can be safely deferred
+
+β
**Communicate your decisions**
+- Let reviewers know what you changed and why
+- Especially important for deferred or rejected suggestions
+- Maintains good relationships and trust
+
+β
**Test incrementally**
+- Re-render after each major section
+- Catch errors early
+- Verify citations and formatting
+
+β
**Commit frequently to git**
+- One commit per section or per reviewer
+- Makes it easy to revert if needed
+- Creates clear history of changes
+
+β **Avoid**
+- Processing all three documents simultaneously (chaos)
+- Accepting all changes blindly without reading
+- Ignoring conflicts (they won't resolve themselves)
+- Skipping documentation (you'll forget your reasoning)
+- Waiting too long to consolidate (feedback gets stale)
+
+### Git Branching for Reviews
+
+Using git branches strategically when managing review cycles keeps your main codebase clean, allows you to experiment with feedback, and makes it easy to revert changes if needed. This section covers practical git workflows for handling multiple reviewers and review rounds.
+
+#### Why Use Branches for Reviews?
+
+**Problem without branches:**
+```bash
+# Working directly on main branch
+git checkout main
+# Incorporate Dr. Smith's feedback
+# Oops, made a mistake
+# Hard to revert without losing other work
+# Dr. Jones's feedback conflicts with Smith's
+# Everything is tangled together
+```
+
+**Solution with branches:**
+```bash
+# Create separate branches for each review
+git checkout -b review/v1.0/dr-smith
+# Incorporate Dr. Smith's feedback
+# Easy to review changes: git diff main
+# Easy to revert: git checkout main
+# Can merge when confident
+```
+
+**Benefits:**
+- β
**Isolation**: Each reviewer's feedback in its own branch
+- β
**Safety**: Main branch stays clean and working
+- β
**Experimentation**: Try different approaches without risk
+- β
**Clarity**: Clear history of what changed and why
+- β
**Parallel work**: Handle multiple reviews simultaneously
+- β
**Easy rollback**: Discard branches if needed
+
+#### Basic Branching Strategy
+
+**Core principle:**
+- `main` branch: Always contains the latest stable, reviewed version
+- Review branches: Temporary branches for incorporating feedback
+- Consolidation branches: Combine multiple reviews before merging to main
+
+**Branch naming convention:**
+
+```
+review// # Individual reviewer branch
+review//consolidated # Combined review branch
+submission/ # Submission-specific branch
+```
+
+**Examples:**
+```
+review/v1.0/dr-smith # Dr. Smith's feedback on v1.0
+review/v1.0/dr-jones # Dr. Jones's feedback on v1.0
+review/v1.0/consolidated # All v1.0 feedback merged
+submission/icml-2026 # ICML conference submission
+```
+
+#### Workflow 1: Sequential Reviews (One Reviewer at a Time)
+
+**Scenario**: Send to Dr. Smith, incorporate feedback, then send to Dr. Jones.
+
+**Step 1: Prepare for first review**
+
+```bash
+# Ensure main is up to date
+git checkout main
+git status # Should be clean
+
+# Tag the version being sent for review
+git tag -a v1.0-sent-to-smith -m "Version 1.0 sent to Dr. Smith on 2026-01-24"
+git push origin v1.0-sent-to-smith
+
+# Generate Word export
+cd research_paper
+quarto render --to docx
+# Send the .docx file to Dr. Smith
+```
+
+**Step 2: Receive feedback and create review branch**
+
+```bash
+# When Dr. Smith returns feedback
+git checkout main
+git checkout -b review/v1.0/dr-smith
+
+# Record that you're starting review
+git commit --allow-empty -m "Start review: Dr. Smith feedback on v1.0"
+```
+
+**Step 3: Incorporate Dr. Smith's feedback**
+
+```bash
+# Still on review/v1.0/dr-smith branch
+code chapters/introduction.qmd
+
+# Make changes based on Dr. Smith's feedback
+# Commit incrementally
+
+git add chapters/introduction.qmd
+git commit -m "intro: Fix typos and clarify methodology (Smith feedback)"
+
+git add chapters/methods.qmd
+git commit -m "methods: Add baseline selection criteria (Smith feedback)"
+
+# Continue for all changes
+```
+
+**Step 4: Review your changes**
+
+```bash
+# See all changes made in this review branch
+git diff main
+
+# Or view change summary
+git log main..review/v1.0/dr-smith --oneline
+```
+
+**Step 5: Merge to main**
+
+```bash
+# When satisfied with all changes
+git checkout main
+git merge review/v1.0/dr-smith -m "Merge Dr. Smith's feedback (v1.0)"
+
+# Tag the updated version
+git tag -a v1.1-smith-feedback-merged -m "Version 1.1: Dr. Smith feedback incorporated"
+git push origin main v1.1-smith-feedback-merged
+
+# Optional: Delete the review branch
+git branch -d review/v1.0/dr-smith
+```
+
+**Step 6: Prepare for second reviewer (Dr. Jones)**
+
+```bash
+# Dr. Jones will review the version with Smith's feedback included
+git checkout main
+
+# Generate new export
+cd research_paper
+quarto render --to docx
+# Send to Dr. Jones
+
+# Tag what was sent
+git tag -a v1.1-sent-to-jones -m "Version 1.1 sent to Dr. Jones on 2026-02-01"
+```
+
+**Step 7: Incorporate Dr. Jones's feedback**
+
+```bash
+# Repeat the process with a new branch
+git checkout main
+git checkout -b review/v1.1/dr-jones
+
+# Incorporate feedback, commit, merge
+# ...
+
+git checkout main
+git merge review/v1.1/dr-jones -m "Merge Dr. Jones's feedback (v1.1)"
+git tag -a v1.2-jones-feedback-merged -m "Version 1.2: Dr. Jones feedback incorporated"
+```
+
+#### Workflow 2: Parallel Reviews (Multiple Reviewers Simultaneously)
+
+**Scenario**: Send v1.0 to Dr. Smith, Dr. Jones, and Dr. Brown at the same time.
+
+**Step 1: Prepare and send to all reviewers**
+
+```bash
+git checkout main
+git status # Clean
+
+# Tag the version sent to everyone
+git tag -a v1.0-sent-for-review -m "Version 1.0 sent to Smith, Jones, Brown on 2026-01-24"
+git push origin v1.0-sent-for-review
+
+# Generate Word export and send to all three
+cd research_paper
+quarto render --to docx
+# Distribute to reviewers
+```
+
+**Step 2: Create branches for each reviewer**
+
+As feedback comes in, create a branch for each reviewer:
+
+```bash
+# Dr. Smith returns feedback first (2026-01-28)
+git checkout main
+git checkout -b review/v1.0/dr-smith
+# Incorporate Smith's feedback
+# Commit changes
+
+# Dr. Jones returns feedback (2026-01-29)
+git checkout main # Start from main, not Smith's branch!
+git checkout -b review/v1.0/dr-jones
+# Incorporate Jones's feedback
+# Commit changes
+
+# Dr. Brown returns feedback (2026-01-30)
+git checkout main # Start from main again
+git checkout -b review/v1.0/dr-brown
+# Incorporate Brown's feedback
+# Commit changes
+```
+
+**Important**: Each review branch starts from `main`, not from other review branches. This keeps them independent.
+
+**Step 3: Review branches individually**
+
+```bash
+# Check what changed in each branch
+git checkout review/v1.0/dr-smith
+git diff main
+
+git checkout review/v1.0/dr-jones
+git diff main
+
+git checkout review/v1.0/dr-brown
+git diff main
+```
+
+**Step 4: Create a consolidation branch**
+
+```bash
+# Create a branch to merge all feedback
+git checkout main
+git checkout -b review/v1.0/consolidated
+
+# Merge each review branch one by one
+git merge review/v1.0/dr-smith -m "Merge Dr. Smith feedback"
+# Resolve conflicts if any
+
+git merge review/v1.0/dr-jones -m "Merge Dr. Jones feedback"
+# Resolve conflicts if any
+
+git merge review/v1.0/dr-brown -m "Merge Dr. Brown feedback"
+# Resolve conflicts if any
+```
+
+**Step 5: Resolve conflicts in consolidation branch**
+
+If reviewers edited the same lines, git will report conflicts:
+
+```bash
+# After git merge shows conflicts
+git status # Lists conflicted files
+
+# Open conflicted files
+code chapters/introduction.qmd
+```
+
+**Example conflict:**
+
+```markdown
+<<<<<<< HEAD
+The algorithm achieves 92% accuracy on the test set.
+=======
+The algorithm achieves 94% accuracy with high confidence.
+>>>>>>> review/v1.0/dr-jones
+```
+
+**Resolve by choosing the best option or synthesizing:**
+
+```markdown
+The algorithm achieves 92% accuracy on the test set with 95% confidence intervals.
+```
+
+**Mark as resolved:**
+
+```bash
+git add chapters/introduction.qmd
+git commit -m "Resolve conflict: Merge accuracy stats from Smith and Jones"
+```
+
+**Step 6: Test the consolidated version**
+
+```bash
+# On review/v1.0/consolidated branch
+cd research_paper
+quarto render
+
+# Verify output looks correct
+# Check citations, figures, formatting
+```
+
+**Step 7: Merge to main**
+
+```bash
+# When everything looks good
+git checkout main
+git merge review/v1.0/consolidated -m "Merge consolidated v1.0 reviews (Smith, Jones, Brown)"
+
+# Tag the new version
+git tag -a v1.1-all-reviews-merged -m "Version 1.1: All v1.0 reviews incorporated"
+git push origin main v1.1-all-reviews-merged
+
+# Clean up review branches
+git branch -d review/v1.0/dr-smith
+git branch -d review/v1.0/dr-jones
+git branch -d review/v1.0/dr-brown
+git branch -d review/v1.0/consolidated
+```
+
+#### Workflow 3: Experimental Approach (Try Before Committing)
+
+**Scenario**: You're not sure if a reviewer's suggestion will work. Try it in a branch first.
+
+```bash
+# Create an experimental branch
+git checkout main
+git checkout -b experiment/revise-intro-structure
+
+# Try the suggested restructuring
+code chapters/introduction.qmd
+# Make changes
+
+# Render and review
+cd research_paper
+quarto render --to html
+
+# If you like it:
+git add chapters/introduction.qmd
+git commit -m "Restructure intro per Dr. Jones suggestion"
+git checkout main
+git merge experiment/revise-intro-structure
+
+# If you don't like it:
+git checkout main
+git branch -D experiment/revise-intro-structure # Discard
+```
+
+#### Handling Complex Merge Conflicts
+
+**Common conflict scenarios:**
+
+**Scenario 1: Same paragraph edited differently**
+
+```markdown
+# File: chapters/introduction.qmd
+<<<<<<< HEAD (from review/v1.0/dr-smith)
+Deep learning has revolutionized computer vision by enabling
+automatic feature extraction from raw data.
+=======
+Deep learning has transformed the field of computer vision
+through its ability to learn hierarchical representations.
+>>>>>>> review/v1.0/dr-jones
+```
+
+**Resolution strategies:**
+
+**Option A: Choose one version**
+```bash
+# Keep Smith's version
+git checkout --ours chapters/introduction.qmd
+
+# Or keep Jones's version
+git checkout --theirs chapters/introduction.qmd
+```
+
+**Option B: Synthesize both**
+```markdown
+Deep learning has revolutionized computer vision by enabling
+automatic feature extraction and learning hierarchical
+representations from raw data.
+```
+
+**Scenario 2: Different reviewers added content in the same location**
+
+```markdown
+<<<<<<< HEAD
+## Background
+
+Deep learning has become the dominant paradigm in computer vision.
+Smith's new paragraph here.
+=======
+## Background
+
+Deep learning has become the dominant paradigm in computer vision.
+Jones's different paragraph here.
+>>>>>>> review/v1.0/dr-jones
+```
+
+**Resolution: Keep both, reorder logically**
+
+```markdown
+## Background
+
+Deep learning has become the dominant paradigm in computer vision.
+
+Smith's paragraph here (more general).
+
+Jones's paragraph here (more specific).
+```
+
+**Scenario 3: Structural conflicts (headings moved/renamed)**
+
+```bash
+# Use a visual merge tool
+git mergetool
+
+# Or manually resolve in editor
+code chapters/introduction.qmd
+```
+
+#### Advanced Branching Patterns
+
+**Pattern 1: Review rounds (iterative reviews)**
+
+```bash
+# First round
+review/round-1/dr-smith
+review/round-1/consolidated
+
+# After merging, send v2.0 for second round
+review/round-2/dr-smith
+review/round-2/consolidated
+
+# Easy to track progression
+git log --graph --oneline --all
+```
+
+**Pattern 2: Feature-based review branches**
+
+```bash
+# Instead of per-reviewer, organize by topic
+review/v1.0/methodology-changes
+review/v1.0/writing-improvements
+review/v1.0/figures-tables
+
+# Merge independently as each is completed
+```
+
+**Pattern 3: Submission branches**
+
+```bash
+# Create a branch for each submission venue
+git checkout main
+git checkout -b submission/icml-2026
+
+# Make venue-specific changes (formatting, length limits)
+# Don't merge back to main (submission-specific)
+
+# Tag when submitted
+git tag submission/icml-2026-final
+```
+
+#### Visualizing Your Branch Structure
+
+**View branch graph:**
+
+```bash
+# Text-based graph
+git log --graph --oneline --all --decorate
+
+# Example output:
+# * b4f3a2c (HEAD -> main) Merge consolidated v1.0 reviews
+# |\
+# | * a3e2d1c (review/v1.0/consolidated) Merge Dr. Brown feedback
+# | |\
+# | | * 9c8b7a6 (review/v1.0/dr-brown) Improve figure captions
+# | * | 7d6e5f4 (review/v1.0/dr-jones) Expand related work
+# | |/
+# | * 5e4d3c2 (review/v1.0/dr-smith) Add statistical tests
+# |/
+# * 3d2c1b0 (tag: v1.0-sent-for-review) Version 1.0 ready for review
+```
+
+**Visual git tools:**
+- **GitKraken**: GUI git client with visual branching
+- **GitHub Desktop**: Simple visual interface
+- **VS Code Git Graph**: Extension for VS Code
+- **Sourcetree**: Free git GUI
+
+#### Git Commands Quick Reference
+
+**Creating and switching branches:**
+
+```bash
+# Create and switch to new branch
+git checkout -b review/v1.0/dr-smith
+
+# Create branch without switching
+git branch review/v1.0/dr-jones
+
+# Switch to existing branch
+git checkout main
+```
+
+**Viewing branches:**
+
+```bash
+# List all branches
+git branch -a
+
+# List with last commit
+git branch -v
+
+# Show merged branches
+git branch --merged
+
+# Show unmerged branches
+git branch --no-merged
+```
+
+**Merging branches:**
+
+```bash
+# Merge branch into current branch
+git merge review/v1.0/dr-smith
+
+# Merge with custom message
+git merge review/v1.0/dr-smith -m "Merge Dr. Smith feedback"
+
+# Abort merge if conflicts are too complex
+git merge --abort
+```
+
+**Comparing branches:**
+
+```bash
+# Show differences between main and review branch
+git diff main..review/v1.0/dr-smith
+
+# Show commit log differences
+git log main..review/v1.0/dr-smith
+
+# Show files changed
+git diff --name-only main..review/v1.0/dr-smith
+```
+
+**Cleaning up branches:**
+
+```bash
+# Delete local branch (safe, prevents deleting unmerged)
+git branch -d review/v1.0/dr-smith
+
+# Force delete (careful!)
+git branch -D review/v1.0/dr-smith
+
+# Delete remote branch
+git push origin --delete review/v1.0/dr-smith
+```
+
+**Tags for milestones:**
+
+```bash
+# Create annotated tag
+git tag -a v1.0-sent-for-review -m "Sent to reviewers"
+
+# List tags
+git tag -l
+
+# Push tags to remote
+git push origin v1.0-sent-for-review
+
+# Push all tags
+git push origin --tags
+
+# Delete tag
+git tag -d v1.0-sent-for-review
+```
+
+#### Best Practices
+
+β
**Always start review branches from main**
+- Keeps review branches independent
+- Prevents tangled dependencies
+
+β
**Use descriptive branch names**
+- `review/v1.0/dr-smith` β
+- `review-smith` β (unclear)
+- `temp-branch` β (meaningless)
+
+β
**Commit frequently with clear messages**
+- One logical change per commit
+- Descriptive messages: "Add statistical tests (Smith feedback)"
+
+β
**Test before merging to main**
+- Always render your document: `quarto render`
+- Verify citations and figures
+- Check for broken links
+
+β
**Tag important milestones**
+- When sending for review
+- After incorporating feedback
+- Before submission
+
+β
**Keep main branch clean**
+- Only merge reviewed, tested changes
+- Main should always be in a "working" state
+
+β
**Delete branches after merging**
+- Reduces clutter
+- History is preserved in git log
+
+β **Avoid**
+- Working directly on main for reviews
+- Creating review branches from other review branches
+- Keeping stale branches around indefinitely
+- Force-pushing to shared branches
+
+### Handling Conflicting Feedback
+
+One of the most challenging aspects of working with multiple reviewers is dealing with conflicting suggestions. When one reviewer says "add more detail" and another says "be more concise," how do you decide? This section provides practical strategies for resolving conflicts and making informed decisions.
+
+#### Types of Conflicts
+
+Understanding the nature of conflicts helps you resolve them effectively.
+
+**Type 1: Direct Contradictions**
+
+Two reviewers suggest opposite actions on the same content.
+
+**Example:**
+```
+Location: Abstract (Section 0)
+Dr. Smith: "The abstract is too short. Add more context about the problem."
+Dr. Jones: "The abstract is too long. Cut unnecessary details."
+```
+
+**Type 2: Different Priorities**
+
+Reviewers have different views on what's important.
+
+**Example:**
+```
+Location: Results section (Section 4)
+Dr. Smith: "Add more statistical rigor (p-values, confidence intervals)."
+Dr. Brown: "Focus on practical implications rather than statistics."
+```
+
+**Type 3: Stylistic Disagreements**
+
+Different preferences for writing style or presentation.
+
+**Example:**
+```
+Location: Introduction (Section 1.2)
+Dr. Jones: "Use more technical terminologyβthis is an academic paper."
+Dr. Brown: "Simplify the language for broader accessibility."
+```
+
+**Type 4: Structural Conflicts**
+
+Disagreements about organization or flow.
+
+**Example:**
+```
+Location: Paper structure
+Dr. Smith: "Move the limitations section to the end of Discussion."
+Dr. Jones: "Limitations should be its own section after Discussion."
+```
+
+**Type 5: Content Inclusion Disagreements**
+
+Conflicting opinions about what should be included.
+
+**Example:**
+```
+Location: Methods (Section 3.3)
+Dr. Smith: "Add a detailed comparison with baseline X."
+Dr. Jones: "Remove the baseline discussionβit's out of scope."
+```
+
+#### Resolution Strategies
+
+##### Strategy 1: Expertise-Based Priority
+
+**When to use**: Conflicts involving technical or domain-specific issues.
+
+**Principle**: Defer to the reviewer with the most relevant expertise.
+
+**Example:**
+
+```
+Conflict:
+- Dr. Smith (statistician): "Use a two-tailed t-test here, not one-tailed."
+- Dr. Jones (domain expert): "One-tailed is fine for this application."
+
+Resolution:
+β Follow Dr. Smith (statistical methodology is their expertise)
+
+Action: Change to two-tailed t-test
+Rationale: Statistical correctness takes priority; consult stats expert
+```
+
+**How to apply:**
+
+1. Identify each reviewer's area of expertise
+2. Determine which expertise is most relevant to the conflict
+3. Prioritize that reviewer's suggestion
+4. Document your decision
+
+**Template for documenting:**
+
+```markdown
+## Decision: Statistical Test Selection (Section 4.1)
+
+**Conflict**: Smith recommends two-tailed test; Jones says one-tailed is fine
+**Expertise**: Smith (statistician) > Jones (domain) for this issue
+**Decision**: Follow Smithβuse two-tailed test
+**Rationale**: Statistical rigor is critical for publication acceptance
+```
+
+##### Strategy 2: Majority Rule
+
+**When to use**: Conflicts where expertise is similar or style-based.
+
+**Principle**: If 2 out of 3 (or 3 out of 4) reviewers agree, follow the majority.
+
+**Example:**
+
+```
+Conflict:
+- Dr. Smith: "Figure 3 caption is too brief, add more detail."
+- Dr. Jones: "Figure 3 caption is too brief, add more detail."
+- Dr. Brown: "Figure 3 caption is fine as-is."
+
+Resolution:
+β Follow majority (Smith + Jones)
+
+Action: Expand Figure 3 caption
+Rationale: 2 out of 3 reviewers think more detail is needed
+```
+
+**How to apply:**
+
+1. Tally reviewer opinions
+2. If β₯60% agree, follow the majority
+3. If votes are split evenly (2-2), use another strategy
+
+##### Strategy 3: Synthesis (Find Middle Ground)
+
+**When to use**: Both suggestions have merit and can be combined.
+
+**Principle**: Address both concerns with a creative solution.
+
+**Example 1: Abstract length**
+
+```
+Conflict:
+- Dr. Smith: "Abstract is too shortβadd problem motivation."
+- Dr. Jones: "Abstract is too longβcut unnecessary details."
+
+Synthesis:
+β Add motivation (Smith) while cutting redundant phrases (Jones)
+
+Before: "We propose a new algorithm. The algorithm improves accuracy.
+ We test it on multiple datasets."
+
+After: "We propose a new algorithm addressing the challenge of [motivation].
+ Our method improves accuracy on multiple benchmark datasets."
+
+Result: +1 sentence (motivation), -15 words (removed redundancy)
+```
+
+**Example 2: Technical depth**
+
+```
+Conflict:
+- Dr. Smith: "Add more mathematical formalism for rigor."
+- Dr. Brown: "Keep it accessible for practitioners."
+
+Synthesis:
+β Add formalism in the main text (Smith), move complex derivations to appendix (Brown)
+
+Action:
+- Main text: High-level equations with intuitive explanations
+- Appendix: Full mathematical derivations for rigorous readers
+```
+
+**How to apply:**
+
+1. Identify the core concern of each reviewer
+2. Brainstorm solutions that address both
+3. Implement the compromise
+4. Verify both reviewers' concerns are addressed
+
+##### Strategy 4: Consult a Tie-Breaker
+
+**When to use**: High-stakes conflicts where you're genuinely uncertain.
+
+**Principle**: Bring in a neutral third party (advisor, co-author, or domain expert).
+
+**Example:**
+
+```
+Conflict:
+- Dr. Smith: "Reorganize the paper: Results before Methods."
+- Dr. Jones: "Keep standard structure: Methods before Results."
+
+Resolution:
+β Consult your advisor (Dr. Taylor)
+
+Email to advisor:
+"Dr. Taylor, I'm receiving conflicting advice about paper structure.
+Dr. Smith suggests Results before Methods (to lead with impact),
+while Dr. Jones prefers the standard Methods-then-Results order.
+For this type of paper (empirical study in our field), which structure
+do you recommend?"
+
+Advisor's response: "For empirical studies in our field, stick with
+the standard Methods-then-Results structure. Reviewers expect it."
+
+Action: Follow standard structure (agree with Dr. Jones)
+```
+
+**When to consult:**
+- Structural disagreements affecting the whole paper
+- Conflicts about core claims or contributions
+- Ethical or methodological concerns
+- High-impact publication strategy decisions
+
+**Who to consult:**
+- Your advisor or senior co-author
+- Domain expert (if technical conflict)
+- Colleague who knows the target venue/journal
+
+##### Strategy 5: Context-Dependent Priority
+
+**When to use**: Conflicts where the "right" answer depends on your goals.
+
+**Principle**: Align decisions with your paper's target audience and venue.
+
+**Example:**
+
+```
+Conflict:
+- Dr. Smith: "Add more technical detail for ML researchers."
+- Dr. Jones: "Simplify for broader interdisciplinary audience."
+
+Context-dependent resolution:
+β Target venue: NeurIPS (ML conference)
+β Action: Follow Dr. Smith (add technical detail)
+β Rationale: NeurIPS audience expects technical depth
+
+Alternative scenario:
+β Target venue: Science (broad audience)
+β Action: Follow Dr. Jones (simplify, move details to supplement)
+β Rationale: Science prioritizes accessibility
+```
+
+**Questions to guide decisions:**
+- Who is the target audience?
+- What is the venue's style and expectations?
+- What are the page limits and format constraints?
+- What is the primary goal (acceptance vs. impact vs. clarity)?
+
+##### Strategy 6: Data-Driven Decision
+
+**When to use**: Conflicts about style or readability.
+
+**Principle**: Use objective measures or external feedback.
+
+**Example 1: Readability**
+
+```
+Conflict:
+- Dr. Smith: "Simplify the introduction for readability."
+- Dr. Jones: "Introduction is fine as-is."
+
+Data-driven resolution:
+β Run a readability test (Flesch-Kincaid, Hemingway)
+
+Before: Grade level 18 (very difficult)
+After simplification: Grade level 14 (college level)
+
+Decision: Simplify (data supports Dr. Smith)
+```
+
+**Example 2: Figure clarity**
+
+```
+Conflict:
+- Dr. Smith: "Figure 3 is too cluttered."
+- Dr. Jones: "Figure 3 includes necessary information."
+
+Data-driven resolution:
+β Ask 3 colleagues (not on the paper) to interpret the figure
+
+Result: 2 out of 3 found it confusing
+
+Decision: Simplify figure (data supports Dr. Smith)
+```
+
+**Tools and methods:**
+- Readability scores (Grammarly, Hemingway Editor)
+- A/B testing with colleagues
+- Citation checks (does the field follow one approach?)
+- Journal/venue guidelines (does the venue specify?)
+
+##### Strategy 7: Defer and Iterate
+
+**When to use**: Non-critical conflicts you can revisit later.
+
+**Principle**: Make a decision now, but be open to changing it in the next round.
+
+**Example:**
+
+```
+Conflict:
+- Dr. Smith: "Restructure the conclusion for more impact."
+- Dr. Brown: "Conclusion structure is fine."
+
+Decision:
+β Defer to next round (focus on critical issues now)
+
+Action:
+1. Note the conflict in your consolidation log
+2. Prioritize higher-impact feedback first (e.g., methodology fixes)
+3. Revisit conclusion structure after addressing critical issues
+4. Decide in the next review round or before submission
+```
+
+**When to defer:**
+- Stylistic issues (not factual or methodological)
+- Conflicts affecting non-critical sections
+- Changes requiring significant work without clear benefit
+- Situations where you need more time to think
+
+**How to defer responsibly:**
+```markdown
+## Deferred Decisions
+
+### Conflict: Conclusion structure (Section 6)
+- **Smith**: Restructure for impact
+- **Brown**: Current structure is fine
+- **Status**: Deferred to Round 2
+- **Reason**: Focusing on critical methodology revisions first
+- **Revisit**: Before final submission (target: 2026-02-15)
+```
+
+#### Conflict Resolution Framework
+
+Use this step-by-step framework for any conflict:
+
+**Step 1: Document the conflict clearly**
+
+```markdown
+## Conflict #1: Abstract Length
+
+**Location**: Abstract (Section 0)
+**Reviewers**:
+- Dr. Smith: "Too short, add motivation"
+- Dr. Jones: "Too long, be more concise"
+
+**Current state**: 150 words
+**Smith's preference**: ~200 words
+**Jones's preference**: ~120 words
+```
+
+**Step 2: Analyze the underlying concerns**
+
+Ask yourself:
+- What is each reviewer really concerned about?
+- Is this a style preference or a substantive issue?
+- Does one reviewer have more relevant expertise?
+
+```markdown
+**Smith's concern**: Readers won't understand the motivation
+**Jones's concern**: Abstract exceeds norms for this venue
+
+**Analysis**:
+- Both concerns are valid
+- Venue guidelines: "Abstracts should be 150-250 words" (we're at lower bound)
+- Smith has a substantive point about motivation
+```
+
+**Step 3: Choose a resolution strategy**
+
+Based on your analysis, pick the most appropriate strategy:
+
+```markdown
+**Strategy**: Synthesis (Strategy 3)
+**Rationale**: Both concerns can be addressed
+**Plan**: Add motivation sentence (+20 words) while cutting redundancies (-15 words)
+**Expected outcome**: 155 words (within guidelines, addresses both concerns)
+```
+
+**Step 4: Implement the resolution**
+
+Make the changes in your markdown source:
+
+```markdown
+
+We propose a new algorithm for neural network optimization...
+
+
+Neural network training is often slow and inefficient. We propose a new
+algorithm that addresses this challenge by...
+(added motivation, removed redundant phrases)
+```
+
+**Step 5: Document your decision**
+
+Record the resolution for future reference and communication:
+
+```markdown
+## Resolution: Abstract Length Conflict
+
+**Decision**: Added motivation sentence (+20 words), removed redundancies (-15 words)
+**Final length**: 155 words (within venue guidelines: 150-250)
+**Rationale**:
+- Addresses Smith's concern about motivation
+- Addresses Jones's concern about conciseness
+- Stays well within venue limits
+**Status**: β
Resolved and implemented (2026-02-02)
+```
+
+**Step 6: Communicate with reviewers (if appropriate)**
+
+For significant conflicts, let reviewers know your decision:
+
+**Email example:**
+
+```
+Subject: Feedback on Paper Draft - Resolution
+
+Dear Dr. Smith and Dr. Jones,
+
+Thank you both for your thoughtful feedback on the abstract. You raised
+important points about length and content.
+
+Dr. Smith suggested adding more motivation, while Dr. Jones recommended
+being more concise. I've addressed both concerns by:
+1. Adding a sentence clarifying the motivation for our work
+2. Removing redundant phrases to stay concise
+
+The abstract is now 155 words (within the 150-250 word guideline).
+I believe this strikes a good balance and hope it addresses both of
+your concerns.
+
+Best regards,
+[Your name]
+```
+
+#### Common Conflict Scenarios and Resolutions
+
+**Scenario 1: "Add more" vs. "Remove this"**
+
+```
+Reviewer A: "Add more examples to Section 4."
+Reviewer B: "Section 4 is too long, cut content."
+
+Resolution: Synthesis
+β Replace verbose examples with more concise, impactful ones
+β Net effect: More examples, fewer words
+```
+
+**Scenario 2: "Too technical" vs. "Not rigorous enough"**
+
+```
+Reviewer A: "Simplify the math for broader appeal."
+Reviewer B: "Add formal proofs for rigor."
+
+Resolution: Context + Synthesis
+β Keep main text accessible (Reviewer A)
+β Move formal proofs to appendix (Reviewer B)
+β Both audiences satisfied
+```
+
+**Scenario 3: "Rewrite this" vs. "This is fine"**
+
+```
+Reviewer A: "Rewrite Section 3βit's unclear."
+Reviewer B: "Section 3 is clear and well-written."
+
+Resolution: Majority + Tie-breaker
+β Ask a third colleague to read Section 3
+β If they find it unclear, revise (support Reviewer A)
+β If they find it clear, keep as-is (support Reviewer B)
+```
+
+**Scenario 4: "Include X" vs. "Exclude X"**
+
+```
+Reviewer A: "Include a comparison with method X."
+Reviewer B: "Method X is out of scopeβdon't include it."
+
+Resolution: Expertise + Context
+β Who is the expert on scope? (Likely your advisor or senior author)
+β What does the venue expect? (Check similar papers)
+β Is there a compromise? (Brief mention in Related Work vs. full comparison)
+```
+
+**Scenario 5: "Reorganize" vs. "Current structure is fine"**
+
+```
+Reviewer A: "Move Section 3 before Section 2."
+Reviewer B: "Current section order is logical."
+
+Resolution: Field norms + Tie-breaker
+β Check 3-5 papers in the target venue: What order do they use?
+β If there's a standard order, follow it
+β If both orders are common, defer to Reviewer B (less work) or consult advisor
+```
+
+#### Conflict Resolution Checklist
+
+Use this checklist when facing conflicts:
+
+```markdown
+## Conflict Resolution Checklist
+
+### 1. Document the conflict
+- [ ] Clearly state both positions
+- [ ] Identify the location/section affected
+- [ ] Note any relevant context
+
+### 2. Analyze the conflict
+- [ ] Identify each reviewer's underlying concern
+- [ ] Determine if it's substantive or stylistic
+- [ ] Check reviewer expertise on this topic
+
+### 3. Choose a strategy
+- [ ] Expertise-based (if one is clearly more expert)
+- [ ] Majority rule (if 2+ reviewers agree)
+- [ ] Synthesis (if both can be addressed)
+- [ ] Tie-breaker (if high-stakes and uncertain)
+- [ ] Context-dependent (if depends on audience/venue)
+- [ ] Data-driven (if objective measures help)
+- [ ] Defer (if non-critical and time is short)
+
+### 4. Implement the resolution
+- [ ] Make the changes in your source files
+- [ ] Test/render the document
+- [ ] Commit changes with descriptive message
+
+### 5. Document the decision
+- [ ] Record the resolution and rationale
+- [ ] Note any follow-up needed
+- [ ] Update your consolidation log
+
+### 6. Communicate (if needed)
+- [ ] Let reviewers know the outcome (optional but courteous)
+- [ ] Explain your rationale for significant conflicts
+```
+
+#### Best Practices
+
+β
**Stay objective**
+- Don't favor one reviewer due to seniority alone
+- Base decisions on merit, expertise, and context
+
+β
**Document everything**
+- Record conflicts and resolutions
+- Future you (or reviewers) will thank you
+
+β
**Communicate decisions**
+- Let reviewers know how you resolved conflicts
+- Explains your reasoning, builds trust
+
+β
**Be willing to synthesize**
+- The best solution often combines both suggestions
+- Creativity can resolve seemingly impossible conflicts
+
+β
**Prioritize substance over style**
+- Fix factual errors and methodological issues first
+- Stylistic conflicts can often be deferred
+
+β
**Consult when uncertain**
+- Don't guess on high-stakes decisions
+- Your advisor/senior collaborators are there to help
+
+β
**Stay flexible**
+- You can always revise in the next round
+- Perfection isn't required immediately
+
+β **Avoid**
+- Ignoring conflicts (they won't resolve themselves)
+- Always picking the easiest option
+- Dismissing feedback without consideration
+- Making arbitrary choices without rationale
+- Implementing conflicting suggestions simultaneously (creates inconsistency)
+
+---
+
+## 5. Comparing Versions and Tracking Changes
+
+Tracking what changed between versions is crucial for understanding reviewer feedback, documenting your revision process, and maintaining a clear history of your document's evolution. This section covers multiple approaches to comparing versions, from simple git diffs to sophisticated visual comparison tools.
+
+### Using Git Diff for Markdown
+
+Git's built-in diff functionality is your first line of defense for tracking changes in markdown files. It's fast, powerful, and works seamlessly with your version control workflow.
+
+#### Basic Git Diff Commands
+
+**Compare working directory to last commit:**
+
+```bash
+# See all changes since your last commit
+git diff
+
+# See changes in a specific file
+git diff chapters/introduction.qmd
+
+# See changes in all chapter files
+git diff chapters/*.qmd
+```
+
+**Compare between commits:**
+
+```bash
+# Compare current version to a specific commit
+git diff abc123 chapters/introduction.qmd
+
+# Compare two specific commits
+git diff abc123 def456 chapters/introduction.qmd
+
+# Compare current version to 5 commits ago
+git diff HEAD~5 chapters/introduction.qmd
+```
+
+**Compare between branches:**
+
+```bash
+# Compare current branch to main
+git diff main..HEAD chapters/introduction.qmd
+
+# Compare two branches
+git diff review-advisor..review-coauthor chapters/introduction.qmd
+```
+
+#### Making Git Diff More Readable
+
+**Word-level diffs** (instead of line-level):
+
+```bash
+# Show word-by-word changes
+git diff --word-diff chapters/introduction.qmd
+
+# Colored word diff with brackets
+git diff --word-diff=color chapters/introduction.qmd
+```
+
+**Example output:**
+
+```diff
+This is a [-long-]{+comprehensive+} sentence that [-demonstrates-]{+shows+} word-level changes.
+```
+
+**Ignore whitespace changes:**
+
+```bash
+# Ignore all whitespace changes
+git diff -w chapters/introduction.qmd
+
+# Ignore whitespace at end of lines
+git diff --ignore-space-at-eol chapters/introduction.qmd
+```
+
+**Side-by-side comparison:**
+
+```bash
+# Show changes side-by-side in terminal
+git diff --color-words --word-diff-regex=. chapters/introduction.qmd | less -R
+```
+
+#### Practical Git Diff Workflows
+
+**Workflow 1: Before and After Review**
+
+Track exactly what changed during a review cycle:
+
+```bash
+# Step 1: Before sending to reviewer, create a snapshot
+git checkout -b review-v1.0
+git add chapters/*.qmd
+git commit -m "Snapshot before Dr. Smith review"
+git push origin review-v1.0
+
+# Step 2: Send docx to reviewer
+quarto render --to docx
+
+# Step 3: After incorporating feedback, compare
+git diff review-v1.0..HEAD chapters/introduction.qmd
+
+# Step 4: Generate a summary of all changes
+git diff review-v1.0..HEAD chapters/*.qmd > review-changes-summary.txt
+```
+
+**Workflow 2: Tracking Multiple Review Rounds**
+
+```bash
+# Create tags for each review version
+git tag v1.0-sent-to-advisor
+git tag v1.1-after-advisor-feedback
+git tag v1.2-sent-to-coauthor
+
+# Compare any two versions
+git diff v1.0-sent-to-advisor v1.1-after-advisor-feedback
+
+# See all versions
+git tag -l
+```
+
+**Workflow 3: Statistics on Changes**
+
+```bash
+# See how many lines changed
+git diff --stat chapters/introduction.qmd
+
+# Count words added/removed
+git diff --word-diff=porcelain chapters/introduction.qmd | \
+ grep -e "^+[^+]" | wc -w # Added words
+git diff --word-diff=porcelain chapters/introduction.qmd | \
+ grep -e "^-[^-]" | wc -w # Removed words
+```
+
+**Example output:**
+
+```
+chapters/introduction.qmd | 42 +++++++++++++-----------
+1 file changed, 25 insertions(+), 17 deletions(-)
+```
+
+#### Creating Readable Change Reports
+
+**Generate an HTML diff for sharing:**
+
+```bash
+# Install diff2html (one-time setup)
+npm install -g diff2html-cli
+
+# Generate visual HTML diff
+git diff review-v1.0..HEAD chapters/*.qmd | diff2html -i stdin -o stdout > changes-report.html
+
+# Open in browser
+open changes-report.html # macOS
+xdg-open changes-report.html # Linux
+start changes-report.html # Windows
+```
+
+This creates a beautiful, syntax-highlighted, side-by-side comparison that you can share with collaborators.
+
+**Export diff to a text file with context:**
+
+```bash
+# Generate diff with 5 lines of context around each change
+git diff -U5 review-v1.0..HEAD chapters/*.qmd > detailed-changes.diff
+
+# Generate a summary with file names and statistics
+git diff --stat review-v1.0..HEAD > change-summary.txt
+```
+
+#### Advanced: Comparing Rendered PDFs
+
+Sometimes you want to compare the rendered output, not just the source:
+
+```bash
+# Step 1: Render both versions to PDF
+git checkout v1.0-sent-to-advisor
+quarto render --to pdf
+mv _book/Paper.pdf ../Paper-v1.0.pdf
+
+git checkout main
+quarto render --to pdf
+mv _book/Paper.pdf ../Paper-v2.0.pdf
+
+# Step 2: Use diff-pdf (install first)
+# macOS: brew install diff-pdf
+# Linux: apt-get install diff-pdf
+
+diff-pdf --view ../Paper-v1.0.pdf ../Paper-v2.0.pdf
+```
+
+This highlights visual differences between PDFs, useful for checking formatting changes.
+
+### Word's Compare Documents Feature
+
+Microsoft Word has a powerful built-in feature for comparing two versions of a document and displaying the differences as tracked changes. This is especially useful when you want to show collaborators exactly what changed between versions.
+
+#### When to Use Word Compare
+
+**Use Word's Compare feature when:**
+
+- You need to show non-technical collaborators what changed
+- You want to see differences in the rendered output (not source)
+- You're working with multiple Word versions and need to consolidate
+- A reviewer asks "what changed since the last version?"
+- You want to verify that your manual merge captured all changes
+
+**Don't use Word Compare when:**
+
+- You only care about source-level changes (use git diff instead)
+- Both versions are in markdown (use text-based diff tools)
+- You need to compare more than two versions simultaneously
+
+#### Step-by-Step: Comparing Two Word Documents
+
+**Step 1: Prepare the documents**
+
+Ensure you have two Word documents to compare:
+
+```bash
+# Render version 1 (before feedback)
+git checkout v1.0-sent-to-advisor
+quarto render --to docx
+mv _book/Paper.docx Paper-v1.0.docx
+
+# Render version 2 (after feedback)
+git checkout main
+quarto render --to docx
+mv _book/Paper.docx Paper-v2.0.docx
+```
+
+**Step 2: Open Word's Compare feature**
+
+- **Windows/Mac**: Open Microsoft Word
+ - Go to **Review** tab β **Compare** β **Compare...**
+
+**Step 3: Select documents**
+
+In the "Compare Documents" dialog:
+
+1. **Original document**: Select `Paper-v1.0.docx` (the older version)
+2. **Revised document**: Select `Paper-v2.0.docx` (the newer version)
+3. **Label changes with**: Enter a label like "Version 2.0" or "After Review"
+
+**Step 4: Configure comparison settings (optional)**
+
+Click **More >>** to access advanced options:
+
+**Comparison settings:**
+- β
**Insertions and deletions**: Track added/removed text
+- β
**Moves**: Track text that was moved
+- β
**Comments**: Include comments
+- β
**Formatting**: Track formatting changes
+- β
**Tables**: Track table changes
+- β
**Headers and footers**: Track header/footer changes
+
+**Show changes:**
+- Select **New document** (creates a third document with tracked changes)
+- Or select **Original document** to mark up the original
+
+**Step 5: Review the comparison**
+
+Word creates a new document showing:
+- **Red text with strikethrough**: Deletions from original
+- **Blue underlined text**: Additions in revised version
+- **Sidebar**: Summary of all changes
+
+**Step 6: Navigate changes**
+
+Use Word's Review tools to move through changes:
+
+- **Next/Previous**: Navigate change by change
+- **Accept**: Accept the current change
+- **Reject**: Reject the current change
+- **Accept All**: Accept all changes at once
+- **Reject All**: Reject all changes
+
+**Step 7: Save or export the comparison**
+
+```bash
+# Save as a new document
+File β Save As β "Paper-Comparison-v1-to-v2.docx"
+
+# Or export back to markdown
+pandoc Paper-Comparison-v1-to-v2.docx -o comparison-notes.md
+```
+
+#### Practical Word Compare Workflows
+
+**Workflow 1: Showing advisor what changed**
+
+```bash
+# Step 1: Render the version you sent to advisor
+git checkout review-advisor-v1
+quarto render --to docx
+cp _book/Paper.docx Paper-SENT.docx
+
+# Step 2: Render current version with incorporated feedback
+git checkout main
+quarto render --to docx
+cp _book/Paper.docx Paper-REVISED.docx
+
+# Step 3: Compare in Word
+# Use Word's Compare feature: Paper-SENT.docx vs Paper-REVISED.docx
+
+# Step 4: Save comparison document
+# File β Save As β "Paper-Changes-Summary.docx"
+
+# Step 5: Send to advisor
+# "Here's a document showing all changes I made based on your feedback"
+```
+
+**Workflow 2: Verifying manual merge accuracy**
+
+After manually merging feedback from a Word document back to markdown:
+
+```bash
+# Step 1: Render the reviewed Word file
+# (You already have Paper-v1.0-DrSmith-REVIEWED.docx)
+
+# Step 2: Render your updated markdown
+quarto render --to docx
+cp _book/Paper.docx Paper-AFTER-MERGE.docx
+
+# Step 3: Compare in Word
+# Original: Paper-v1.0-DrSmith-REVIEWED.docx
+# Revised: Paper-AFTER-MERGE.docx
+
+# Step 4: Check for any missed changes
+# Differences indicate changes you may have missed during manual merge
+```
+
+**Workflow 3: Consolidating feedback from multiple reviewers**
+
+```bash
+# Step 1: You have multiple reviewed versions
+# Paper-v1.0.docx (original)
+# Paper-v1.0-DrSmith-REVIEWED.docx
+# Paper-v1.0-DrJones-REVIEWED.docx
+
+# Step 2: Compare original vs DrSmith
+# Use Word Compare to see Dr. Smith's changes
+# Save as: "Paper-Changes-DrSmith.docx"
+
+# Step 3: Compare original vs DrJones
+# Use Word Compare to see Dr. Jones's changes
+# Save as: "Paper-Changes-DrJones.docx"
+
+# Step 4: Side-by-side review
+# Open both comparison documents
+# Identify overlapping vs. unique changes
+# Incorporate systematically into your markdown source
+```
+
+#### Tips for Using Word Compare Effectively
+
+**β
Best Practices:**
+
+- **Use descriptive labels**: Instead of "Version 1" and "Version 2", use "Sent-to-Advisor" and "After-Feedback"
+- **Save comparison documents**: Keep them as a record of what changed
+- **Check "Show Source Documents"**: View original and revised side-by-side
+- **Filter by change type**: Use the Review Pane to filter insertions/deletions/formatting
+- **Export to PDF**: Share comparison as PDF if recipient doesn't have Word
+
+**β οΈ Common Pitfalls:**
+
+- **Formatting noise**: Word Compare treats formatting changes (fonts, spacing) as edits. Disable "Formatting" in comparison settings if you only care about content.
+- **Large documents are slow**: Comparing 100+ page documents can take time. Consider comparing chapter-by-chapter.
+- **Tables create confusion**: Complex table changes may be hard to interpret. Review table changes separately.
+- **Citations look messy**: Rendered citations make diffs noisy. Focus on structural and textual changes.
+
+### Visual Diff Tools
+
+Visual diff tools provide a graphical interface for comparing files side-by-side, making it easier to spot changes and merge content. These tools excel at providing an intuitive view of differences, especially for non-programmers.
+
+#### Why Use Visual Diff Tools?
+
+**Advantages over command-line diffs:**
+
+- π **Side-by-side view**: See original and modified versions simultaneously
+- π¨ **Syntax highlighting**: Color-coded changes for easy scanning
+- π±οΈ **Interactive**: Click to accept/reject individual changes
+- π **Directory comparison**: Compare entire folder structures
+- π **Three-way merge**: Merge changes from two reviewers into your source
+- πΎ **Integrated editing**: Edit directly in the comparison view
+
+**When to use visual diff tools:**
+
+- Comparing markdown files before and after converting from Word
+- Merging feedback from multiple reviewers
+- Reviewing your changes before committing to git
+- Teaching collaborators how to read diffs
+- Resolving merge conflicts in git
+
+#### VS Code (Visual Studio Code)
+
+**Best for**: All platforms, built-in git integration, markdown preview
+
+**Installation:**
+
+```bash
+# macOS
+brew install --cask visual-studio-code
+
+# Linux (Debian/Ubuntu)
+sudo snap install code --classic
+
+# Windows
+# Download from https://code.visualstudio.com/
+```
+
+**Usage:**
+
+```bash
+# Compare two files
+code --diff original.qmd reviewed.md
+
+# Compare files with git integration
+code .
+# Then: Click Source Control β File β Right-click β "Compare with..."
+
+# Compare current file with previous commit
+# In VS Code: Right-click file β "Open Timeline" β Click previous version
+```
+
+**Features:**
+
+- **Inline diff view**: See changes highlighted within the text
+- **Side-by-side diff view**: Original and revised side-by-side
+- **Markdown preview**: Preview rendered markdown while comparing
+- **Git integration**: Compare against any commit directly
+- **Search in diff**: Find specific changes
+- **Navigate changes**: Jump between modifications
+
+**Example workflow:**
+
+```bash
+# Step 1: Convert Word feedback to markdown
+pandoc Paper-REVIEWED.docx -o reviewed.md
+
+# Step 2: Open in VS Code diff view
+code --diff chapters/introduction.qmd reviewed.md
+
+# Step 3: Review changes
+# - Left pane: Your original markdown
+# - Right pane: Converted feedback
+# - Use arrow buttons to jump between changes
+
+# Step 4: Manually apply changes to your source file
+# Copy desired changes from right pane to your .qmd file
+```
+
+#### Meld
+
+**Best for**: Linux/macOS, three-way merges, directory comparison
+
+**Installation:**
+
+```bash
+# macOS
+brew install --cask meld
+
+# Linux (Ubuntu/Debian)
+sudo apt-get install meld
+
+# Linux (Fedora)
+sudo dnf install meld
+```
+
+**Usage:**
+
+```bash
+# Compare two files
+meld original.qmd reviewed.md
+
+# Compare three files (three-way merge)
+meld base.qmd reviewer1.md reviewer2.md
+
+# Compare directories
+meld research_paper_v1/ research_paper_v2/
+```
+
+**Features:**
+
+- **Three-way merge**: Merge changes from two sources into a base file
+- **Directory comparison**: Compare entire project structures
+- **Syntax highlighting**: Supports markdown and many languages
+- **Merge mode**: Interactively merge changes with click-to-apply
+- **Filter files**: Ignore certain file types or patterns
+
+**Example workflow (three-way merge):**
+
+```bash
+# Scenario: Two reviewers edited the same Word document
+
+# Step 1: Convert both reviewed versions to markdown
+pandoc Paper-DrSmith-REVIEWED.docx -o reviewed-smith.md
+pandoc Paper-DrJones-REVIEWED.docx -o reviewed-jones.md
+
+# Step 2: Three-way merge in Meld
+meld chapters/introduction.qmd reviewed-smith.md reviewed-jones.md
+
+# Layout:
+# - Left: Your original markdown (destination)
+# - Center: Dr. Smith's changes
+# - Right: Dr. Jones's changes
+
+# Step 3: Click arrows to merge changes
+# - Click β to merge Smith's changes to your file
+# - Click β to merge Jones's changes to your file
+# - Edit directly in left pane as needed
+
+# Step 4: Save merged result
+# File β Save (saves to your original .qmd file)
+```
+
+#### Beyond Compare
+
+**Best for**: Windows, professional use, advanced filtering
+
+**Installation:**
+
+- Download from [https://www.scootersoftware.com/](https://www.scootersoftware.com/)
+- **Note**: Commercial software (~$60), free trial available
+
+**Usage:**
+
+```bash
+# Compare two files
+bcomp original.qmd reviewed.md
+
+# Compare directories
+bcomp research_paper_v1\ research_paper_v2\
+```
+
+**Features:**
+
+- **Professional-grade**: Used by software teams worldwide
+- **Advanced filtering**: Ignore whitespace, comments, specific patterns
+- **Folder sync**: Synchronize files between directories
+- **Archive support**: Compare files inside ZIP/TAR archives
+- **Hex comparison**: Compare binary files
+- **Report generation**: Export comparison reports to HTML/XML
+
+**Best use cases:**
+
+- Professional research teams with budget for tools
+- Comparing large numbers of files across versions
+- Need for detailed comparison reports for documentation
+
+#### DiffMerge
+
+**Best for**: Free alternative to Beyond Compare, all platforms
+
+**Installation:**
+
+- Download from [https://sourcegear.com/diffmerge/](https://sourcegear.com/diffmerge/)
+
+**Usage:**
+
+```bash
+# Compare two files
+diffmerge original.qmd reviewed.md
+
+# Three-way merge
+diffmerge base.qmd reviewer1.md reviewer2.md -o merged.qmd
+```
+
+**Features:**
+
+- **Free and open-source**
+- **Three-way merge support**
+- **Syntax highlighting**
+- **Integrated editing**
+- **Cross-platform**: Windows, macOS, Linux
+
+#### Platform-Specific Built-In Tools
+
+**macOS: opendiff (FileMerge)**
+
+Built into macOS, part of Xcode Command Line Tools:
+
+```bash
+# Install Xcode Command Line Tools (if not already installed)
+xcode-select --install
+
+# Compare two files
+opendiff original.qmd reviewed.md
+
+# Three-way merge
+opendiff original.qmd reviewed.md -ancestor base.qmd -merge merged.qmd
+```
+
+**Windows: WinMerge**
+
+Free, open-source, Windows-only:
+
+```bash
+# Download from https://winmerge.org/
+
+# Compare two files
+WinMergeU.exe original.qmd reviewed.md
+
+# Compare directories
+WinMergeU.exe research_paper_v1\ research_paper_v2\
+```
+
+**Features:**
+
+- **Windows integration**: Right-click β "WinMerge" in Explorer
+- **Plugin support**: Extend functionality
+- **Syntax highlighting**: Markdown support
+- **Generate reports**: HTML diff reports
+
+**Linux: Kompare**
+
+KDE's graphical diff tool:
+
+```bash
+# Install
+sudo apt-get install kompare # Debian/Ubuntu
+sudo dnf install kompare # Fedora
+
+# Compare files
+kompare original.qmd reviewed.md
+```
+
+#### Choosing the Right Visual Diff Tool
+
+| Tool | Platform | Cost | Best For | Three-Way Merge |
+|------|----------|------|----------|-----------------|
+| **VS Code** | All | Free | General use, git integration | No |
+| **Meld** | Linux/Mac | Free | Three-way merge, directories | β
Yes |
+| **Beyond Compare** | Windows | Paid | Professional, advanced features | β
Yes |
+| **DiffMerge** | All | Free | Free alternative to Beyond Compare | β
Yes |
+| **opendiff** | macOS | Free | Built into macOS | β
Yes |
+| **WinMerge** | Windows | Free | Windows users, simple needs | No |
+| **Kompare** | Linux | Free | KDE users | No |
+
+**Quick recommendation:**
+
+- **Just starting out?** Use **VS Code** (you probably already have it)
+- **Need three-way merge?** Use **Meld** (Linux/Mac) or **DiffMerge** (all platforms)
+- **Professional team?** Consider **Beyond Compare**
+- **macOS user?** Try **opendiff** (already installed)
+- **Windows user?** Try **WinMerge** (free and simple)
+
+### Command-Line Comparison
+
+For power users and automation workflows, command-line comparison tools offer speed, scriptability, and integration with build pipelines. These tools are especially useful when you need to compare files programmatically or generate reports automatically.
+
+#### diff (Standard Unix Tool)
+
+**Built into**: Linux, macOS, Windows (Git Bash, WSL)
+
+**Basic usage:**
+
+```bash
+# Compare two files
+diff original.qmd reviewed.md
+
+# Unified diff format (more readable)
+diff -u original.qmd reviewed.md
+
+# Side-by-side comparison
+diff -y original.qmd reviewed.md
+
+# Ignore whitespace
+diff -w original.qmd reviewed.md
+
+# Recursive directory comparison
+diff -r research_paper_v1/ research_paper_v2/
+```
+
+**Understanding diff output:**
+
+```diff
+< This line only appears in original.qmd
+> This line only appears in reviewed.md
+```
+
+**Unified diff format (`-u` flag):**
+
+```diff
+--- original.qmd
++++ reviewed.md
+@@ -10,7 +10,7 @@
+ This line is the same in both files.
+-This line was removed.
++This line was added.
+ This line is also the same.
+```
+
+**Common flags:**
+
+| Flag | Purpose | Example |
+|------|---------|---------|
+| `-u` | Unified format (context around changes) | `diff -u file1 file2` |
+| `-y` | Side-by-side | `diff -y file1 file2` |
+| `-w` | Ignore whitespace | `diff -w file1 file2` |
+| `-i` | Ignore case | `diff -i file1 file2` |
+| `-r` | Recursive (directories) | `diff -r dir1/ dir2/` |
+| `-q` | Brief (only report if different) | `diff -q file1 file2` |
+
+**Practical example:**
+
+```bash
+# Generate a diff report for documentation
+diff -u chapters/introduction.qmd reviewed-introduction.md > changes-intro.diff
+
+# Check if files are identical (exit code 0 = identical)
+if diff -q original.qmd reviewed.md > /dev/null; then
+ echo "Files are identical"
+else
+ echo "Files differ"
+fi
+```
+
+#### wdiff (Word-Based Diff)
+
+**Best for**: Natural language documents, prose-heavy files
+
+Unlike `diff`, which compares line-by-line, `wdiff` compares word-by-word, making it ideal for academic writing where sentences may reflow across lines.
+
+**Installation:**
+
+```bash
+# macOS
+brew install wdiff
+
+# Linux (Debian/Ubuntu)
+sudo apt-get install wdiff
+
+# Linux (Fedora)
+sudo dnf install wdiff
+```
+
+**Usage:**
+
+```bash
+# Basic word diff
+wdiff original.qmd reviewed.md
+
+# With color output
+wdiff -w $'\e[31m' -x $'\e[0m' -y $'\e[32m' -z $'\e[0m' original.qmd reviewed.md
+
+# Show statistics
+wdiff -s original.qmd reviewed.md
+```
+
+**Example output:**
+
+```
+This is a [-long-] {+comprehensive+} sentence that [-demonstrates-] {+illustrates+} the difference.
+```
+
+- `[-removed-]`: Words that were deleted
+- `{+added+}`: Words that were added
+
+**Practical example:**
+
+```bash
+# Compare and count word changes
+wdiff -s chapters/introduction.qmd reviewed-introduction.md
+
+# Output:
+# chapters/introduction.qmd: 45 words deleted
+# reviewed-introduction.md: 52 words inserted
+```
+
+**Why use wdiff for academic writing:**
+
+```bash
+# Example: Line-based diff vs word-based diff
+
+# Original file (line-wrapped at 80 characters):
+This is a very long sentence that wraps across multiple lines in the markdown
+source file but appears as a single line in the rendered output.
+
+# Reviewed file (different line wrapping):
+This is a very long sentence that wraps across multiple
+lines in the markdown source file but appears as a single line in the output.
+
+# diff output (noisy, shows line removal/addition):
+- source file but appears as a single line in the rendered output.
++ lines in the markdown source file but appears as a single line in the output.
+
+# wdiff output (clean, shows actual word change):
+... file but appears as a single line in the [-rendered-] output.
+```
+
+#### difftastic (Structural Diff)
+
+**Best for**: Markdown with code blocks, syntax-aware comparison
+
+`difftastic` is a modern diff tool that understands file structure and syntax, making it excellent for markdown files with embedded code.
+
+**Installation:**
+
+```bash
+# macOS
+brew install difftastic
+
+# Linux
+cargo install difftastic # Requires Rust
+
+# Or download binary from https://github.com/Wilfred/difftastic/releases
+```
+
+**Usage:**
+
+```bash
+# Compare two files
+difft original.qmd reviewed.md
+
+# Set as git difftool
+git config --global diff.external difft
+git diff
+
+# Compare specific sections
+difft --display side-by-side original.qmd reviewed.md
+```
+
+**Features:**
+
+- **Syntax-aware**: Understands markdown, code blocks, YAML frontmatter
+- **Structural matching**: Matches sections even if reordered
+- **Color-coded**: Easy-to-read terminal output
+- **Language support**: 30+ programming languages, markdown, JSON, YAML
+
+**Example:**
+
+```bash
+# Compare Quarto documents (handles YAML + markdown + code)
+difft chapters/analysis.qmd reviewed-analysis.md
+
+# Output highlights:
+# - YAML frontmatter changes separately
+# - Code block changes with syntax highlighting
+# - Prose changes word-by-word
+```
+
+#### delta (Syntax-Highlighting Diff)
+
+**Best for**: Beautiful terminal output, git integration
+
+`delta` enhances git diff and other diff tools with syntax highlighting and side-by-side views.
+
+**Installation:**
+
+```bash
+# macOS
+brew install git-delta
+
+# Linux (binary releases)
+wget https://github.com/dandavison/delta/releases/download/0.16.5/delta-0.16.5-x86_64-unknown-linux-gnu.tar.gz
+tar -xzf delta-*.tar.gz
+sudo mv delta-*/delta /usr/local/bin/
+```
+
+**Configure with git:**
+
+```bash
+# Add to ~/.gitconfig
+git config --global core.pager delta
+git config --global interactive.diffFilter 'delta --color-only'
+git config --global delta.navigate true
+git config --global delta.line-numbers true
+git config --global delta.side-by-side true
+```
+
+**Usage:**
+
+```bash
+# Now git diff uses delta automatically
+git diff chapters/introduction.qmd
+
+# Compare two files directly
+delta original.qmd reviewed.md
+
+# Side-by-side view
+delta --side-by-side original.qmd reviewed.md
+```
+
+**Features:**
+
+- **Syntax highlighting**: Color-coded markdown, code blocks
+- **Side-by-side mode**: Split-screen view in terminal
+- **Line numbers**: Easy reference to source files
+- **Hyperlinks**: Jump to files in editors (VS Code, etc.)
+- **Themes**: Customizable color schemes
+
+#### Automation and Scripting
+
+**Generate change reports automatically:**
+
+```bash
+#!/bin/bash
+# generate-change-report.sh
+
+ORIGINAL="chapters/introduction.qmd"
+REVIEWED="reviewed-introduction.md"
+REPORT="change-report.txt"
+
+echo "Change Report: Introduction Chapter" > $REPORT
+echo "Generated: $(date)" >> $REPORT
+echo "======================================" >> $REPORT
+echo "" >> $REPORT
+
+echo "SUMMARY:" >> $REPORT
+wdiff -s $ORIGINAL $REVIEWED >> $REPORT
+echo "" >> $REPORT
+
+echo "DETAILED CHANGES:" >> $REPORT
+wdiff $ORIGINAL $REVIEWED >> $REPORT
+
+echo "Report saved to $REPORT"
+```
+
+**Compare all chapters in a loop:**
+
+```bash
+#!/bin/bash
+# compare-all-chapters.sh
+
+for file in chapters/*.qmd; do
+ basename=$(basename "$file" .qmd)
+ echo "Comparing $basename..."
+
+ # Generate diff for each chapter
+ diff -u "$file" "reviewed-${basename}.md" > "diffs/${basename}.diff"
+
+ # Count changes
+ added=$(grep "^+" "diffs/${basename}.diff" | wc -l)
+ removed=$(grep "^-" "diffs/${basename}.diff" | wc -l)
+
+ echo " Added: $added lines"
+ echo " Removed: $removed lines"
+done
+
+echo "All diffs saved to diffs/ directory"
+```
+
+**Check for differences before committing:**
+
+```bash
+#!/bin/bash
+# pre-commit-check.sh
+
+# Check if any .qmd files have uncommitted changes
+if git diff --name-only | grep -q "\.qmd$"; then
+ echo "β οΈ Warning: You have uncommitted .qmd files"
+ echo ""
+ echo "Changed files:"
+ git diff --name-only | grep "\.qmd$"
+ echo ""
+ echo "Review changes with: git diff"
+ exit 1
+fi
+
+echo "β
All .qmd files are committed"
+```
+
+#### Comparison Tool Quick Reference
+
+| Tool | Best For | Installation | Output Format |
+|------|----------|--------------|---------------|
+| `diff` | General comparison, portable | Pre-installed | Line-based |
+| `git diff` | Version control, commit history | Pre-installed | Line-based |
+| `wdiff` | Prose, natural language | `brew install wdiff` | Word-based |
+| `difftastic` | Structured files, markdown+code | `brew install difftastic` | Syntax-aware |
+| `delta` | Beautiful terminal output | `brew install git-delta` | Enhanced git diff |
+| `diff2html` | HTML reports for sharing | `npm install -g diff2html-cli` | HTML |
+
+**Command cheat sheet:**
+
+```bash
+# Line-based comparison
+diff -u file1 file2 # Unified format
+git diff file1 file2 # Git's diff
+git diff --word-diff file1 file2 # Word-level in git
+
+# Word-based comparison
+wdiff file1 file2 # Word-by-word
+wdiff -s file1 file2 # With statistics
+
+# Syntax-aware comparison
+difft file1 file2 # Structural diff
+delta file1 file2 # Syntax-highlighted
+
+# Generate reports
+diff -u file1 file2 > changes.diff # Save to file
+diff2html -i file changes.diff # HTML report
+wdiff file1 file2 > changes.txt # Word-based report
+
+# Ignore whitespace
+diff -w file1 file2 # Ignore all whitespace
+git diff -w file1 file2 # Git ignore whitespace
+wdiff -w file1 file2 # wdiff ignore whitespace
+
+# Directory comparison
+diff -r dir1/ dir2/ # Recursive diff
+git diff --stat branch1..branch2 # Git branch stats
+```
+
+**Practical workflow combining tools:**
+
+```bash
+# Step 1: High-level check (are files different?)
+diff -q original.qmd reviewed.md
+
+# Step 2: See overall statistics
+wdiff -s original.qmd reviewed.md
+
+# Step 3: Review changes visually
+delta --side-by-side original.qmd reviewed.md
+
+# Step 4: Generate report for documentation
+diff -u original.qmd reviewed.md | diff2html -i stdin -o stdout > review-changes.html
+
+# Step 5: Commit if satisfied
+git add original.qmd
+git commit -m "Incorporated feedback from reviewer"
+```
+
+---
+
+## 6. Practical Examples and Workflows
+
+This section provides real-world scenarios you're likely to encounter when collaborating with co-authors using Microsoft Word. Each example includes a complete step-by-step workflow you can follow.
+
+---
+
+### Example 1: PhD Student and Advisor
+
+**Scenario**: Sarah is a PhD student writing her dissertation using Quarto. Her advisor, Dr. Johnson, prefers to review drafts in Microsoft Word with Track Changes enabled. Sarah needs to incorporate his feedback efficiently while maintaining her markdown source.
+
+#### Workflow Diagram
+
+```
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β 1. Sarah's Quarto Markdown β 2. Export to Word (.docx) β
+β (chapters/*.qmd) quarto render --to docx β
+ββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββ
+ β
+ β
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β 3. Send to Advisor β
+β Email: dissertation-draft-v1.docx β
+β Note: "Please use Track Changes for all edits" β
+ββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββ
+ β
+ β
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β 4. Advisor Reviews β
+β - Opens in Word β
+β - Enables Track Changes (Review β Track Changes) β
+β - Adds comments and edits β
+β - Saves as: dissertation-draft-v1-reviewed.docx β
+ββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββ
+ β
+ β
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β 5. Sarah Receives Feedback β
+β Downloads: dissertation-draft-v1-reviewed.docx β
+ββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββ
+ β
+ β
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β 6. Review Changes in Word β
+β - Accept/reject each change β
+β - Save final version: dissertation-draft-v1-final.docx β
+ββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββ
+ β
+ β
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β 7. Convert Back to Markdown β
+β pandoc dissertation-draft-v1-final.docx -o reviewed.md β
+ββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββ
+ β
+ β
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β 8. Compare and Merge Changes β
+β - Use git diff or wdiff to compare β
+β - Manually merge changes to .qmd files β
+β - Test: quarto preview β
+ββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββββββ
+ β
+ β
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β 9. Commit to Git β
+β git add chapters/*.qmd β
+β git commit -m "Incorporate advisor feedback from review v1" β
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+```
+
+#### Step-by-Step Instructions
+
+**Step 1: Export your current draft to Word**
+
+```bash
+cd ~/dissertation
+quarto render --to docx
+```
+
+Expected output:
+
+```
+rendering chapters/introduction.qmd
+ to: docx
+ output-file: dissertation.docx
+
+Output created: _book/dissertation.docx
+```
+
+**Step 2: Create a versioned copy for your advisor**
+
+```bash
+cp _book/dissertation.docx _book/dissertation-draft-2024-01-15.docx
+```
+
+> **π‘ Tip**: Always include a date or version number in filenames. This prevents confusion when you have multiple review rounds.
+
+**Step 3: Send to your advisor with clear instructions**
+
+Email template:
+
+```
+Subject: Dissertation Draft - Chapter 1-3 for Review
+
+Hi Dr. Johnson,
+
+I've attached the latest draft of my dissertation (Chapters 1-3) for your review.
+
+Request: Please use Microsoft Word's "Track Changes" feature for all edits:
+ - Review tab β Track Changes β Track Changes (or Ctrl+Shift+E)
+
+Timeline: Could you provide feedback by January 22nd?
+
+File: dissertation-draft-2024-01-15.docx
+
+Thank you!
+Sarah
+```
+
+**Step 4: Receive and organize reviewed file**
+
+```bash
+# Create a reviews folder if it doesn't exist
+mkdir -p reviews
+
+# Save the reviewed file from email
+mv ~/Downloads/dissertation-draft-2024-01-15-reviewed.docx reviews/
+```
+
+**Step 5: Review tracked changes in Word**
+
+Open the file in Microsoft Word and go through each change:
+
+1. **Navigate changes**: Use Review β Next/Previous buttons
+2. **Accept changes**: Review β Accept β Accept This Change (or Accept All)
+3. **Reject changes**: Review β Reject β Reject This Change
+4. **Read comments**: Click on comment bubbles in the margin
+
+> **β οΈ Important**: Don't just "Accept All Changes" without reviewing. Your advisor may have questions or suggestions that need discussion.
+
+**Step 6: Save the final version**
+
+After accepting/rejecting all changes:
+
+```
+File β Save As β dissertation-draft-2024-01-15-final.docx
+```
+
+**Step 7: Convert back to markdown**
+
+```bash
+cd reviews
+pandoc dissertation-draft-2024-01-15-final.docx -o dissertation-reviewed.md
+```
+
+**Step 8: Compare changes with your original**
+
+```bash
+# View word-by-word differences
+wdiff -s ../chapters/introduction.qmd dissertation-reviewed.md
+
+# Or use a visual diff tool
+delta --side-by-side ../chapters/introduction.qmd dissertation-reviewed.md
+```
+
+**Step 9: Manually merge changes into your Quarto files**
+
+Open both files side-by-side and merge changes:
+
+```bash
+# Open in your editor (example with VS Code)
+code ../chapters/introduction.qmd dissertation-reviewed.md
+```
+
+Go through section by section and update your `.qmd` files with the accepted changes.
+
+**Step 10: Test the updated document**
+
+```bash
+cd ..
+quarto preview
+```
+
+Check that:
+- β
All changes are incorporated correctly
+- β
Citations still work
+- β
Figures and tables render properly
+- β
Cross-references are intact
+
+**Step 11: Commit your changes**
+
+```bash
+git add chapters/introduction.qmd chapters/methods.qmd chapters/results.qmd
+git commit -m "Incorporate advisor feedback from Jan 15 review
+
+- Clarified research questions in introduction
+- Added missing methodology details
+- Improved figure captions in results
+- Fixed typos throughout
+
+Reviewer: Dr. Johnson
+Review date: 2024-01-15"
+
+git push origin main
+```
+
+**Step 12: Archive the review artifacts**
+
+```bash
+# Move Word files to an archive folder
+mkdir -p reviews/2024-01-15-advisor-review
+mv reviews/dissertation-draft-2024-01-15* reviews/2024-01-15-advisor-review/
+```
+
+**Expected timeline**: This entire workflow typically takes 1-2 hours after receiving feedback, depending on the number of changes.
+
+---
+
+### Example 2: Research Team with Multiple Reviewers
+
+**Scenario**: Alex is writing a research paper with three co-authors: Dr. Chen (domain expert), Dr. Patel (methods specialist), and Dr. Kim (statistician). Each will review the paper independently in Word and provide feedback.
+
+#### Workflow Diagram
+
+```
+ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β Initial State: Complete Draft in Quarto β
+β research_paper/chapters/*.qmd β
+βββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββ
+ β
+ β
+ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β Export to Word & Create 3 Copies β
+β research-paper-v2-chen.docx β
+β research-paper-v2-patel.docx β
+β research-paper-v2-kim.docx β
+βββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββ
+ β
+ βββββββββββββ¬ββββββββββββ¬βββββββββββββββ
+ β β β β
+ βββββββββββ βββββββββββ βββββββββββ βββββββββββ
+ βDr. Chen β βDr. Patelβ β Dr. Kim β β Alex β
+ β Reviews β β Reviews β β Reviews β β Waits β
+ ββββββ¬βββββ ββββββ¬βββββ ββββββ¬βββββ βββββββββββ
+ β β β
+ βββββββββββββ΄ββββββββββββ
+ β
+ β
+ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β Consolidation Phase β
+β - Process reviews one by one β
+β - Handle conflicts β
+β - Create unified version β
+βββββββββββββββββββββ¬βββββββββββββββββββββββββββββββββββββββββββ
+ β
+ β
+ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β Final Version with All Feedback Integrated β
+β git commit -m "Integrate feedback from all co-authors" β
+ββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+```
+
+#### Step-by-Step Instructions
+
+**Step 1: Prepare for multi-reviewer workflow**
+
+```bash
+cd ~/research_paper
+
+# Create a reviews directory structure
+mkdir -p reviews/round-2/{chen,patel,kim,consolidated}
+
+# Create a tracking spreadsheet
+cat > reviews/round-2/tracking.md << 'EOF'
+# Review Round 2 Tracking
+
+| Reviewer | Sent Date | Due Date | Received | Processed | Notes |
+|------------|------------|------------|----------|-----------|-------|
+| Dr. Chen | 2024-01-20 | 2024-01-27 | β³ | β³ | |
+| Dr. Patel | 2024-01-20 | 2024-01-27 | β³ | β³ | |
+| Dr. Kim | 2024-01-20 | 2024-01-27 | β³ | β³ | |
+
+Last updated: 2024-01-20
+EOF
+```
+
+**Step 2: Export to Word**
+
+```bash
+quarto render --to docx
+```
+
+**Step 3: Create personalized copies for each reviewer**
+
+```bash
+# Copy to each reviewer's folder with their name
+cp _book/research-paper.docx reviews/round-2/chen/research-paper-v2-chen.docx
+cp _book/research-paper.docx reviews/round-2/patel/research-paper-v2-patel.docx
+cp _book/research-paper.docx reviews/round-2/kim/research-paper-v2-kim.docx
+```
+
+> **π‘ Why personalized copies?** This makes it easier to track which file came from which reviewer and prevents confusion when files are returned with the same name.
+
+**Step 4: Send to reviewers with focused instructions**
+
+Email to Dr. Chen (domain expert):
+
+```
+Subject: Research Paper Draft v2 - Domain Expertise Review
+
+Hi Dr. Chen,
+
+I've attached draft v2 of our research paper for your domain expertise review.
+
+Focus areas:
+ - Literature review (Section 2): Are we missing key references?
+ - Problem formulation (Section 3): Is the framing accurate?
+ - Results interpretation (Section 5): Are our conclusions sound?
+
+Please use Track Changes for edits and add comments for questions.
+
+Due date: January 27, 2024
+File: research-paper-v2-chen.docx
+
+Thanks!
+Alex
+```
+
+Email to Dr. Patel (methods specialist):
+
+```
+Subject: Research Paper Draft v2 - Methodology Review
+
+Hi Dr. Patel,
+
+I've attached draft v2 for your methodology review.
+
+Focus areas:
+ - Research design (Section 3.2): Is our approach rigorous?
+ - Data collection (Section 3.3): Any gaps in our protocol?
+ - Analysis methods (Section 4): Are our techniques appropriate?
+
+Please use Track Changes for edits and add comments for questions.
+
+Due date: January 27, 2024
+File: research-paper-v2-patel.docx
+
+Thanks!
+Alex
+```
+
+Email to Dr. Kim (statistician):
+
+```
+Subject: Research Paper Draft v2 - Statistical Review
+
+Hi Dr. Kim,
+
+I've attached draft v2 for your statistical review.
+
+Focus areas:
+ - Statistical tests (Section 4): Are they appropriate for our data?
+ - Tables and figures: Clear and accurate?
+ - Results reporting: Following APA standards?
+
+Please use Track Changes for edits and add comments for questions.
+
+Due date: January 27, 2024
+File: research-paper-v2-kim.docx
+
+Thanks!
+Alex
+```
+
+**Step 5: Track incoming reviews**
+
+As reviews come in, update your tracking file:
+
+```bash
+# When Dr. Chen sends feedback
+mv ~/Downloads/research-paper-v2-chen-reviewed.docx reviews/round-2/chen/
+
+# Update tracking.md
+code reviews/round-2/tracking.md
+# Change Dr. Chen's "Received" to β
+```
+
+**Step 6: Process reviews in priority order**
+
+Start with the most critical reviewer or the one whose changes might conflict with others.
+
+**Process Dr. Chen's feedback first:**
+
+```bash
+cd reviews/round-2/chen
+
+# Accept/reject changes in Word
+# (Open research-paper-v2-chen-reviewed.docx, review changes, save as -final.docx)
+
+# Convert to markdown
+pandoc research-paper-v2-chen-final.docx -o chen-changes.md
+
+# Create a diff report
+diff -u ../../../chapters/literature-review.qmd chen-changes.md > chen-diff.txt
+
+# View the changes
+cat chen-diff.txt
+```
+
+**Step 7: Merge Dr. Chen's changes into your source**
+
+```bash
+cd ../../.. # Back to research_paper/
+
+# Create a branch for this review round
+git checkout -b review-round-2
+git add -A
+git commit -m "Checkpoint before integrating review feedback"
+
+# Open files side-by-side and merge changes
+code chapters/literature-review.qmd reviews/round-2/chen/chen-changes.md
+```
+
+Manually merge changes, then test:
+
+```bash
+quarto preview
+```
+
+Commit Chen's changes:
+
+```bash
+git add chapters/
+git commit -m "Integrate feedback from Dr. Chen
+
+- Added 5 additional key references to literature review
+- Clarified problem formulation in Section 3
+- Revised results interpretation per domain expertise
+- Fixed terminology inconsistencies
+
+Reviewer: Dr. Chen (domain expert)
+Review date: 2024-01-23"
+```
+
+**Step 8: Process Dr. Patel's feedback**
+
+```bash
+cd reviews/round-2/patel
+
+# Accept/reject changes in Word, save as -final.docx
+# Convert to markdown
+pandoc research-paper-v2-patel-final.docx -o patel-changes.md
+
+# Compare with CURRENT version (which now includes Chen's changes)
+cd ../../..
+wdiff chapters/methods.qmd reviews/round-2/patel/patel-changes.md
+```
+
+> **β οΈ Important**: Always compare against your current source files, not the original Word export, to avoid losing previous reviewer's changes.
+
+Merge Patel's changes:
+
+```bash
+code chapters/methods.qmd reviews/round-2/patel/patel-changes.md
+# Manually merge changes
+
+# Test
+quarto preview
+
+# Commit
+git add chapters/methods.qmd
+git commit -m "Integrate feedback from Dr. Patel
+
+- Enhanced methodology section with additional details
+- Clarified data collection protocol
+- Added justification for analysis techniques
+- Fixed methodological terminology
+
+Reviewer: Dr. Patel (methodology specialist)
+Review date: 2024-01-24"
+```
+
+**Step 9: Process Dr. Kim's feedback**
+
+```bash
+cd reviews/round-2/kim
+
+# Accept/reject changes in Word, save as -final.docx
+# Convert to markdown
+pandoc research-paper-v2-kim-final.docx -o kim-changes.md
+
+# Compare with current version
+cd ../../..
+wdiff chapters/results.qmd reviews/round-2/kim/kim-changes.md
+```
+
+Merge Kim's changes:
+
+```bash
+code chapters/results.qmd reviews/round-2/kim/kim-changes.md
+# Manually merge changes
+
+# Test
+quarto preview
+
+# Commit
+git add chapters/results.qmd chapters/analysis.qmd
+git commit -m "Integrate feedback from Dr. Kim
+
+- Corrected statistical test reporting
+- Improved table formatting and clarity
+- Added confidence intervals to all estimates
+- Fixed p-value notation to follow APA style
+
+Reviewer: Dr. Kim (statistician)
+Review date: 2024-01-25"
+```
+
+**Step 10: Handle conflicting feedback (if any)**
+
+If reviewers disagree, document the conflict and your resolution:
+
+```bash
+# Create a conflicts log
+cat > reviews/round-2/consolidated/conflicts-log.md << 'EOF'
+# Conflicting Feedback - Resolution Log
+
+## Conflict 1: Sample Size Discussion
+
+**Dr. Patel suggested**: "Add justification for sample size calculation"
+**Dr. Kim suggested**: "Remove sample size discussion - it's implied by the design"
+
+**Resolution**: Added brief sample size justification (2 sentences) in methods section per Dr. Patel's suggestion, as reviewers often ask for this. Kept it concise per Dr. Kim's concern.
+
+**Rationale**: Transparency is important for reproducibility.
+
+---
+
+## Conflict 2: Figure 3 Placement
+
+**Dr. Chen suggested**: Move Figure 3 to introduction
+**Dr. Patel suggested**: Move Figure 3 to discussion
+
+**Resolution**: Kept Figure 3 in results section (original position).
+
+**Rationale**: Figure 3 shows primary results data, which belongs in results section per journal guidelines. Added forward reference in introduction and backward reference in discussion.
+
+---
+
+Last updated: 2024-01-26
+EOF
+```
+
+**Step 11: Generate a consolidation report**
+
+```bash
+# Create a summary of all changes
+cat > reviews/round-2/consolidated/consolidation-summary.md << 'EOF'
+# Review Round 2 - Consolidation Summary
+
+## Overview
+
+- **Review period**: January 20-27, 2024
+- **Reviewers**: Dr. Chen, Dr. Patel, Dr. Kim
+- **Total changes**: ~150 edits across all chapters
+
+## Changes by Reviewer
+
+### Dr. Chen (Domain Expert)
+- Added 5 key references
+- Clarified problem formulation
+- Revised results interpretation
+- Fixed terminology (12 instances)
+
+### Dr. Patel (Methodology Specialist)
+- Enhanced methodology details
+- Clarified data collection protocol
+- Added analysis justifications
+- Improved methodological clarity
+
+### Dr. Kim (Statistician)
+- Corrected statistical reporting
+- Improved table formatting
+- Added confidence intervals
+- Fixed p-value notation throughout
+
+## Conflicts Resolved
+
+2 conflicts identified and resolved (see conflicts-log.md)
+
+## Next Steps
+
+1. β
All feedback integrated
+2. β³ Final proofread by lead author
+3. β³ Send consolidated version to all co-authors for final approval
+4. β³ Submit to journal
+
+Last updated: 2024-01-26
+EOF
+```
+
+**Step 12: Merge review branch and create tagged version**
+
+```bash
+# Merge review branch back to main
+git checkout main
+git merge review-round-2
+
+# Tag this version
+git tag -a v2.1-post-review -m "Version 2.1: Integrated feedback from all co-authors"
+
+# Push to remote
+git push origin main
+git push origin v2.1-post-review
+```
+
+**Step 13: Send consolidated version to all reviewers**
+
+```bash
+# Export the final version
+quarto render --to docx
+
+# Create final copy
+cp _book/research-paper.docx reviews/round-2/consolidated/research-paper-v2.1-consolidated.docx
+```
+
+Email to all co-authors:
+
+```
+Subject: Research Paper v2.1 - Consolidated Version with All Feedback
+
+Hi team,
+
+Thank you for your thorough reviews! I've integrated all feedback and resolved two minor conflicts (see attached conflicts-log.md).
+
+Attached:
+ - research-paper-v2.1-consolidated.docx (final version)
+ - consolidation-summary.md (overview of all changes)
+ - conflicts-log.md (how conflicts were resolved)
+
+Please review the consolidated version by February 2nd. If you have any concerns about how your feedback was integrated, let me know.
+
+Next step: Submit to journal (target: February 5th)
+
+Best,
+Alex
+```
+
+**Expected timeline**: Processing 3 reviewers' feedback typically takes 4-8 hours of focused work spread over 2-3 days.
+
+---
+
+### Example 3: Handling Conflicting Suggestions
+
+**Scenario**: Maria receives contradictory feedback from two co-authors on the same paragraph. Dr. Lee wants to expand it with more details, while Dr. Brown wants to condense it for brevity. Maria needs to find a solution that satisfies both reviewers.
+
+#### The Conflict
+
+**Original paragraph** (in `chapters/discussion.qmd`):
+
+```markdown
+Our findings suggest that the proposed algorithm outperforms existing methods
+on large-scale datasets. The improvement is particularly notable in scenarios
+with high-dimensional feature spaces.
+```
+
+**Dr. Lee's tracked changes** (expand):
+
+```markdown
+Our findings suggest that the proposed algorithm outperforms existing methods
+on large-scale datasets, achieving a 23% reduction in computational time and
+15% improvement in accuracy compared to the baseline approach (Smith et al., 2023).
+The improvement is particularly notable in scenarios with high-dimensional feature
+spaces (d > 1000), where traditional methods struggle with the curse of dimensionality.
+We observed consistent performance gains across all five benchmark datasets tested.
+```
+
+**Dr. Brown's tracked changes** (condense):
+
+```markdown
+Our algorithm outperforms existing methods on large-scale, high-dimensional datasets.
+```
+
+#### Resolution Strategies
+
+**Strategy 1: Hybrid Approach (Recommended)**
+
+Combine both suggestions by keeping key details but maintaining brevity:
+
+```markdown
+Our algorithm outperforms existing methods on large-scale datasets, achieving
+23% faster computation and 15% better accuracy (Smith et al., 2023). The improvement
+is particularly notable in high-dimensional feature spaces (d > 1000).
+```
+
+**Why this works:**
+- β
Addresses Dr. Lee's request for specific metrics
+- β
Addresses Dr. Brown's request for brevity (3 sentences β 2 sentences)
+- β
Keeps the most important details
+- β
Removes redundant phrases
+
+**Strategy 2: Move Details to Table or Figure**
+
+Keep the paragraph brief (Dr. Brown) but add a table with details (Dr. Lee):
+
+**Updated paragraph:**
+
+```markdown
+Our algorithm outperforms existing methods on large-scale, high-dimensional
+datasets (Table 4).
+```
+
+**New table:**
+
+```markdown
+| Method | Computation Time | Accuracy | Feature Dimensions |
+|--------|------------------|----------|-------------------|
+| Proposed | 1.2 hrs | 94.5% | d > 1000 |
+| Baseline | 1.5 hrs | 79.3% | d > 1000 |
+| Smith et al. | 1.8 hrs | 82.1% | d > 1000 |
+
+Table 4: Performance comparison across high-dimensional datasets.
+```
+
+**Why this works:**
+- β
Main text stays brief (Dr. Brown's preference)
+- β
Details are preserved and expanded (Dr. Lee's preference)
+- β
Table is easier to read than dense prose
+- β
Adds visual interest to the paper
+
+**Strategy 3: Consult Both Reviewers**
+
+When strategies 1 and 2 don't work, ask both reviewers for input:
+
+```
+Subject: Quick Question - Discussion Section Paragraph
+
+Hi Dr. Lee and Dr. Brown,
+
+I received your feedback on the discussion section paragraph about algorithm
+performance. I'd like to get your input on how to best integrate both suggestions:
+
+Dr. Lee suggested: Expand with specific metrics and dataset details
+Dr. Brown suggested: Condense for brevity and clarity
+
+Proposed resolution:
+I've created a hybrid version that includes key metrics (computation time, accuracy)
+but keeps the text concise. I've also added Table 4 with detailed benchmark results.
+
+Could you review my proposed solution (attached) and let me know if this works?
+I aim to balance detail with readability.
+
+Thanks!
+Maria
+```
+
+**Why this works:**
+- β
Shows you value both reviewers' opinions
+- β
Demonstrates you've thought through the issue
+- β
Gets buy-in before finalizing the change
+- β
Prevents future revision rounds
+
+#### Workflow for Handling Conflicts
+
+**Step 1: Identify the conflict**
+
+```bash
+# Compare both reviewers' versions
+cd reviews/
+wdiff lee-version.md brown-version.md > conflict-comparison.txt
+cat conflict-comparison.txt
+```
+
+**Step 2: Document the conflict**
+
+```bash
+# Create a conflicts log
+cat > conflicts-log.md << 'EOF'
+# Conflict Resolution Log
+
+## Conflict: Discussion Section - Algorithm Performance Paragraph
+
+**Location**: chapters/discussion.qmd, lines 45-48
+
+**Dr. Lee's suggestion**: Expand with metrics and dataset details
+**Dr. Brown's suggestion**: Condense for brevity
+
+**Original length**: 3 sentences, 47 words
+**Lee's version**: 6 sentences, 98 words
+**Brown's version**: 1 sentence, 11 words
+
+**Proposed resolution**: Hybrid approach (2 sentences, 35 words) + new Table 4
+
+**Rationale**: Balances detail (Lee) with brevity (Brown). Table format makes
+data easier to read than prose.
+
+**Status**: Pending reviewer approval
+EOF
+```
+
+**Step 3: Create proposed solution**
+
+```bash
+# Edit the file with your proposed solution
+code chapters/discussion.qmd
+
+# Test the rendering
+quarto preview
+```
+
+**Step 4: Send for approval**
+
+```bash
+# Create a Word version showing your proposed resolution
+quarto render chapters/discussion.qmd --to docx
+
+# Highlight the changed paragraph in Word
+# Add a comment explaining your reasoning
+```
+
+**Step 5: Implement after approval**
+
+```bash
+# Once approved, commit the change
+git add chapters/discussion.qmd
+git commit -m "Resolve conflicting feedback on discussion paragraph
+
+Conflict between Dr. Lee (expand) and Dr. Brown (condense).
+
+Resolution:
+- Used hybrid approach: brief text + detailed table
+- Kept key metrics (23% speedup, 15% accuracy gain)
+- Reduced word count by 25% vs. Lee's version
+- Added 275% more info vs. Brown's version
+- Created Table 4 with benchmark details
+
+Approved by: Dr. Lee (2024-01-28), Dr. Brown (2024-01-28)"
+```
+
+#### Common Conflict Patterns and Solutions
+
+| Conflict Type | Example | Resolution Strategy |
+|---------------|---------|---------------------|
+| **Detail vs. Brevity** | One wants more info, one wants less | Hybrid text + move details to table/figure |
+| **Terminology** | One prefers "algorithm", one prefers "method" | Use both terms or choose journal's style guide |
+| **Tone** | One wants formal, one wants accessible | Aim for "professional but clear" |
+| **Section placement** | Disagree on where content belongs | Follow journal's structure guidelines |
+| **Citation style** | Different interpretation of same source | Add both citations or use the more recent one |
+| **Figure design** | Different preferences for visualization | A/B test with 3rd party or use journal examples |
+
+#### Template Email for Conflict Resolution
+
+```
+Subject: Feedback Conflict - Need Your Input
+
+Hi [Reviewer 1] and [Reviewer 2],
+
+I've received your feedback on [specific section/paragraph]. I notice you have
+different perspectives on how to improve this section:
+
+[Reviewer 1] suggested: [brief summary]
+[Reviewer 2] suggested: [brief summary]
+
+Both suggestions have merit. I've created three possible solutions:
+
+Option A: [description]
+ Pros: [benefits]
+ Cons: [drawbacks]
+
+Option B: [description]
+ Pros: [benefits]
+ Cons: [drawbacks]
+
+Option C: [description]
+ Pros: [benefits]
+ Cons: [drawbacks]
+
+My recommendation: Option [X] because [rationale]
+
+Could you let me know which option you prefer, or if you'd like to suggest
+a different approach? I'd like to resolve this by [date] so we can stay on
+track for submission.
+
+Attached: Document showing all three options side-by-side
+
+Thanks for your flexibility!
+[Your name]
+```
+
+---
+
+### Quick Reference Commands
+
+This section provides a cheat sheet of the most commonly used commands in Word-based collaboration workflows. Copy and paste these commands into your terminal.
+
+#### Export to Word
+
+```bash
+# Basic export
+quarto render --to docx
+
+# Export specific chapter
+quarto render chapters/introduction.qmd --to docx
+
+# Export with custom reference document
+quarto render --to docx --reference-doc custom-template.docx
+
+# Export all formats (HTML, PDF, Word)
+quarto render
+```
+
+#### File Organization
+
+```bash
+# Create review directory structure
+mkdir -p reviews/{round-1,round-2,round-3}/{received,processed,consolidated}
+
+# Copy export to review folder with date
+cp _book/paper.docx reviews/round-1/paper-$(date +%Y-%m-%d).docx
+
+# Archive old reviews
+mv reviews/round-1 reviews/archive/round-1-$(date +%Y-%m-%d)
+```
+
+#### Converting Word to Markdown
+
+```bash
+# Basic conversion
+pandoc reviewed-paper.docx -o reviewed-paper.md
+
+# Preserve citations
+pandoc reviewed-paper.docx --citeproc -o reviewed-paper.md
+
+# Extract images to folder
+pandoc reviewed-paper.docx --extract-media=./media -o reviewed-paper.md
+
+# Convert multiple files in batch
+for file in reviews/*.docx; do
+ pandoc "$file" -o "${file%.docx}.md"
+done
+```
+
+#### Comparing Versions
+
+```bash
+# Quick check if files differ
+diff -q original.qmd reviewed.md
+
+# Word-by-word comparison with statistics
+wdiff -s original.qmd reviewed.md
+
+# Side-by-side visual comparison
+delta --side-by-side original.qmd reviewed.md
+
+# Generate HTML diff report
+diff -u original.qmd reviewed.md | diff2html -i stdin -o file -F diff-report.html
+
+# Git-based comparison
+git diff --word-diff original.qmd reviewed.md
+```
+
+#### Git Workflow
+
+```bash
+# Create branch for review round
+git checkout -b review-round-2
+
+# Checkpoint before major changes
+git add -A
+git commit -m "Checkpoint before integrating feedback"
+
+# Commit with detailed message
+git add chapters/introduction.qmd
+git commit -m "Incorporate reviewer feedback
+
+- Added clarification on research questions
+- Fixed typos (15 instances)
+- Improved figure captions
+
+Reviewer: Dr. Smith
+Review date: 2024-01-20"
+
+# Tag major versions
+git tag -a v1.0-pre-review -m "Version before peer review"
+git tag -a v1.1-post-review -m "Version after incorporating peer review"
+
+# View commit history for a file
+git log --oneline chapters/introduction.qmd
+
+# Compare current version with previous commit
+git diff HEAD~1 chapters/introduction.qmd
+```
+
+#### Testing and Validation
+
+```bash
+# Preview in browser
+quarto preview
+
+# Check for broken cross-references
+quarto render --to html 2>&1 | grep -i "warning\|error"
+
+# Validate bibliography
+quarto render --to docx 2>&1 | grep -i "citation"
+
+# Count words in markdown files
+wc -w chapters/*.qmd
+
+# Find TODO comments left by reviewers
+grep -rn "TODO\|FIXME\|XXX" chapters/
+```
+
+#### Batch Processing Multiple Reviews
+
+```bash
+# Process all received Word files
+for file in reviews/received/*.docx; do
+ basename=$(basename "$file" .docx)
+ echo "Processing $basename..."
+
+ # Convert to markdown
+ pandoc "$file" -o "reviews/processed/${basename}.md"
+
+ # Create diff report
+ diff -u chapters/original.qmd "reviews/processed/${basename}.md" > "reviews/processed/${basename}.diff"
+
+ echo "β
Processed $basename"
+done
+
+echo "All reviews processed!"
+```
+
+#### Utilities
+
+```bash
+# Check Quarto version
+quarto --version
+
+# Check Pandoc version
+pandoc --version
+
+# List all docx files with timestamps
+find reviews/ -name "*.docx" -type f -exec ls -lh {} \;
+
+# Count tracked changes in Word (macOS with textutil)
+textutil -convert txt reviewed.docx -stdout | grep -c "\[Deleted:\|Added:"
+
+# Find large Word files (> 10MB)
+find reviews/ -name "*.docx" -size +10M
+```
+
+#### Common One-Liners
+
+```bash
+# Export, copy to review folder, open in Finder (macOS)
+quarto render --to docx && cp _book/paper.docx reviews/ && open reviews/
+
+# Convert Word to markdown and compare
+pandoc reviewed.docx -o reviewed.md && wdiff -s original.qmd reviewed.md
+
+# Check for conflicts between two reviewers
+wdiff reviews/reviewer1.md reviews/reviewer2.md | grep -E "\[-|\{\+"
+
+# Create dated backup before incorporating feedback
+tar -czf backup-$(date +%Y-%m-%d).tar.gz chapters/
+
+# Quick word count comparison
+echo "Original: $(wc -w < original.qmd) words" && echo "Reviewed: $(wc -w < reviewed.md) words"
+```
+
+#### Troubleshooting Commands
+
+```bash
+# Check if Track Changes are still in Word file
+strings reviewed.docx | grep -i "revision"
+
+# Verify citations are rendering
+quarto render chapters/intro.qmd --to docx && strings _book/intro.docx | grep -i "references"
+
+# Check for corrupted Word files
+file *.docx
+
+# Find files modified in last 7 days
+find reviews/ -name "*.docx" -mtime -7
+
+# Check disk space in reviews folder
+du -sh reviews/
+```
+
+---
+
+### Workflow Visualization
+
+Here's a visual summary of the complete collaboration workflow:
+
+```
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+β COLLABORATION WORKFLOW β
+βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
+
+ YOU (Quarto User) CO-AUTHOR (Word User)
+ βββββββββββββββββ βββββββββββββββββββββ
+
+ β Write in Quarto
+ β (.qmd files)
+ β
+ βββββββββββββββ
+ β quarto β
+ β render β
+ β --to docx β
+ ββββββββ¬βββββββ
+ β
+ β
+ βββββββββββββββ
+ β .docx file β
+ β exported β
+ ββββββββ¬βββββββ
+ β
+ β Email or share βββββββββββββββββββββ β
+ β β
+ β βββββββββββββββ
+ β β Opens in β
+ β β Word β
+ β ββββββββ¬βββββββ
+ β β
+ β β
+ β βββββββββββββββ
+ β β Track β
+ β β Changes ON β
+ β ββββββββ¬βββββββ
+ β β
+ β β
+ β βββββββββββββββ
+ β β Makes edits β
+ β β & comments β
+ β ββββββββ¬βββββββ
+ β β
+ β β
+ β βββββββββββββββ
+ β β Saves as β
+ β β *-reviewed β
+ β ββββββββ¬βββββββ
+ β β
+ β ββββββββββββββββββββββββββββββββββββββ β Email back
+ β
+ β
+ βββββββββββββββ
+ β Review β
+ β changes in β
+ β Word β
+ ββββββββ¬βββββββ
+ β
+ β
+ βββββββββββββββ
+ β Accept/ β
+ β Reject β
+ β changes β
+ ββββββββ¬βββββββ
+ β
+ β
+ βββββββββββββββ
+ β pandoc β
+ β convert to β
+ β markdown β
+ ββββββββ¬βββββββ
+ β
+ β
+ βββββββββββββββ
+ β Compare & β
+ β merge to β
+ β .qmd source β
+ ββββββββ¬βββββββ
+ β
+ β
+ βββββββββββββββ
+ β git commit β
+ β with messageβ
+ ββββββββ¬βββββββ
+ β
+ β
+ βββββββββββββββ
+ β Next round β
+ β or publish β
+ βββββββββββββββ
+```
+
+---
+
+## 7. Platform-Specific Instructions
+
+This section provides platform-specific guidance for collaborating with Word users on macOS, Windows, and Linux. Each platform has different tools available, file path conventions, and compatibility considerations.
+
+---
+
+### macOS
+
+#### Microsoft Word Compatibility
+
+**Native Word:**
+
+If you have Microsoft Word for Mac installed, the collaboration workflow is seamless:
+
+```bash
+# Open the exported Word document directly
+open _book/Research-Paper-Title.docx
+
+# Or specify Word explicitly
+open -a "Microsoft Word" _book/Research-Paper-Title.docx
+```
+
+**Alternatives if you don't have Word:**
+
+1. **Apple Pages** (Free, pre-installed):
+ ```bash
+ # Open Word document in Pages
+ open -a Pages _book/Research-Paper-Title.docx
+ ```
+
+ Pages can open and edit `.docx` files with good fidelity. However:
+ - β
Preserves most formatting, comments, and basic tracked changes
+ - β οΈ Complex tracked changes may not display correctly
+ - β οΈ Save as `.docx` when done to maintain compatibility
+
+ **Best practice**: Use Pages for reviewing and light editing, but warn collaborators that complex tracked changes should be made in Word.
+
+2. **Google Docs** (Free, web-based):
+ ```bash
+ # Upload to Google Drive and open in browser
+ open "https://drive.google.com/drive/my-drive"
+ ```
+
+ - β
Excellent Track Changes support (called "Suggesting mode")
+ - β
Real-time collaboration
+ - β οΈ Some advanced Word formatting may be lost
+ - π‘ Export back to `.docx` when done: File β Download β Microsoft Word (.docx)
+
+3. **LibreOffice** (Free, open-source):
+ ```bash
+ # Install via Homebrew
+ brew install --cask libreoffice
+
+ # Open document
+ open -a LibreOffice _book/Research-Paper-Title.docx
+ ```
+
+#### Command-Line Differences
+
+**File paths:**
+
+macOS uses forward slashes and is case-sensitive by default:
+
+```bash
+# Navigate to paper directory
+cd research_paper
+
+# Render to Word
+quarto render --to docx
+
+# Find generated files
+ls -la _book/*.docx
+
+# Copy to shared folder
+cp _book/Paper-v1.docx ~/Desktop/
+```
+
+**Comparing documents:**
+
+```bash
+# Using diff for text-based comparison
+diff <(cat version1.docx) <(cat version2.docx)
+
+# Using macOS-specific comparison
+cmp -l version1.docx version2.docx
+
+# Visual diff (if you have a diff tool installed)
+# Install via: brew install --cask diffmerge
+diffmerge _book/version1.docx _book/version2.docx
+```
+
+**Shell scripts:**
+
+The helper scripts use bash, which is compatible with macOS:
+
+```bash
+# Make script executable (if needed)
+chmod +x helper.sh
+
+# Run helper commands
+./helper.sh build-paper
+./helper.sh serve-paper
+```
+
+**Note**: macOS Catalina (10.15) and later use `zsh` as the default shell instead of `bash`, but bash scripts still work fine.
+
+#### macOS-Specific Tips
+
+1. **Finder integration**:
+ - Right-click `.docx` files and choose "Open With" to select your preferred application
+ - Set default application: Right-click β Get Info β Open with: β Select app β Change All...
+
+2. **Quick Look**:
+ - Press `Spacebar` while selecting a `.docx` file in Finder to preview without opening
+
+3. **Spotlight search**:
+ ```bash
+ # Find all Word documents in your project
+ mdfind -onlyin . "kMDItemContentType == 'org.openxmlformats.wordprocessingml.document'"
+ ```
+
+4. **Automation with AppleScript** (advanced):
+ ```applescript
+ # Example: Open Word document and activate Track Changes
+ tell application "Microsoft Word"
+ open POSIX file "/path/to/document.docx"
+ activate
+ set track revisions of active document to true
+ end tell
+ ```
+
+---
+
+### Windows
+
+#### Microsoft Word Compatibility
+
+**Native Word:**
+
+Windows users typically have Microsoft Word installed, making this the most straightforward platform:
+
+```powershell
+# Open the exported Word document
+start _book\Research-Paper-Title.docx
+
+# Or open with Word explicitly
+start winword.exe _book\Research-Paper-Title.docx
+```
+
+**Alternatives if you don't have Word:**
+
+1. **Office Online** (Free, web-based):
+ - Upload to OneDrive: [https://onedrive.live.com](https://onedrive.live.com)
+ - β
Full Word compatibility
+ - β
Complete Track Changes support
+ - β οΈ Requires internet connection
+ - π‘ Best free option for Windows users
+
+2. **LibreOffice** (Free, open-source):
+ ```powershell
+ # Download from: https://www.libreoffice.org/download/download/
+ # After installation, open document
+ start LibreOffice _book\Research-Paper-Title.docx
+ ```
+
+#### Command-Line Differences
+
+**PowerShell vs Command Prompt:**
+
+Windows has two command-line interfaces. Use PowerShell for better compatibility with modern workflows:
+
+**PowerShell commands:**
+
+```powershell
+# Navigate to paper directory
+cd research_paper
+
+# Render to Word
+quarto render --to docx
+
+# List generated files
+Get-ChildItem _book\*.docx
+
+# Copy to shared folder
+Copy-Item _book\Paper-v1.docx ~\Desktop\
+```
+
+**Command Prompt (cmd.exe) commands:**
+
+```cmd
+REM Navigate to paper directory
+cd research_paper
+
+REM Render to Word
+quarto render --to docx
+
+REM List generated files
+dir _book\*.docx
+
+REM Copy to shared folder
+copy _book\Paper-v1.docx %USERPROFILE%\Desktop\
+```
+
+**File paths:**
+
+Windows uses backslashes and is case-insensitive:
+
+```powershell
+# Both of these work the same
+cd C:\Users\YourName\research_paper
+cd c:\users\yourname\RESEARCH_PAPER
+
+# Quarto handles forward slashes too
+quarto render --to docx
+```
+
+**Note**: In Quarto configuration files (`_quarto.yml`) and `.qmd` documents, always use forward slashes `/` for paths, even on Windows. Quarto converts them automatically.
+
+#### Windows-Specific Tips
+
+1. **File associations**:
+ - Right-click `.docx` β Open with β Choose another app β Select Word/LibreOffice
+ - Check "Always use this app" to set default
+
+2. **Windows Subsystem for Linux (WSL)**:
+
+ If you're using WSL for development but need to open Word documents:
+
+ ```bash
+ # From WSL, open file in Windows
+ explorer.exe _book/Research-Paper-Title.docx
+
+ # Or convert WSL path to Windows path
+ wslpath -w ~/research_paper/_book/Paper.docx
+ # Returns: \\wsl$\Ubuntu\home\user\research_paper\_book\Paper.docx
+ ```
+
+3. **PowerShell profile customization**:
+
+ Add helpful aliases to your PowerShell profile:
+
+ ```powershell
+ # Edit profile
+ notepad $PROFILE
+
+ # Add these lines
+ function Render-Paper {
+ cd research_paper
+ quarto render --to docx
+ start _book\Research-Paper-Title.docx
+ }
+
+ Set-Alias qword Render-Paper
+ ```
+
+ Now you can type `qword` to render and open in one command.
+
+4. **Track Changes keyboard shortcut**:
+ - `Ctrl+Shift+E` - Toggle Track Changes in Word
+ - Train collaborators to use this shortcut
+
+5. **Comparing documents in Word**:
+ ```powershell
+ # Word has excellent built-in comparison
+ # No command-line needed - use Word's UI:
+ # Review tab β Compare β Compare... β Select two documents
+ ```
+
+6. **Path length limitations**:
+
+ Windows has a 260-character path limit (though this is relaxed in Windows 10+). Keep your project directory shallow:
+
+ ```powershell
+ # Good
+ C:\projects\research_paper\
+
+ # Problematic
+ C:\Users\YourName\Documents\Projects\Research\2026\Paper-Draft\research_paper\
+ ```
+
+---
+
+### Linux
+
+#### Microsoft Word Compatibility
+
+Linux does not have native Microsoft Word, so you'll need alternatives:
+
+**Recommended Options:**
+
+1. **LibreOffice Writer** (Best native option):
+ ```bash
+ # Install on Ubuntu/Debian
+ sudo apt-get update
+ sudo apt-get install libreoffice-writer
+
+ # Install on Fedora
+ sudo dnf install libreoffice-writer
+
+ # Install on Arch
+ sudo pacman -S libreoffice-fresh
+
+ # Open document
+ libreoffice --writer _book/Research-Paper-Title.docx
+ ```
+
+ LibreOffice compatibility with Word:
+ - β
Excellent `.docx` support (reads and writes)
+ - β
Track Changes fully supported (called "Record Changes")
+ - β
Comments work well
+ - β οΈ Complex formatting may have minor differences
+ - π‘ **Best practice**: Save as `.docx` format, not LibreOffice's native `.odt`
+
+2. **OnlyOffice** (High Word compatibility):
+ ```bash
+ # Install via Flatpak (works on all distros)
+ flatpak install flathub org.onlyoffice.desktopeditors
+
+ # Open document
+ flatpak run org.onlyoffice.desktopeditors _book/Research-Paper-Title.docx
+ ```
+
+ - β
Very high Word compatibility
+ - β
Modern, familiar interface
+ - β
Excellent Track Changes support
+
+3. **Google Docs** (Web-based):
+ ```bash
+ # Upload to Google Drive and open in browser
+ xdg-open "https://drive.google.com/drive/my-drive"
+ ```
+
+ - β
Best online option for Linux
+ - β
Full Track Changes support
+
+4. **Office 365 Web** (Web-based):
+ ```bash
+ # Access via browser
+ xdg-open "https://www.office.com"
+ ```
+
+ - β
Full Word compatibility (it IS Word)
+ - β οΈ Requires Microsoft 365 subscription
+
+#### Command-Line Differences
+
+**File paths:**
+
+Linux uses forward slashes and is case-sensitive:
+
+```bash
+# Navigate to paper directory
+cd research_paper
+
+# Render to Word
+quarto render --to docx
+
+# List generated files
+ls -lh _book/*.docx
+
+# Copy to shared folder
+cp _book/Paper-v1.docx ~/Desktop/
+```
+
+**Shell variations:**
+
+Most Linux distributions use bash by default, but you might encounter:
+
+```bash
+# Check your shell
+echo $SHELL
+
+# Common shells: bash, zsh, fish
+
+# Helper scripts work with bash
+./helper.sh build-paper
+
+# If you're using a different shell, you can run explicitly
+bash helper.sh build-paper
+```
+
+**Opening files:**
+
+```bash
+# Generic "open with default app" command
+xdg-open _book/Research-Paper-Title.docx
+
+# Open with specific application
+libreoffice --writer _book/Research-Paper-Title.docx
+
+# Or
+onlyoffice _book/Research-Paper-Title.docx
+```
+
+**Comparing documents:**
+
+Linux has excellent command-line diff tools:
+
+```bash
+# Text-based comparison
+diff -u version1.docx version2.docx
+
+# Side-by-side comparison
+diff -y version1.docx version2.docx
+
+# Word count differences
+wc -w version1.docx version2.docx
+
+# Visual diff tools
+# Meld (install: sudo apt install meld)
+meld _book/version1.docx _book/version2.docx
+
+# KDiff3 (install: sudo apt install kdiff3)
+kdiff3 _book/version1.docx _book/version2.docx
+```
+
+#### Linux-Specific Tips
+
+1. **Set default application for .docx files**:
+ ```bash
+ # Set LibreOffice as default
+ xdg-mime default libreoffice-writer.desktop application/vnd.openxmlformats-officedocument.wordprocessingml.document
+
+ # Verify
+ xdg-mime query default application/vnd.openxmlformats-officedocument.wordprocessingml.document
+ ```
+
+2. **File manager integration**:
+
+ Most Linux file managers support right-click β Open With. Configure your preferred app there.
+
+3. **Command-line document conversion** (advanced):
+
+ LibreOffice has a powerful headless mode for automation:
+
+ ```bash
+ # Convert Word to PDF
+ libreoffice --headless --convert-to pdf _book/Paper.docx
+
+ # Convert multiple formats
+ for file in _book/*.docx; do
+ libreoffice --headless --convert-to pdf "$file"
+ done
+
+ # Enable Track Changes via command line (requires macro)
+ # See: https://ask.libreoffice.org/en/question/
+ ```
+
+4. **Wine for running Windows Word** (not recommended):
+
+ While you *can* run Windows Word on Linux via Wine, it's not recommended due to stability issues. Use LibreOffice or OnlyOffice instead.
+
+5. **Pandoc for advanced conversions**:
+
+ Quarto uses Pandoc under the hood, but you can use it directly for fine-grained control:
+
+ ```bash
+ # Convert markdown to Word with custom reference
+ pandoc input.md -o output.docx --reference-doc=custom-reference.docx
+
+ # Convert Word back to markdown
+ pandoc input.docx -o output.md
+
+ # Extract text from Word document
+ pandoc -f docx -t plain input.docx
+ ```
+
+6. **Handling collaborator concerns**:
+
+ Some collaborators may worry about compatibility. You can reassure them:
+
+ > "I'm using LibreOffice on Linux, which has excellent compatibility with Word's .docx format. Your Track Changes and comments will work perfectly. Microsoft's own compatibility testing shows 99%+ format preservation between Word and LibreOffice for standard documents."
+
+7. **Bash aliases for common workflows**:
+
+ Add to your `~/.bashrc` or `~/.bash_aliases`:
+
+ ```bash
+ # Edit .bashrc
+ nano ~/.bashrc
+
+ # Add these lines
+ alias qword='quarto render --to docx && xdg-open _book/*.docx'
+ alias qpaper='cd ~/research_paper && quarto render --to docx'
+ alias checkdocx='ls -lh _book/*.docx'
+
+ # Reload
+ source ~/.bashrc
+ ```
+
+8. **Automated Word exports via cron** (advanced):
+
+ Auto-generate Word exports on a schedule:
+
+ ```bash
+ # Edit crontab
+ crontab -e
+
+ # Add line to render every day at 6 AM
+ 0 6 * * * cd /home/user/research_paper && quarto render --to docx
+ ```
+
+#### Distribution-Specific Notes
+
+**Ubuntu/Debian:**
+```bash
+# All dependencies via apt
+sudo apt-get install quarto libreoffice-writer pandoc
+```
+
+**Fedora/RHEL:**
+```bash
+# Quarto from their website, LibreOffice via dnf
+sudo dnf install libreoffice-writer pandoc
+```
+
+**Arch Linux:**
+```bash
+# Use AUR for Quarto, pacman for the rest
+yay -S quarto-cli
+sudo pacman -S libreoffice-fresh pandoc
+```
+
+**NixOS:**
+```nix
+# Add to configuration.nix
+environment.systemPackages = with pkgs; [
+ quarto
+ libreoffice
+ pandoc
+];
+```
+
+---
+
+## 8. Troubleshooting Common Issues
+
+This section addresses common problems you might encounter when collaborating with co-authors using Microsoft Word. Each issue includes symptoms, root causes, and step-by-step solutions.
+
+---
+
+### Citations Not Rendering in Word
+
+#### Symptoms
+
+- Citations appear as `[@smith2023]` instead of formatted references
+- Bibliography section is missing at the end of the document
+- Reference numbers show as `[?]` or are missing entirely
+- Word document shows raw citation keys instead of formatted citations
+
+#### Root Causes
+
+1. **Bibliography file not specified**: Quarto couldn't find your `.bib` file
+2. **Citeproc not enabled**: Citation processing was disabled
+3. **Invalid BibTeX entries**: Syntax errors in your `.bib` file
+4. **Citation keys mismatch**: Keys in text don't match `.bib` file entries
+
+#### Solutions
+
+**Solution 1: Verify bibliography configuration in `_quarto.yml`**
+
+```yaml
+bibliography: references.bib
+csl: ieee.csl # Optional: citation style
+```
+
+Make sure the `references.bib` file exists and the path is correct.
+
+**Solution 2: Check for BibTeX syntax errors**
+
+```bash
+# Validate your BibTeX file
+bibtex-check references.bib
+
+# Or manually check for common issues
+grep -n "@" references.bib
+```
+
+Common BibTeX errors to look for:
+- Missing closing braces `}`
+- Missing commas between fields
+- Invalid entry types (use `@article`, `@book`, etc.)
+- Special characters not escaped
+
+**Solution 3: Render with verbose output**
+
+```bash
+# See detailed citation processing logs
+quarto render --to docx --verbose
+
+# Look for citation-related warnings
+quarto render --to docx 2>&1 | grep -i "citation\|bibliography"
+```
+
+**Solution 4: Force citation processing**
+
+Add to your document YAML header:
+
+```yaml
+---
+title: "My Paper"
+bibliography: references.bib
+citeproc: true
+---
+```
+
+**Solution 5: Test with a minimal example**
+
+Create a test file `test.qmd`:
+
+```markdown
+---
+title: "Citation Test"
+bibliography: references.bib
+---
+
+# Test
+
+This is a test citation [@test2023].
+
+# References
+```
+
+And a minimal `references.bib`:
+
+```bibtex
+@article{test2023,
+ author = {Test Author},
+ title = {Test Title},
+ journal = {Test Journal},
+ year = {2023}
+}
+```
+
+Render it:
+
+```bash
+quarto render test.qmd --to docx
+```
+
+If this works, the issue is in your main bibliography file. Compare the working minimal example with your full setup.
+
+**Solution 6: Re-export with explicit bibliography rendering**
+
+```bash
+# Clean build cache
+rm -rf _book/ .quarto/
+
+# Render with explicit citeproc
+quarto render --to docx --metadata citeproc=true
+```
+
+**Solution 7: Check citation key formatting**
+
+Ensure citations in your text follow Pandoc syntax:
+- Correct: `[@smith2023]`, `@smith2023`, `[@smith2023; @jones2024]`
+- Incorrect: `[smith2023]`, `{smith2023}`, `(@smith2023)`
+
+**Verification:**
+
+After fixing, your Word document should show:
+- Formatted citations in text (e.g., "[1]" for IEEE style or "Smith et al. (2023)" for APA)
+- Complete References section at the end
+- All citations linked to bibliography entries
+
+---
+
+### Formatting Lost During Export
+
+#### Symptoms
+
+- Headings appear as plain text
+- Bullet lists lose indentation
+- Code blocks lose syntax highlighting
+- Tables have no borders
+- Images are incorrectly sized or missing
+- Custom styles from your Quarto document don't appear in Word
+
+#### Root Causes
+
+1. **No custom reference document**: Using Word's default styles
+2. **Quarto version incompatibility**: Older Quarto versions have export bugs
+3. **Complex formatting**: Some Quarto features don't translate to Word
+4. **Corrupted cache**: Stale build artifacts
+
+#### Solutions
+
+**Solution 1: Create and use a custom Word template**
+
+Step 1: Generate a default reference document:
+
+```bash
+quarto pandoc -o custom-reference.docx --print-default-data-file reference.docx
+```
+
+Step 2: Open `custom-reference.docx` in Word and customize:
+- Heading styles (Heading 1, Heading 2, etc.)
+- Body text font and size
+- Code block formatting (style name: "Source Code")
+- Table styles
+- Page margins and headers/footers
+
+Step 3: Save and reference it in `_quarto.yml`:
+
+```yaml
+format:
+ docx:
+ reference-doc: custom-reference.docx
+```
+
+Step 4: Re-render:
+
+```bash
+quarto render --to docx
+```
+
+**Solution 2: Update Quarto to latest version**
+
+```bash
+# Check current version
+quarto --version
+
+# Update Quarto (macOS with Homebrew)
+brew upgrade quarto
+
+# Update Quarto (Linux)
+# Download latest from https://quarto.org/docs/get-started/
+wget https://github.com/quarto-dev/quarto-cli/releases/download/v1.4.549/quarto-1.4.549-linux-amd64.deb
+sudo dpkg -i quarto-1.4.549-linux-amd64.deb
+
+# Update Quarto (Windows with Chocolatey)
+choco upgrade quarto
+
+# Verify new version
+quarto --version
+```
+
+**Solution 3: Clear build cache and re-render**
+
+```bash
+# Remove cached files
+rm -rf _book/ .quarto/
+
+# Clean render
+quarto render --to docx
+```
+
+**Solution 4: Enhance formatting with specific Quarto options**
+
+In `_quarto.yml`:
+
+```yaml
+format:
+ docx:
+ toc: true
+ toc-depth: 3
+ number-sections: true
+ highlight-style: github
+ fig-width: 6.5
+ fig-height: 4.5
+ fig-dpi: 300
+ df-print: kable
+ reference-doc: custom-reference.docx
+```
+
+**Solution 5: Handle specific formatting issues**
+
+**Tables losing borders:**
+
+Add to your table in markdown:
+
+```markdown
+| Column 1 | Column 2 |
+|----------|----------|
+| Data 1 | Data 2 |
+
+: Table caption {#tbl-example}
+```
+
+Or use grid tables for complex formatting:
+
+```markdown
++----------+----------+
+| Column 1 | Column 2 |
++==========+==========+
+| Data 1 | Data 2 |
++----------+----------+
+
+: Table caption
+```
+
+**Code blocks losing formatting:**
+
+In your custom reference document, format the "Source Code" style:
+1. Open `custom-reference.docx`
+2. Go to Home β Styles β Manage Styles
+3. Find "Source Code"
+4. Set font to monospace (e.g., Consolas, Courier New)
+5. Set background color (light gray recommended)
+6. Save the reference document
+
+**Images incorrectly sized:**
+
+Use explicit figure attributes:
+
+```markdown
+{width=80% #fig-example}
+```
+
+Or in YAML:
+
+```yaml
+format:
+ docx:
+ fig-width: 6
+ fig-height: 4
+```
+
+**Solution 6: Test formatting with a simple document**
+
+Create `format-test.qmd`:
+
+```markdown
+---
+title: "Format Test"
+format:
+ docx:
+ reference-doc: custom-reference.docx
+---
+
+# Level 1 Heading
+
+## Level 2 Heading
+
+Regular paragraph text with **bold** and *italic*.
+
+- Bullet item 1
+ - Nested item
+- Bullet item 2
+
+1. Numbered item 1
+2. Numbered item 2
+
+```python
+# Code block
+def test():
+ return "formatted"
+```
+
+| Column A | Column B |
+|----------|----------|
+| Cell 1 | Cell 2 |
+```
+
+Render and check each element:
+
+```bash
+quarto render format-test.qmd --to docx
+open _book/format-test.docx
+```
+
+**Solution 7: Use Pandoc directly for debugging**
+
+```bash
+# Export using Pandoc directly
+quarto pandoc -o output.docx -f markdown -t docx input.qmd
+
+# With custom reference document
+quarto pandoc -o output.docx --reference-doc=custom-reference.docx input.qmd
+```
+
+**Verification:**
+
+After fixing, your Word document should have:
+- β
Properly styled headings with hierarchy
+- β
Formatted bullet and numbered lists
+- β
Syntax-highlighted code blocks
+- β
Tables with borders and proper alignment
+- β
Images at correct sizes with captions
+- β
Consistent fonts and spacing throughout
+
+---
+
+### Merge Conflicts
+
+#### Symptoms
+
+- Different reviewers edited the same paragraph with contradictory changes
+- Git shows merge conflicts when trying to combine branches
+- Manual merge is confusing due to overlapping edits
+- Lost track of which reviewer's changes have been incorporated
+- Accidentally overwrote previous reviewer's feedback
+
+#### Root Causes
+
+1. **Multiple reviewers editing the same content**: Natural when multiple people review the same document
+2. **Sequential merge without tracking**: Not using branches or version control properly
+3. **No change tracking system**: Merging without documenting what was changed by whom
+4. **Timing issues**: Reviewers working from different base versions
+
+#### Solutions
+
+**Solution 1: Use Git branches for each reviewer**
+
+```bash
+# Create a branch for each review round
+git checkout -b review-round-1
+git commit -m "Checkpoint before review round 1"
+
+# As each reviewer's feedback comes in, create sub-branches
+git checkout -b review-round-1-chen
+# Merge Dr. Chen's changes
+git add chapters/
+git commit -m "Integrated Dr. Chen's feedback"
+
+git checkout review-round-1
+git checkout -b review-round-1-patel
+# Merge Dr. Patel's changes
+git add chapters/
+git commit -m "Integrated Dr. Patel's feedback"
+
+# Merge both into review-round-1 branch
+git checkout review-round-1
+git merge review-round-1-chen
+git merge review-round-1-patel # This may show conflicts
+
+# Resolve conflicts if any
+# Then merge back to main
+git checkout main
+git merge review-round-1
+```
+
+**Solution 2: Process reviews sequentially, not in parallel**
+
+Instead of trying to merge all reviews at once:
+
+```bash
+# Process reviews one at a time
+# Step 1: Integrate Reviewer 1's changes
+git checkout -b integrate-reviewer1
+# Make changes
+git commit -m "Integrated Reviewer 1 feedback"
+git checkout main
+git merge integrate-reviewer1
+
+# Step 2: Export new version for Reviewer 2 to work from
+quarto render --to docx
+# Send to Reviewer 2
+
+# Step 3: Integrate Reviewer 2's changes (based on version that includes Reviewer 1's changes)
+git checkout -b integrate-reviewer2
+# Make changes
+git commit -m "Integrated Reviewer 2 feedback"
+git checkout main
+git merge integrate-reviewer2
+```
+
+**Solution 3: Document conflicts and resolutions**
+
+Create a conflicts log file:
+
+```bash
+cat > reviews/conflicts-log.md << 'EOF'
+# Merge Conflicts Resolution Log
+
+## Date: 2024-01-25
+
+### Conflict 1: Introduction paragraph 3
+
+**Location**: chapters/introduction.qmd, lines 45-50
+
+**Reviewer A (Dr. Chen)**: "Change 'algorithm' to 'methodology'"
+**Reviewer B (Dr. Patel)**: "Change 'algorithm' to 'computational approach'"
+
+**Resolution**: Used "methodology" (Reviewer A's suggestion)
+
+**Rationale**: More precise terminology. Notified Dr. Patel of decision.
+
+---
+
+### Conflict 2: Figure 3 placement
+
+**Location**: chapters/results.qmd, line 120
+
+**Reviewer A (Dr. Chen)**: Move to introduction
+**Reviewer B (Dr. Patel)**: Move to discussion
+
+**Resolution**: Kept in results section (original placement)
+
+**Rationale**: Figure shows primary results data, belongs in results per journal guidelines. Added forward reference in introduction and backward reference in discussion to satisfy both reviewers' concerns.
+
+---
+
+Last updated: 2024-01-25
+EOF
+```
+
+**Solution 4: Use visual merge tools**
+
+```bash
+# For Git conflicts, use a visual merge tool
+git config --global merge.tool meld # or kdiff3, vimdiff, etc.
+
+# When conflicts occur
+git mergetool
+
+# This opens a visual interface showing:
+# - Original version (base)
+# - Your version (local)
+# - Their version (remote)
+# - Merged result (output)
+```
+
+**Solution 5: Compare all versions side-by-side**
+
+```bash
+# Create a comparison script
+cat > compare-all-versions.sh << 'EOF'
+#!/bin/bash
+
+# Compare original with all reviewer versions
+echo "=== Comparing all versions of introduction.qmd ==="
+echo ""
+
+echo "Original vs Reviewer 1:"
+diff -u chapters/introduction.qmd reviews/reviewer1-introduction.md | head -20
+
+echo ""
+echo "Original vs Reviewer 2:"
+diff -u chapters/introduction.qmd reviews/reviewer2-introduction.md | head -20
+
+echo ""
+echo "Reviewer 1 vs Reviewer 2:"
+diff -u reviews/reviewer1-introduction.md reviews/reviewer2-introduction.md | head -20
+EOF
+
+chmod +x compare-all-versions.sh
+./compare-all-versions.sh
+```
+
+**Solution 6: Handle Git merge conflicts manually**
+
+When Git shows conflicts:
+
+```bash
+# Git will mark conflicts in the file like this:
+<<<<<<< HEAD
+Your current version of the text
+=======
+The conflicting version from the merge
+>>>>>>> review-branch
+```
+
+Edit the file to resolve:
+
+```bash
+# Open in editor
+code chapters/introduction.qmd
+
+# Manually choose which version to keep or combine both
+# Remove the conflict markers (<<<<<<, =======, >>>>>>>)
+
+# Mark as resolved
+git add chapters/introduction.qmd
+
+# Continue the merge
+git commit
+```
+
+**Solution 7: Prevent conflicts with clear reviewer assignments**
+
+Assign specific sections to each reviewer:
+
+```
+Email to reviewers:
+
+To avoid overlapping edits, I've assigned focus areas:
+
+Dr. Chen: Sections 1-2 (Introduction, Literature Review)
+Dr. Patel: Sections 3-4 (Methods, Results)
+Dr. Kim: Sections 5-6 (Discussion, Conclusions)
+
+You're welcome to comment on other sections, but please focus your detailed edits on your assigned sections.
+```
+
+**Solution 8: Use Word's Compare Documents feature**
+
+When you have multiple Word files with different edits:
+
+1. Open Microsoft Word
+2. Go to Review β Compare β Compare
+3. Select "Original document": `dissertation-v1.docx`
+4. Select "Revised document": `dissertation-v1-reviewer1.docx`
+5. Click "More Β»" β Check "Show changes in: New document"
+6. Click OK
+
+This creates a new document showing all changes. Repeat for each reviewer, then manually reconcile differences.
+
+**Solution 9: Consolidate before committing**
+
+```bash
+# Create a consolidation checklist
+cat > reviews/consolidation-checklist.md << 'EOF'
+# Consolidation Checklist
+
+## Before Committing
+
+- [ ] All reviewer files received and converted to markdown
+- [ ] Compared each reviewer's version with original
+- [ ] Identified all conflicts (documented in conflicts-log.md)
+- [ ] Resolved all conflicts (with rationale)
+- [ ] Merged all changes into source .qmd files
+- [ ] Tested with `quarto preview` - renders correctly
+- [ ] Spell-checked and proofread consolidated version
+- [ ] Created summary of changes (consolidation-summary.md)
+- [ ] Notified reviewers of any conflicts resolved differently than their suggestion
+
+## After Committing
+
+- [ ] Tagged version in git
+- [ ] Archived review files
+- [ ] Exported consolidated version to Word
+- [ ] Sent consolidated version to all reviewers for final approval
+
+Date completed: __________
+EOF
+```
+
+**Verification:**
+
+After resolving merge conflicts:
+- β
All reviewers' suggestions considered and documented
+- β
Conflicts resolved with clear rationale
+- β
No duplicate or contradictory content
+- β
Git history shows clean merge
+- β
Document renders without errors
+- β
All reviewers notified of resolutions
+
+---
+
+### Large Files and Performance
+
+#### Symptoms
+
+- Word export takes a very long time (> 5 minutes)
+- Exported `.docx` file is extremely large (> 50 MB)
+- Word crashes or freezes when opening the exported file
+- Pandoc conversion fails with memory errors
+- Git repository becomes slow due to large binary files
+
+#### Root Causes
+
+1. **High-resolution images**: Large PNG/JPG files embedded in document
+2. **Too many images**: Hundreds of figures in the document
+3. **Complex tables**: Large data tables with thousands of rows
+4. **Embedded media**: Videos or audio files accidentally included
+5. **Inefficient image formats**: Uncompressed or high-DPI images
+
+#### Solutions
+
+**Solution 1: Optimize images before including them**
+
+```bash
+# Install image optimization tools
+brew install imagemagick # macOS
+sudo apt install imagemagick # Linux
+
+# Compress all PNG images in figures directory
+cd figures/
+for img in *.png; do
+ mogrify -strip -quality 85 -resize '1200>' "$img"
+ echo "Optimized $img"
+done
+
+# Convert large images to JPEG (better compression for photos)
+for img in *.png; do
+ convert "$img" -quality 85 "${img%.png}.jpg"
+done
+
+# Check file sizes
+ls -lh figures/
+```
+
+**Solution 2: Set appropriate DPI for figures**
+
+In your `_quarto.yml`:
+
+```yaml
+format:
+ docx:
+ fig-dpi: 150 # Lower than default 300 DPI (sufficient for screen)
+ fig-width: 6
+ fig-height: 4
+```
+
+For print-quality, use 300 DPI. For digital-only or draft reviews, 150 DPI is sufficient and reduces file size significantly.
+
+**Solution 3: Use external figure references for drafts**
+
+Instead of embedding large images, link to them:
+
+```markdown
+
+
+
+
+
+```
+
+**Solution 4: Split large documents into chapters**
+
+```bash
+# Instead of one large document, export chapters separately
+quarto render chapters/introduction.qmd --to docx
+quarto render chapters/methods.qmd --to docx
+quarto render chapters/results.qmd --to docx
+
+# Send individual chapter files to reviewers
+cp _book/introduction.docx reviews/chapter1-for-review.docx
+cp _book/methods.docx reviews/chapter2-for-review.docx
+cp _book/results.docx reviews/chapter3-for-review.docx
+```
+
+**Solution 5: Reduce table size for Word export**
+
+For large data tables, consider:
+
+```markdown
+
+
+
+
+Table 1 shows the first 10 entries. Full dataset available at: [data.csv](data/full-dataset.csv)
+
+| ID | Value | Category |
+|----|-------|----------|
+| 1 | 42 | A |
+| 2 | 38 | B |
+...
+| 10 | 51 | A |
+
+
+Table 1: Summary statistics (see Appendix A for full data)
+
+| Category | Mean | SD | N |
+|----------|------|-----|------|
+| A | 45.2 | 3.1 | 500 |
+| B | 39.8 | 4.2 | 500 |
+```
+
+**Solution 6: Check and remove embedded media**
+
+```bash
+# Find all media files referenced in your document
+grep -r "\!\[.*\](" chapters/
+
+# Check for large files
+find figures/ -size +5M -exec ls -lh {} \;
+
+# Check Word file size after export
+ls -lh _book/*.docx
+
+# Extract and inspect contents of Word file
+unzip -l _book/paper.docx | grep "word/media"
+```
+
+**Solution 7: Use Git LFS for large binary files**
+
+```bash
+# Install Git Large File Storage
+brew install git-lfs # macOS
+sudo apt install git-lfs # Linux
+
+# Initialize Git LFS
+git lfs install
+
+# Track large file types
+git lfs track "*.docx"
+git lfs track "*.png"
+git lfs track "*.jpg"
+git lfs track "figures/*"
+
+# Commit the .gitattributes file
+git add .gitattributes
+git commit -m "Configure Git LFS for large files"
+
+# Now large files are stored efficiently
+git add _book/*.docx
+git commit -m "Add Word exports"
+```
+
+**Solution 8: Increase Pandoc memory limit**
+
+If Pandoc fails with memory errors:
+
+```bash
+# Set higher memory limit (8GB)
+export PANDOC_MEM=8G
+
+# Or use lower memory mode with chunked processing
+quarto render --to docx --execute-daemon-restart
+```
+
+**Solution 9: Archive old review files**
+
+```bash
+# Compress old review files
+tar -czf reviews-archive-2024-Q1.tar.gz reviews/2024-{01,02,03}-*/
+
+# Remove originals
+rm -rf reviews/2024-{01,02,03}-*/
+
+# Check disk space recovered
+du -sh reviews/
+```
+
+**Solution 10: Optimize Word file after export**
+
+```bash
+# Create optimized copy with compressed images
+# (Do this in Word: File β Save As β Tools β Compress Pictures)
+
+# Or use command-line tools
+# Install docx-compress
+pip install python-docx
+
+# Python script to compress images in docx
+cat > compress-docx.py << 'EOF'
+from docx import Document
+from docx.shared import Inches
+import sys
+
+doc = Document(sys.argv[1])
+
+# Reduce image sizes
+for shape in doc.inline_shapes:
+ if shape.width > Inches(6):
+ shape.width = Inches(6)
+
+doc.save(sys.argv[2])
+print(f"Compressed {sys.argv[1]} β {sys.argv[2]}")
+EOF
+
+# Run the compression
+python compress-docx.py input.docx output-compressed.docx
+```
+
+**Solution 11: Diagnostic script for performance issues**
+
+```bash
+# Create diagnostic script
+cat > diagnose-performance.sh << 'EOF'
+#!/bin/bash
+
+echo "=== Quarto Performance Diagnostics ==="
+echo ""
+
+echo "1. Quarto version:"
+quarto --version
+echo ""
+
+echo "2. Document size:"
+wc -l chapters/*.qmd | tail -1
+echo ""
+
+echo "3. Number of figures:"
+find figures/ -type f | wc -l
+echo ""
+
+echo "4. Large figures (> 1MB):"
+find figures/ -size +1M -exec ls -lh {} \;
+echo ""
+
+echo "5. Total figures directory size:"
+du -sh figures/
+echo ""
+
+echo "6. Number of citations:"
+grep -h "@" chapters/*.qmd | grep -o "@[a-zA-Z0-9_]*" | wc -l
+echo ""
+
+echo "7. Bibliography file size:"
+ls -lh *.bib
+echo ""
+
+echo "8. Exported Word file size:"
+ls -lh _book/*.docx 2>/dev/null || echo "No exports found"
+echo ""
+
+echo "9. Git repository size:"
+du -sh .git/
+echo ""
+
+echo "=== Recommendations ==="
+echo ""
+
+# Check for large images
+LARGE_IMAGES=$(find figures/ -size +1M | wc -l)
+if [ $LARGE_IMAGES -gt 0 ]; then
+ echo "β οΈ Found $LARGE_IMAGES large images (>1MB). Consider optimizing."
+fi
+
+# Check repository size
+REPO_SIZE=$(du -sm .git/ | cut -f1)
+if [ $REPO_SIZE -gt 100 ]; then
+ echo "β οΈ Git repository is ${REPO_SIZE}MB. Consider using Git LFS."
+fi
+
+# Check Word file size
+if [ -f "_book/*.docx" ]; then
+ DOCX_SIZE=$(du -m _book/*.docx 2>/dev/null | cut -f1 | head -1)
+ if [ ! -z "$DOCX_SIZE" ] && [ $DOCX_SIZE -gt 20 ]; then
+ echo "β οΈ Word export is ${DOCX_SIZE}MB. Consider splitting chapters."
+ fi
+fi
+
+echo ""
+echo "=== Done ==="
+EOF
+
+chmod +x diagnose-performance.sh
+./diagnose-performance.sh
+```
+
+**Verification:**
+
+After optimization:
+- β
Word export completes in < 1 minute
+- β
Exported `.docx` file is < 20 MB (ideally < 10 MB)
+- β
Word opens file quickly without crashing
+- β
Images are clear but appropriately sized
+- β
Git repository stays manageable (< 100 MB)
+
+---
+
+## Quick Troubleshooting Flowchart
+
+```
+Problem exporting to Word?
+ β
+ βββ Citations not rendering?
+ β βββ Check bibliography: in _quarto.yml, verify .bib file
+ β
+ βββ Formatting looks wrong?
+ β βββ Create custom reference-doc, set in _quarto.yml
+ β
+ βββ Merge conflicts with reviewers?
+ β βββ Use Git branches, process sequentially, document conflicts
+ β
+ βββ File too large or slow?
+ βββ Optimize images, reduce DPI, split chapters
+```
+
+**Still stuck?** See the [Need Help?](#-need-help) section at the end of this guide.
+
+---
+
+## 9. Best Practices and Tips
+
+### When to Use This Workflow
+
+*This section will be populated in subsequent subtasks*
+
+### Communication Strategies
+
+*This section will be populated in subsequent subtasks*
+
+### Maintaining Quality Control
+
+*This section will be populated in subsequent subtasks*
+
+---
+
+## π Related Documentation
+
+- [Getting Started Guide](GETTING_STARTED.md) - Set up your research template
+- [Troubleshooting Guide](docs/TROUBLESHOOTING.md) - Common issues and solutions
+- [Customization Guide](CUSTOMIZATION_GUIDE.md) - Customize your workflow
+- [Quarto Documentation](https://quarto.org/docs/output-formats/ms-word.html) - Official Quarto Word format docs
+
+---
+
+## π¬ Need Help?
+
+If you encounter issues not covered in this guide:
+
+1. Check the [Troubleshooting Guide](docs/TROUBLESHOOTING.md)
+2. Review [Quarto's Word format documentation](https://quarto.org/docs/output-formats/ms-word.html)
+3. Search existing [GitHub Issues](https://github.com/yourusername/research-template/issues)
+4. Open a new issue with details about your workflow and the problem
+
+---
+
+**Last Updated**: January 2026
+**Maintained by**: Research Template Contributors