doc: use pull request title pattern for issues too #4057
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
leighmcculloch
changed the title
Co-authored-by: Alec Charbonneau <[email protected]>
ire-and-curses
approved these changes
Nov 16, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What
Prefix issues by their primarily affected service or area of the monorepo.
Why
It's difficult to sometimes understand what the scope of an issue is because our issue titles assume the reader has some prior knowledge that the scope relates to the Go SDK, or Horizon, or something else. Sometimes we don't provide this context at all in the title, other times the context can be found in labels, and other times we do mention it in the title but inside the text.
We have a really clear pattern for communicating this in pull requests: we prefix titles with their area most affected. This results in pull requests having titles like
services/ticker: ...oringest: .... This pattern can be applied to issues as well.We have several teams working in this repository and so context is not always obvious to people in other teams.
The Go community also has a well established pattern of using this for issues at pull requests in the golang/go repo, and it shows up in the ecosystem too, and it is a helpful pattern in that much larger complex repo, so should scale well here too.
Known limitations
N/A