-
Notifications
You must be signed in to change notification settings - Fork 22
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
Define what being an "approver" means for the UX WG #153
Comments
/cc @knative/steering-committee |
I don't have a clear idea of what the requirements should be yet, if anyone has any thoughts please add them below! In particular, a lot of our current requirements are very github/code centric, and most of the work for this group is happening in google docs, figma, and canva |
Thanks for bringing this up! Have you folks have an idea? I was hoping to plan a meeting with Red Hat UX team to discuss things like this, but couldn't make that happen. Let's check with TAG Contributor Strategy and Non-Code initiative. |
I feel that establishing standardized criteria for UX work can be challenging since it heavily involves human interaction, design thoughts, and idea generation. However, we can still get some inspiration from Knative's approver requirements. (i.e require nominees to be endorsed by WG leads) The following text from a research report (Diary-Studies-Designers-in-OSS) provides valuable insight into how designers measure the success of their projects, I recommend you check it out:
Based on reading this and relate some of my thoughts, I think some of the following ideas may be suitable:
So self-assessments, peer reviews feedback, and community feedback to evaluate candidates fairly! |
Personally, I like a lot of the points except for the self-nomination one. Currently, the other WGs require "nomination from a WG lead" to become an approver, so I would prefer to stick with that rather than allowing for self nomination. Otherwise, I love the suggestions @Leo6Leo ! |
As our WG expands and has more longer term contributors, we should come to a definition of "approver" for our group, as well as a set of requirements for achieving it. Looking at the current requirements, I'm not sure how well they map on to our work.
The text was updated successfully, but these errors were encountered: