How the Every Programmer Should Know Repository Is Curated: Core Values and PR Workflow

The Every Programmer Should Know repository is curated through a strict, opinionated pull‑request workflow governed by four core values—less is more, broad applicability, low stress, and human‑centric focus—where every submission must be personally evaluated and justified against these principles.

The mtdvio/every-programmer-should-know list has become a definitive resource for essential programming knowledge, but its quality stems from a deliberate curation process rather than crowd‑sourced volume. Understanding how the Every Programmer Should Know repository is curated reveals why the list remains concise, timeless, and genuinely useful across technology stacks.

Core Values Driving the Curation Process

The repository’s philosophy is codified in CONTRIBUTING.md, where the maintainer defines four non‑negotiable principles that every submission must satisfy.

Less Is More

The curation explicitly rejects volume in favor of density. Lines 17‑22 of CONTRIBUTING.md state that the list targets a smaller collection of more valuable resources rather than an exhaustive catalog. This constraint forces contributors to justify why an entry deserves limited real estate.

Broad Applicability

Resources must survive technological churn. According to lines 24‑28, submissions need strategically valuable knowledge that remains relevant across languages, frameworks, and decades. Specific library documentation or trending frameworks are typically rejected in favor of fundamental concepts.

Low Stress, No Hype

The list bans anxiety‑inducing or buzzword‑heavy material. Lines 31‑36 explicitly instruct contributors to avoid adding to stress or hype levels, filtering out content that emphasizes imposter syndrome or marketing‑driven urgency.

Human‑Centric Focus

Technology serves people, not the reverse. Lines 39‑43 emphasize resources that improve soft skills and the human dimension of software engineering, ensuring the list includes communication, ethics, and mental health alongside technical topics.

Strict Curation Guidelines and Requirements

Beyond values, CONTRIBUTING.md enforces procedural rules that operationalize the philosophy.

Guideline	Requirement	Source Location
Personal Evaluation	Only submit resources you have personally used or studied.	Lines 48‑53: "Do not add things you have not evaluated personally!"
Value‑Based Reasoning	Answer four impact questions regarding programmers’ work and life before submitting.	Lines 56‑63: "Use reasoning based on our values."
One Item Per PR	Each pull request must contain exactly one new resource to keep discussion focused.	Lines 66‑70: "One item per Pull Request."
PRs, Not Issues	New resources are submitted via pull requests, never via GitHub issues.	Lines 72‑75: "Do not open issues … create a Pull Request instead!"
Consistent Emoji Tagging	Resources must use the defined emoji set: 📖 (book), 🎥 (video), 📄 (article), 📜 (paper), ✅ (checklist).	Lines 77‑84: "Use consistent set of resource type emoji."
Mandatory Explanation	Every PR must include honest arguments for why the resource belongs.	Lines 49‑53: "Give honest arguments for why the resource should be included."
No Silent Rejection	The maintainer promises never to discard a PR without detailed explanation.	Line 11: "No PR will be discarded without explanations!"

The repository is explicitly labeled as highly opinionated and curated (line 8 of CONTRIBUTING.md), reinforcing that inclusion is a deliberate editorial decision rather than a democratic vote.

The Pull Request Workflow

The curation process operates through a lightweight, transparent pipeline:

1. Submit a focused PR containing a single markdown entry with the appropriate emoji tag.
2. Undergo maintainership review where the maintainer verifies personal evaluation, alignment with the four core values, and proper formatting.
3. Engage in discussion directly on the PR; if rejected, the maintainer provides a detailed rationale referencing specific value conflicts.
4. Merge upon consensus only after the resource passes the four‑question sanity check and demonstrates clear value alignment.

Because the list lives in a simple Markdown file (README.md), the entire curation pipeline remains version‑controlled, community‑auditable, and free of complex automation.

Key Files in the Curation Architecture

File	Role	Location
README.md	The curated list of resources, organized by topic.	README.md
CONTRIBUTING.md	Defines core values, guidelines, and the PR workflow.	CONTRIBUTING.md
.github/FUNDING.yml	Enables sponsorships supporting long‑term maintenance.	.github/FUNDING.yml

These three files constitute the architectural backbone of the repository’s curation process: README.md reflects the editorial outcome, CONTRIBUTING.md encodes the how and why, and FUNDING.yml sustains the effort.

Summary

• The Every Programmer Should Know repository is curated through a strict, opinionated PR workflow defined in CONTRIBUTING.md.
• Four core values—less is more, broad applicability, low stress/no hype, and human‑centric focus—filter every submission.
• Contributors must personally evaluate resources and submit one item per PR, using a consistent emoji taxonomy (📖, 🎥, 📄, 📜, ✅).
• The maintainer reviews each PR against value‑based reasoning questions and never discards submissions without explanation.
• The lightweight architecture (README.md, CONTRIBUTING.md, .github/FUNDING.yml) keeps the process transparent and sustainable.

Frequently Asked Questions

What makes the Every Programmer Should Know list different from other awesome lists?

Unlike typical "awesome" lists that optimize for comprehensiveness, this repository explicitly follows a "less is more" philosophy (lines 17‑22 of CONTRIBUTING.md). Every entry must survive strict scrutiny against four core values—broad applicability, low stress, and human‑centric benefit—ensuring the final list contains only timeless, high‑signal resources rather than exhaustive catalogs of every available tool.

Can I suggest a resource by opening a GitHub issue instead of a pull request?

No. The curation workflow explicitly forbids resource suggestions via issues. According to lines 72‑75 of CONTRIBUTING.md, contributors must "create a Pull Request instead" of opening an issue. This policy ensures that every submission arrives as a concrete, formatted entry with the required justification, facilitating immediate evaluation against the repository’s editorial standards.

Why does the repository require only one item per pull request?

The "one item per Pull Request" rule (lines 66‑70) keeps discussion focused and reviewable. By isolating each resource, the maintainer can evaluate its specific alignment with core values without the noise of bundled submissions. This granularity also preserves clean git history, making it easy to revert or modify individual entries without affecting unrelated resources.

What happens if my pull request is rejected?

The maintainer promises that "no PR will be discarded without explanations" (line 11). If a submission fails to meet the criteria—whether due to lack of personal evaluation, misalignment with the "low stress" or "broadly applicable" values, or improper formatting—the reviewer will provide specific feedback referencing the relevant sections of CONTRIBUTING.md. This transparency allows contributors to refine their proposals or understand the editorial boundaries.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}