Teach review judgment before counting merged patches

A contributor can help a project by explaining why a change needs another test, why a compatibility concern matters or why a patch is ready. Counting merged code alone leaves much of that judgment invisible. Teams developing contributors should make review reasoning observable through paired reviews and feedback, while keeping public participation optional as evidence of professional ability.

The occasion for this November 2026 retrospective is the Django Software Foundation's announcement on 10 October 2025 that Tim Schilling received the Malcolm Tredinnick Memorial Prize. A community award can identify practices worth examining. It cannot establish a measured improvement in recruitment, retention or engineering output, and this article makes none of those claims.

Recognition names work that a commit count misses

The foundation's nomination call of 13 September 2025 emphasized welcoming and supporting newcomers, offering feedback and helping the community grow. The nomination call preceded the award announcement. It described the prize's values rather than selecting a winner in September. Keeping those dates separate avoids turning an invitation into an outcome.

The award post includes community testimony about Schilling's support for newcomers and constructive feedback. In particular, Raffaella describes the Djangonaut Space “Space Reviewers” team being formed to host a live stream that would share the review process and review a ticket. That is attributed testimony published by the foundation, rather than a controlled assessment of the session's educational effect.

The useful inference is modest. Showing how an experienced reviewer reaches a decision gives learners access to something a final approval cannot show. A learner can see which uncertainty was investigated, which concern was important and what evidence changed the conclusion. This is an argument for making reasoning available, not a claim that the cited session followed every teaching practice proposed below.

It also gives recognition a more precise object. Thanking someone for being helpful is worthwhile, but identifying the explanation that enabled another person to participate makes the contribution easier to understand. Review feedback, context on a ticket and patient clarification can be valuable even when the helper does not author the merged patch.

A paired review needs a question to investigate

An illustrative learning session can start with one bounded change and its intended behavior. Before reading every line, the learner describes what a correct result would mean and where the change might affect existing users. The experienced reviewer can then ask for evidence rather than supply an immediate verdict. The point is to expose the learner's reasoning while there is still time to improve it.

Choose material that can be discussed legitimately. A public open-source ticket is one option; an employer can also provide an authorized internal exercise during paid time. Private code and customer data should not become portfolio material merely because the review was educational. Permission to perform a review is not automatically permission to publish its contents.

A useful record can explain the concern, the evidence consulted and the final decision. It need not reproduce a whole conversation. If the reviewer initially suspected a defect and later found the behavior was intentional, that correction is part of the evidence. Judgment includes recognizing that a proposed change is unnecessary, rather than finding a flaw on every occasion.

Feedback should address the decision and its consequences. A missed compatibility condition deserves a different discussion from a preference about naming. If every comment is presented with equal urgency, the learner may learn to maximize comment volume instead of protecting users. Explain why an issue blocks the change, why it is optional or why it should be handled separately.

Make disagreement teachable

Two capable reviewers can disagree about the right scope of a patch. One may prefer a narrow fix; another may want to address the surrounding design. A paired session can make that tradeoff explicit by returning to the reported problem, the release constraints and the evidence available. Agreement is useful when it follows reasons that another person can inspect.

The mentor should also be open to correction. A teaching arrangement that treats the experienced person's first opinion as the answer can train deference rather than judgment. Leave room for the learner to identify an overlooked condition or ask for stronger support. The project's actual decision process still applies; the session does not grant either participant authority they do not hold.

This is distinct from funding review continuity. Paying people to handle a queue can support dependable availability, while mentoring helps people learn how to assess a change. The two can support each other, but they answer different questions. A funded position does not prove that teaching occurs, and a generous teaching session does not establish that a project's maintenance queue has enough capacity.

The same distinction limits how a business should interpret the award. The foundation recognized community contribution according to its stated values. That recognition is not an AL+ recruitment program, an endorsement of a commercial service or a claim about the productivity of everyone who participates in Djangonaut Space. Keep the institutional attribution attached to the actual announcement.

Public contribution cannot be a universal entry requirement

The strongest objection to a review portfolio is unequal opportunity. Public work takes time, and people differ in caring responsibilities, employment restrictions and access to suitable projects. A hiring process that requires a visible open-source history can exclude capable reviewers whose most relevant work cannot be shared. The absence of public evidence is not evidence of absent ability.

An employer can instead offer a bounded, authorized review exercise and assess the explanation against clear criteria. The exercise should give candidates enough context to reason, rather than reward familiarity with an unexplained codebase. This is a proposed assessment option, not a tested hiring result or a promise that one exercise eliminates bias.

For custom software development, review quality begins with making the intended behavior and compatibility concerns discussable. If you mentor contributors, ask them to explain a decision, show the evidence and revisit it after feedback. Recognize the person who makes another reviewer more capable alongside the person whose code is merged. That is a contribution a commit count alone cannot describe.