-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Issue assignment clarity #3511
Issue assignment clarity #3511
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added some comments but this looks good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One more suggestion to make sure we cover all false positives
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @joemull, it all looks much clearer now
The issue described in #2750 has likely been fixed, but in investigating it, I found a bug in the View Metadata modal that meant users could not change Projected Issue after it was set, because they were sent to the Issue Manager instead of the Projected Issue assignment form.
I changed the link to the correct form, but I did not want to get rid of the link between View Metadata and the Issue Manager, because even if it was the "wrong" link, some people might be using it to manage primary issue assignment before pre-publication. So I added a table for Primary Issue to View Metadata below Projected Issue, and I clarified the text around these forms so that new editors could more easily get up to speed on the difference between Projected and Primary and manage both flexibly.
Closes #2750