Use cases / Keeping main healthy
The same review comment on every pull request. Will this one stick?
Reviewers repeat the same correction on pull request after pull request, because the convention lives only in their comments.
Jigward fixes every instance in its own change, answers in the reviewer's thread and keeps the note as that reviewer's request for one repository, so its next pull request follows it unasked. The merge, and how far the rule reaches, stay with the reviewer.
The film
Chapters
Read the narration
0:00 The review note that keeps coming back
Anna leaves the same review note on almost every new PR. The line gets fixed, and the habit comes back. I'm Jigward. Review comments on my own pull requests come back to me. Anna wants the Clock injected, so the tests don't change from day to day. She shouldn't have to write this twice.
0:20 Fixed everywhere in its own change
Anna flagged one line. My change makes that call twice more. Older calls aren't mine to change, so I'll propose an automated check. Each class now takes the Clock, and the tests pin the time. They pass whatever day they run, which was Anna's point.
0:39 Answered in the thread, kept as a request
One more commit on my PR, then a reply in Anna's thread: fixed here, and in the two places she didn't flag. Then I'll remember it as Anna's request, scoped to the billing repo, so later work follows it without a reminder.
0:58 A week later, a new Jira story
A week later, a new ticket: mark unpaid invoices past due. Nothing in it mentions the clock. The new job needs today's date. Copying older code would repeat the mistake, so I follow Anna's request from last week.
1:16 Followed without a reminder
The new draft PR injects the Clock from the start and names its source, so Anna can check it herself. This time, Anna reviews the change, not the habit. The merge, and how far the rule should reach, are still her call.
What changes
Today. The reviewer types the same note, the author fixes the flagged line, and the pattern comes back two files away or on the next pull request, because the rule exists only in review comments. No style guide covers every convention, and turning each one into a lint rule takes time nobody schedules. Linters catch what is already a rule, and a correction left in one review stays in that thread.
-
Before: The flagged line fixed, and the same call left two files away.
With Jigward: All three calls in Jigward's own change fixed, and the tests pinned to a fixed time.
-
Before: A convention that lives in one reviewer's comments.
With Jigward: The note kept in memory as that reviewer's request for the billing repository, with the comment it came from.
-
Before: The same comment again on next week's pull request.
With Jigward: A new pull request that injects the Clock from its first commit and names where the convention came from.
What Jigward does
Inject the Clock bean here instead of calling Instant.now(). Otherwise the tests depend on the day they run.
Connected beforehand
- The billing repository is connected through GitHub, in the billing Context.
- The billing project in Jira is named with the same Context, and the team assigns stories to Jigward.
- The team channel in Slack is named for that Context.
-
Takes up the comment
The review comment on Jigward's draft pull request continues the Task that opened it. The reviewer flagged one call to Instant.now().
-
Searches the repository
A search finds seven calls. Three are in Jigward's own change, and four are in older code it did not write.
-
Fixes its own calls
Each new class takes the Clock, and the tests pin the time, so they pass whatever day they run. The four older calls stay as they are, and Jigward records an automated architecture check for them as an initiative.
-
Answers in the thread
One more commit on its own pull request, then a reply in the reviewer's thread saying it is fixed here and in the two places nobody flagged.
-
Keeps the request
Jigward keeps the note in memory as the reviewer's request, held to the billing repository, with the comment it came from.
-
Follows it a week later
A new Jira story says nothing about the clock. The request comes back when the work begins, and the new draft pull request injects the Clock from the start and names its source.
Jigward in this case
-
Jira
Stories assigned to Jigward become Tasks. A week later, a new story starts the Task that follows the convention.
-
GitHub
The review comment reaches Jigward on its own draft pull request, and the reply goes into the same thread. Jigward pushes only to its own branch.
-
Workspace
The search, the fix and the tests with a fixed clock run on Jigward's own copy of the repository.
-
Memory
The convention is kept as one reviewer's request for one repository, never as a rule of the whole organization.
-
Initiatives
The four older calls become an initiative for an automated architecture check, instead of a change to code Jigward did not write.
-
Slack
When the new pull request is ready, Jigward tells the reviewer in the team channel, linking the Jira issue, the pull request and the Task.
What comes back, and what stays with the team
What comes back
- The first pull request One more commit, and a reply in the reviewer's thread naming every place the fix touched and the four older calls left alone.
- The new pull request A draft that injects the Clock from the start and cites the reviewer's comment as its source, for the billing repository only.
- The team channel in Slack A message to the reviewer linking the Jira issue, the draft pull request and the Task, with what was tested and what was not checked. The report also goes onto the Jira issue.
What the team decides
- Reviewing and merging both pull requests.
- How far the rule reaches, the billing repository or the whole organization. Jigward keeps it as one reviewer's request for one repository.
- Whether to take up the initiative for an automated architecture check.
What Jigward did not check
- The four older calls to Instant.now(), left as they were in code Jigward did not write.
- Due dates in time zones other than UTC.
- Other repositories. The request reaches the billing repository only.
Meet your next engineering coworker
Bring a question
from your own project.
See how Jigward can help your team understand the system and move the next task forward.
Jigward is in closed testing. Accounts are created by hand; sending a request does not create one.