-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
Severity #16921
Severity #16921
Conversation
▫️# the commit.
✅ Deploy Preview for v11-carbon-react ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for carbon-elements ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Initial thought on docs, I think we could break down "missing" into major and minor pieces. Docs Sev 2: "The documentation is wrong or missing major details". Docs Sev 3: "The documentation is mis-leading, somewhat true, or missing minor details"
|
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.
Looks good! One minor suggestion on the first column
Co-authored-by: Taylor Jones <[email protected]>
Co-authored-by: Taylor Jones <[email protected]>
Co-authored-by: Taylor Jones <[email protected]>
Co-authored-by: Taylor Jones <[email protected]>
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 think these are good for general descriptions. I think at some point we could better define what is considered "major" versus "minor"
Agreed. In my mind, as we start to tackle these types of issues, we'll start to find harden our POV on major vs. minor. What's important is that we're identifing defects and having the conversations. |
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.
❤️
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 apologize for nitpicking. We have some inconsistent usage of workaround
, work-around
, and work around
. 😉
no apology needed! Fixing now! |
Co-authored-by: elysia <[email protected]>
Co-authored-by: elysia <[email protected]>
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 for doing this, Scott!
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.
Thank you Scott!
e21d106
Brief
As a maintainer of the Core Components of Carbon, I would argue that we have an incredibly polished process for triaging defects in our codebase and turning those bugs around into fixes in our regular sprint cadence.
However, I think things tend to fall apart when we extend the idea of triaging and fixing defects in the other pillars of our design system, our Figma kit and our Documentation. This PR aims to remedy that with a comprehensive point-of-view on our approach to applying severity to not only our Code, but our Kit and Docs as well.
Testing
To review, click on the
Files changed
tab above, then click the button to display rich diff.Scroll down to the Triaging section to see the table.
I'm looking for feedback on not only these descriptions, but on the very idea of assigning severity to defects in not just our code, but our docs and our kits as well.