As a software user, I want to see the known bugs for a component release #49
Comments
|
@tloubrieu-jpl as a heads up, whenever we create requirements, we should be sure to set a priority (p.must-have, p.should-have, p.could-have, p.wont-have) prior to removing the |
|
ok, thanks @jordanpadams |
|
That should be added in the release notes. |
|
I tried to update the parameters of the automated release note by following instructions on https://github.com/github/docs/blob/main/content/repositories/releasing-projects-on-github/automatically-generated-release-notes.md but the only allows to select entries from the Pull Request list, it does not enable to pull entries from the issues. So this option does not seem appropriate. I suggest to manually add a section for open critical and high severity bugs. See example https://github.com/NASA-PDS/registry-api/releases/edit/v1.2.0 |
|
@tloubrieu-jpl added this to sprint backlog since we said we were going to do it. let me know if we should defer |
|
The proposal is to add the version label to the open bugs at the time of a release (see command created by the PR NASA-PDS/lasso-issues#4). The command could be called automatically by roundup for stable releases. See ticket NASA-PDS/roundup-action#128 Then the following text (for example) need to be added manually at the end of the release notes: |
|
Re-open because one sub-ticket is not closed. |
|
All sub-tasks completed |
github-project-automation
bot
moved this from Backlog
to 🏁 Done
in EN Portfolio Backlog
🧑🔬 User Persona(s)
software user
💪 Motivation
...so that I can quickly see the known bugs and for each 'major/high' criticality bug, find a work-around.
📖 Additional Details
This is a feedback from the DDR review on 11/31/2022.
⚖️ Acceptance Criteria
Given
When I perform
Then I expect
⚙️ Engineering Details
Skipping I&T Rationale
i&t.skip label applied because this is an internal tracking mechanism with no affect on the software delivered.
The text was updated successfully, but these errors were encountered: