Process

This document explains how the projects at Dijktra are managed. Clarity in process reduces friction, avoids burnout, and ensures the project scales sustainably.

Issue Lifecycle

Every change in Dijkstra begins with an issue.

1. Issue Opened

Anyone may open an issue.

Issues can represent:

bugs
feature requests
refactors
documentation improvements
architectural discussions
questions that may evolve into changes

A good issue includes:

clear problem description
context or motivation
expected vs actual behavior (for bugs)
screenshots, logs, or examples if applicable

Incomplete issues may be asked for clarification before moving forward.

2. Maintainer Triage

Maintainers review newly opened issues to:

verify scope and relevance
detect duplicates
assess urgency and impact
determine whether the issue fits project goals

At this stage, maintainers may:

ask follow-up questions
suggest alternatives
close issues that are out of scope (with explanation)

Triage ensures effort is spent where it matters most.

3. Labeling & Prioritization

Issues are labeled to communicate intent and difficulty.

Labels help contributors quickly understand:

what kind of issue this is
who it is suitable for
how urgent it is

Prioritization balances:

user impact
technical debt
maintainer bandwidth
long-term roadmap

Not all issues are equal—and that’s okay.

4. Assignment

Issues may be:

self-assigned by contributors
explicitly assigned by maintainers
left unassigned for open contribution

Before starting work:

comment on the issue to claim it
wait for confirmation if requested

This avoids duplicated work and frustration.

5. Development

Once assigned, development begins.

Expectations during development:

follow contribution and coding guidelines
keep changes focused and scoped to the issue
communicate progress if work is long-running
ask questions early if blocked

Large changes should be broken into smaller, reviewable steps whenever possible.

6. Review

All changes go through review.

Review focuses on:

correctness
maintainability
readability
alignment with project goals
potential edge cases or regressions

Feedback may include:

requested changes
questions for clarification
suggestions (not all are mandatory)

Reviews are about improving the code, not judging the author.

7. Merge

Once approved:

the change is merged by a maintainer
commit history is preserved or squashed as appropriate
related issues are linked and resolved

Merges happen deliberately—not rushed.

8. Close

Issues are closed when:

the change is merged
the issue is resolved another way
the issue is no longer relevant

Closed does not mean ignored—it means concluded.

Issue Labels

Labels are a navigation system for contributors and maintainers.

Core Labels

good first issue
Beginner-friendly issues with limited scope and clear direction.
Ideal for first-time contributors.
help wanted
Issues the maintainers explicitly want help with.
Often higher-impact or time-sensitive.
bug
Incorrect or unexpected behavior that needs fixing.
enhancement
Improvements or new features that extend functionality.
documentation
Changes related to guides, READMEs, comments, or explanations.

Why Labels Matter

Labels:

reduce onboarding friction
signal expectations clearly
help prioritize review effort
prevent contributor burnout

Always check labels before starting work.

Decision Making

Dijkstra values open discussion with clear ownership.

Maintainer Authority

Maintainers have final decision-making authority
This responsibility exists to protect project direction and stability

Authority is exercised with explanation, not silence.

Technical Merit Over Opinion

Decisions are guided by:

technical correctness
long-term maintainability
clarity and simplicity
alignment with project goals

Arguments backed by reasoning, benchmarks, or examples carry weight.

Consensus First

Whenever possible:

decisions are discussed openly
alternatives are considered
trade-offs are made explicit

Consensus builds trust and shared understanding.

Respectful Disagreement

Disagreement is normal and healthy.

Expected behavior:

challenge ideas, not people
explain why you disagree
accept final decisions gracefully

Hostility or dismissiveness is never acceptable.