Add automated release blog guideline #70
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
✅ Deploy Preview for playful-gelato-7892ba ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
chartgerink
changed the title
Bisaloo
approved these changes
Jan 30, 2024
jamesmbaazam
approved these changes
Jan 30, 2024
joshwlambert
approved these changes
Jan 30, 2024
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.
This PR adds a blueprint guideline regarding automated blog posts for new releases of packages. This change follows on the discussions in epiverse-trace/epiverse-trace.github.io#135, where it became clear that a guideline can provide clarity. Inviting the original participants of the discussion for sharing their thoughts :-)
This PR explicates that patch release blogs are not a necessity, but are possible at the discretion of the code owner. This helps unburden those who may feel like it is a necessity, but also gives flexibility for the code owners of the package to make the final call (context matters).
Scenario
I can imagine the scenario where a patch is for a critical vulnerability may require an urgent update to our community in the form of a blog. It also gives guidance to team members that they are not required to release a blog for patches.
Next steps
Given this is a small change that will not substantively change the immediate situation, I will move ahead if no objections arise before end of the week.