-
Notifications
You must be signed in to change notification settings - Fork 8
Normalize terminology to fit other standards #23
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
Normalize terminology to fit other standards #23
Conversation
The "compliant/non-compliant" terminology really helps get rid of some of the "emotional overtones" of the guidelines. And I really like the "decidability" term! Looks great - thank you! |
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.
+1 for the language change!
(no review of the code change)
Thanks for the feedback @adfernandes! I'm likely going to go ahead and merge this over the weekend barring any concerns from folks. That'll allow me to freshen up #16 to line up with these changes. |
Ah and thank you @AlexCeleste! 🤝 |
Also good news -- the nightly build works + properly breaks on upstream changes in FLS
Could use an improvement to only break the build if there's a guideline effected though! Maybe? Hmm, not so sure on second thought. Maybe better to always require human intervention? |
Based on some suggestions in #19, I've tried to align to other existing standards' categories for various things
Added
Also
fls.lock
tospec.lock
to make this update a little easier later when we migrate from FLS to the upstreamed version../make.py
to allow us to update thespec.lock
after resolving the breaking checksums