The Triple-R pattern organizes a change-request comment around three questions: What should change? Why is it warranted? How will completion be recognized? section 6.1.3
Compose the comment in this order:
- Request: state the action you want the author to take. section 6.1.3
- Rationale: explain why the change is warranted, using relevant references or links. section 6.1.3
- Result: describe a measurable end state, such as a metric, screenshot, or expected code structure. section 6.1.3
Moving a method
Request: move AuthenticateUser() into AuthenticationUtilities. Rationale: related authentication methods already live there, and the team agreement places authentication behavior in that library. Result: calls use the library rather than a standalone declaration. section 6.1.3
needs change: Can we update this endpoint to use version 3 (v3)? The call to our getCoordinates() method currently references version 2 (v2), a soon- to-be-deprecated (link) version, which will cause functionality to break. Also, our other endpoints are already using v3; updating this will keep our code consistent.
Compare a concrete endpoint-update comment that combines the requested action, deprecation rationale, consistency argument, and intended outcome. section 6.1.3
