Skip to content
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

Open
Cali0707 opened this issue Jun 13, 2024 · 5 comments
Open

Define what being an "approver" means for the UX WG #153

Cali0707 opened this issue Jun 13, 2024 · 5 comments
Assignees

Comments

@Cali0707
Copy link
Member

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.

@Cali0707
Copy link
Member Author

/cc @knative/steering-committee
/cc @knative/ux-wg-leads

@Cali0707 Cali0707 self-assigned this Jun 13, 2024
@Cali0707
Copy link
Member Author

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

@aliok
Copy link
Member

aliok commented Jun 13, 2024

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.

@Leo6Leo
Copy link
Member

Leo6Leo commented Jun 13, 2024

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:

Designers measured the success of an ongoing project in two slightly contrasting ways: when receiving no feedback (but no resistance) and receiving feedback (with low or understandable resistance). The designers saw their work as successful when they saw the feedback they received as relevant and useful. Often, the designers saw their designs as successful, which is unsurprising since they used usability tests and user interactions to inform their design.

Based on reading this and relate some of my thoughts, I think some of the following ideas may be suitable:

  1. Nomination by WG Leads

  2. Contribution Metrics:

    • Number of Completed PRs/Contributions. (This is from Knative Approver req., and I think this may not be fair in this case, if the project/task is huge, but the work is done in 1 PR)
    • Quality of Contributions: Assess the impact and quality of contributions through feedback from peers and the success of implemented designs.
  3. Community Engagement:

    • Active Participation: In WG meetings, discussions, and design reviews.
    • Documentation and Knowledge Sharing: They should help document design processes and share knowledge through blogs, tutorials, or presentations or etc.
  4. Consistency and Long-Term Involvement:

    • Sustained Contributions: A history of sustained contributions demonstrating commitment over X months.
  5. Ask them to submit a self-nomination letter or text listing their contributions and the impact they have made on the community.

So self-assessments, peer reviews feedback, and community feedback to evaluate candidates fairly!

@Cali0707
Copy link
Member Author

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 !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants