Nomination Evidence: kirktrue

Project: apache/kafka Period: 2026-01-27 to 2026-02-26

Summary

kirktrue reviews 8x more PRs than they author (8 reviews, 1 PRs), interacting with 10 contributors, 1 of 1 authored PRs scored as high-complexity, 2 binding vote(s) on the dev@ mailing list.

Highlights

30 commits, 1 PRs merged, 8 PRs reviewed, 45 review comments, 5 dev@ messages | https://github.com/apache/kafka/commits?author=kirktrue
Drove PR #21457 (KAFKA-20131: ClassicKafkaConsumer does not clear endOffsetRequested flag on failed LIST_OFFSETS calls), 41 review rounds: https://github.com/apache/kafka/pull/21457
Review on PR #21117 (KAFKA-19932: adding handling of OOM and avoiding wrapped as timeout): "Is it possible to use a generic "mock" here instead of a spy?..." https://github.com/apache/kafka/pull/21117
PR #21457 (KAFKA-20131: ClassicKafkaConsumer does not clear endOffsetRequested flag on failed LIST_OFFSETS calls): 9 days to merge: https://github.com/apache/kafka/pull/21457
Review comment on PR #21457 (KAFKA-20131: ClassicKafkaConsumer does not clear endOffsetRequested flag on failed LIST_OFFSETS calls): "> In this case we want to refresh metadata and try again once we know the leader. Is there a reason why we want to chang..." https://github.com/apache/kafka/pull/21457
2 binding vote(s) on dev@, 5 threads

Contribution statistics

Code contributions (GitHub)

PRs opened: 1
PRs merged: 1
Lines added: 274
Lines deleted: 41
Commits: 30

Code review

PRs reviewed: 8
Review comments given: 45
Issue comments: 5
- APPROVED: 1 (12%)
- CHANGES_REQUESTED: 0 (0%)
- COMMENTED: 7 (87%)

Mailing list participation (dev@)

Messages sent: 5
Threads started: 0
Threads participated: 5
Votes cast: 3 (2 binding)

Composite score

Dimension	Score	Notes
Complexity	6.7/10	1 high-complexity PRs of 1 scored
Stewardship	7.6/10	67% maintenance work, 80% consistency
Review depth	8.5/10	3.1 comments/review, 40% questions, 10 contributors
Composite	7.6/10	out of 118 contributors

Review relationships

People this contributor reviews most

iit2009060: 2 reviews
Anushreebasics: 1 reviews
ravikalla: 1 reviews
prabhashkr: 1 reviews
zooo-code: 1 reviews
devtrace404: 1 reviews
m1a2st: 1 reviews

People who review this contributor's PRs most

lianetm: 12 reviews
AndrewJSchofield: 3 reviews
viktorsomogyi: 1 reviews

Net reviewer

kirktrue reviews 8.0x more PRs than they author (8 reviews, 1 PRs), interacting with 10 different contributors.

Community health profile

Relational metrics: how this contributor strengthens the community beyond code output.

Net reviewer ratio: 8.0x
Interaction breadth: 10 unique contributors (concentration: 25%)
Newcomer welcoming: 8 reviews on PRs from contributors with 3 or fewer PRs
- Names: Anushreebasics, ravikalla, prabhashkr, zooo-code, devtrace404, iit2009060, m1a2st
Helping ratio: 50% of GitHub comments directed at others' PRs
Review depth: 3.1 comments/review, 40% questions (25 comments on 8 reviews)
Stewardship: 67% of work is maintenance (6/9 PRs: 0 authored, 6 reviewed)
Thread response ratio: 100% of mailing list threads joined are others' threads
Consistency: 80% (4/5 weeks active)
Feedback responsiveness: 100% iteration rate, 11.7h median turnaround, 119% reply rate (1 PRs with feedback)

Complexity of authored work

PRs scored: 1
High complexity (>= 0.5): 1
Low complexity (< 0.5): 0
Average complexity: 0.550

Highest-complexity authored PRs

PR #21457 (KAFKA-20131: ClassicKafkaConsumer does not clear endOffsetRequested flag on failed LIST_OFFSETS calls)
- Complexity score: 0.550
- Probing ratio: 47.6%
- Review rounds: 41
- Probing topics: imagine we don, known leader, background retrying, flag get cleared

Quality of review contributions

Probing review comments (expressing uncertainty, challenging assumptions): 4

Most significant probing reviews (on highest-complexity PRs)

PR #21457 (KAFKA-20131: ClassicKafkaConsumer does not clear endOffsetRequested flag on failed LIST_OFFSETS calls, score 0.550)
- Comment: "> I agree we need this if we don't have any time left to retry. But if there's s..."
PR #21457 (KAFKA-20131: ClassicKafkaConsumer does not clear endOffsetRequested flag on failed LIST_OFFSETS calls, score 0.550)
- Comment: "@lianetm—are you OK with leaving the logging in OffsetFetcherUtils or should w..."
PR #21117 (KAFKA-19932: adding handling of OOM and avoiding wrapped as timeout, score 0.212)
- Comment: "Is it possible to use a generic "mock" here instead of a spy?"
PR #21483 (KAFKA-18608 [WIP]: Add Support for OAuth Client Assertion to client_credentials Grant Type, score 0.189)
- Comment: "Could we use Utils.isBlank() for these checks? Super minor but reads a little ..."

Highest-judgment review comments (on others' PRs)

(Selected by length, technical content, and presence of questions)

PR #21483 (KAFKA-18608 [WIP]: Add Support for OAuth Client Assertion to client_credentials Grant Type) | https://github.com/apache/kafka/pull/21483#discussion_r2825487409
- File: gradle/dependencies.gradle
- "Super nitpicky, but... With a couple of exceptions, it seems like this array is supposed to be sorted alphabetically, though I understand wanting to keep the OAuth-related libraries together. @omkreddy—any guidance on this?"
PR #21483 (KAFKA-18608 [WIP]: Add Support for OAuth Client Assertion to client_credentials Grant Type) | https://github.com/apache/kafka/pull/21483#discussion_r2825480183
- File: clients/src/main/java/org/apache/kafka/common/security/oauthbearer/internals/secured/HttpRequestFormatterFactory.java
- "I'm wondering if it makes more sense to name this ClientCredentialsRequestFormatter and make it a super class of ClientAssertionRequestFormatter and ClientSecretRequestFormatter. Unless we foresee the method returning other types besides those two."
PR #20212 (KAFKA-10840: Expose authentication failures in KafkaConsumer.poll()) | https://github.com/apache/kafka/pull/20212#discussion_r2396346901
- File: clients/src/main/java/org/apache/kafka/clients/consumer/internals/ClassicKafkaConsumer.java
- "Error handling that depends on strings appearing in the error messages is always a bit brittle. Regardless, this seems like something that should happen at a different layer so that the admin and producer clients can use it."
PR #21198 (KAFKA-16799: Reduce log level for 'Node is not ready' message to TRACE ) | https://github.com/apache/kafka/pull/21198#discussion_r2670522553
- File: clients/src/main/java/org/apache/kafka/clients/consumer/internals/NetworkClientDelegate.java
- "ready() has several conditions in which it could return false. For some of them (e.g. connecting state), it may make sense to back off, but for others (e.g. busy sending a metadata request), not so much."
PR #21484 (KAFKA-200135 Add javadoc to org.apache.kafka.clients.admin module(1/N)) | https://github.com/apache/kafka/pull/21484#discussion_r2819813594
- File: clients/src/main/java/org/apache/kafka/clients/admin/ClassicGroupDescription.java
- "It doesn't look like there's anything preventing a null from being passed to the constructor for protocol. protocolData is forced to an empty string, but protocol is not 🤔"