Skip to content

Contributing to Documentation Project — Complete Guide

DodaTech Updated 2026-06-28 6 min read

In this tutorial, you will learn about Contributing to Documentation Project. We cover key concepts, practical examples, and best practices to help you master this topic.

The contributing project applies all lessons to make meaningful documentation contributions to an open source project or your own documentation.

What You'll Learn

You will apply all the skills from this module to find, plan, create, and submit documentation contributions, building a portfolio of verifiable work.

Why It Matters

Theory without practice is forgettable. Making real contributions solidifies your skills and creates a portfolio that demonstrates your abilities to employers.

Real-World Use

The DodaTech team evaluates candidates by asking them to complete a documentation contribution to a real open source project as part of the interview Process.

flowchart LR
  A[Project Phases] --> B[Find Project]
  A --> C[Plan Contribution]
  A --> D[Create Content]
  A --> E[Submit PR]
  B --> F[Identify Needs]
  B --> G[Read Guidelines]
  C --> H[Scope Work]
  C --> I[Gather Resources]
  D --> J[Write Draft]
  D --> K[Self-Review]
  E --> L[Create PR]
  E --> M[Respond to Feedback]
  F:::current
  classDef current fill:#f90,color:#fff,stroke:#333,stroke-width:2px

Phase 1: Find a Project

Identifying Good Projects

Criteria Why
Active maintainers Your PR will be reviewed
Clear contributing guide You know the process
Good first issues labeled They welcome new contributors
Uses your tech stack You understand the content
Has documented style guide You can produce consistent content
def evaluate_project(project):
    score = 0
    if project.get('active_maintainers'):
        score += 3
    if project.get('contributing_guide'):
        score += 2
    if project.get('good_first_issues'):
        score += 2
    if project.get('style_guide'):
        score += 2
    if project.get('uses_known_tech'):
        score += 1
    
    if score >= 8:
        return "Excellent project for contribution"
    elif score >= 5:
        return "Good project for contribution"
    else:
        return "Look for a more active project"

project = {
    'active_maintainers': True,
    'contributing_guide': True,
    'good_first_issues': True,
    'style_guide': True,
    'uses_known_tech': True,
}
print(evaluate_project(project))

Expected output:

Excellent project for contribution

Where to Look

## Finding Documentation Projects

1. **GitHub Explore**: Search "good first issue" + "docs"
2. **Up for Grabs**: Site listing beginner-friendly projects
3. **First Timers Only**: Monthly initiative for new contributors
4. **Your favorite tools**: Projects you already use
5. **DodaTech Tutorials**: Our own open source content

Phase 2: Plan Your Contribution

Choose the Right Contribution

Contribution Type Time Required Skills Needed
Fix typo 15-30 minutes Attention to detail
Fix broken link 30 minutes Basic Git
Add missing section 1-2 hours Knowledge of topic
Write new tutorial 3-5 hours Strong writing + topic expertise

Scope the Work

## Contribution Plan Template

### Project
[Project name and repository URL]

### Issue Being Addressed
[Link to the issue or description of the need]

### Scope
[What you will and will not do in this contribution]

### Files to Change
[Exact file paths relative to repository root]

### Dependencies
[Content that must exist before this can be merged]

### Timeline
[Your expected completion date]

Phase 3: Create the Content

Follow the Style Guide

Every project has specific requirements. Check before writing.

# Check for style guide
ls CONTRIBUTING.md
ls STYLEGUIDE.md
ls docs/style-guide.md

# Run linters before committing
npx markdownlint-cli2 content/

Quality Checklist

def self_review(content):
    checks = []
    checks.append(('First paragraph 140-165 chars', 140 <= len(content.split('\n')[0]) <= 165))
    checks.append(('Code examples present', '```' in content))
    checks.append(('Mermaid diagram', '```mermaid' in content))
    checks.append(('Common Mistakes section', '## Common Mistakes' in content))
    checks.append(('Practice Questions', '## Practice Questions' in content))
    checks.append(('FAQ section', '## FAQ' in content))
    checks.append(('Mini Project', '## Mini Project' in content))
    checks.append(('What\'s Next', '## What\'s Next' in content))
    
    failures = [name for name, passed in checks if not passed]
    return failures

content = "# Test\n\nSome content here"
failures = self_review(content)
print(f"Failed checks: {failures}")

Expected output:

Failed checks: ['First paragraph 140-165 chars', 'Code examples present', 'Mermaid diagram', 'Common Mistakes section', 'Practice Questions', 'FAQ section', 'Mini Project', "What's Next"]

Phase 4: Submit the PR

Create a Descriptive PR

## PR: Add troubleshooting guide for authentication errors

### Summary
This PR adds a troubleshooting guide for common authentication
errors, including invalid API keys, expired tokens, and rate
limiting issues.

### Related Issues
Closes #456

### Changes
- New file: content/api/troubleshooting-auth.md
- Updated: content/api/_index.md (added link)

### Checklist
- [ ] Follows style guide
- [ ] Code examples tested
- [ ] All links valid
- [ ] Build passes

Handle Feedback

def handle_review_feedback(feedback_items):
    responses = []
    for item in feedback_items:
        if item['type'] == 'correction':
            responses.append(f"Fixed: {item['description']}")
        elif item['type'] == 'suggestion':
            responses.append(f"Good suggestion. I will update: {item['description']}")
        elif item['type'] == 'question':
            responses.append(f"Great question. Here is my reasoning: {item['description']}")
    return responses

feedback = [
    {'type': 'correction', 'description': 'Fixed typo on line 34'},
    {'type': 'suggestion', 'description': 'Added more detail to the explanation'},
]
for r in handle_review_feedback(feedback):
    print(r)

Expected output:

Fixed: Fixed typo on line 34
Good suggestion. I will update: Added more detail to the explanation

Portfolio Documentation

After the PR is merged, document it for your portfolio.

## Portfolio Entry: Authentication Troubleshooting Guide

### Project
DodaTech Tutorials (https://github.com/dodatech/tutorials)

### Contribution
Wrote a comprehensive troubleshooting guide covering 5 common
authentication errors with code examples and solutions.

### Skills Demonstrated
- Technical writing for developer audiences
- API authentication concepts
- Markdown and Git workflow
- Responding to PR feedback

### Link
https://github.com/dodatech/tutorials/pull/789

Common Mistakes

1. Choosing a Project You Do Not Use

Contributing to documentation for a project you have never used means you do not understand the user's perspective.

2. Working Without an Issue

Starting work without claiming an issue risks duplicate effort. Always comment on the issue first.

3. Ignoring the Timeline

If you cannot complete the contribution in the expected time, communicate with the maintainers.

4. Not Documenting for Portfolio

A merged PR that you do not document in your portfolio has less career value. Record every contribution.

5. Stopping After One PR

The real value comes from sustained contribution. Plan to make 3-5 contributions across 1-2 projects.

Practice Questions

1. What are the four phases of the contributing project?

Find a project, plan the contribution, create the content, and submit the PR.

2. What criteria make a project good for first contributions?

Active maintainers, clear contributing guide, good first issues, style guide, and familiar tech stack.

3. How should you document a contribution for your portfolio?

Include the project name, contribution description, skills demonstrated, and a link to the PR.

4. Why is it important to claim an issue before working on it?

To prevent duplicate effort and let maintainers know someone is working on it.

5. Challenge: Complete a real documentation contribution to an open source project. Document the process and add the contribution to your portfolio.

FAQ

What if my PR is not merged?

It happens. Learn from the feedback, improve, and try another project. Not every PR will be accepted.

How many contributions should I aim for?

3-5 quality contributions across 1-2 projects create a strong portfolio.

Can I contribute to a project anonymously?

Yes, but you lose the portfolio and networking benefits. Using your real name is recommended.

What if I cannot find a good first issue?

Look for outdated documentation, broken links, or missing sections. You do not need an issue to fix obvious problems.

How do I know if my contribution is valuable?

If it helps users understand the product better, it is valuable. Maintainers will let you know.

Mini Project

Complete a real documentation contribution to an open source project. Find a project, identify a need (typo, broken link, missing section), create the fix, submit a PR, respond to feedback, and document the contribution in your portfolio.

What's Next

Congratulations on completing the contributing to documentation module! You now have the skills to contribute to any documentation project. Consider revisiting the PR Process for Docs or exploring the Content Strategy Project.

Built by the developers of DodaTech

Doda Browser, DodaZIP & Durga Antivirus Pro