forhalle
commented
3 years ago This documentation is phenomenal, Josh!
From: Joshua Rainbolt @.> Sent: Wednesday, October 20, 2021 4:30 PM To: o3de/sig-ui-ux @.> Cc: Ford, Halle @.>; Mention @.> Subject: [o3de/sig-ui-ux] Proposed RFC Suggestion = O3DE Sig UX/UI - process, guidelines and quality standard (Issue #44)
Summary:
The Sig UX-Ui team has been working on our ticket triage process. We've defined some of the new rules around how and what actions should be taken. We have worked with @forhallehttps://github.com/forhalle, @yuyihsuhttps://github.com/yuyihsu, @AMZN-Livhttps://github.com/AMZN-Liv, and @mcphedarhttps://github.com/mcphedar to establish the best rules we can based on the most current process we have in place. Please note that anything added can be changed at a later point, but these will act as guiding principles until we know better.
What is the motivation for this suggestion?
Why is this important? We already have three Sig Ux Ui documents that captures some of our rules, but these documents don't define the ticket triage process. We want to keep these documents up to date with the latest perspective.
What are the use cases for this suggestion? I as a Sig Ux Ui member want to understand the rules of triage and how its performed. How would I learn about these rules?
What should the outcome be if this suggestion is implemented? We will post this RFC for one week to receive feedback and address any open concerns about the process. If there are no major objections. We will add our content to the following governance charter documentationhttps://github.com/o3de/sig-ui-ux/blob/main/governance/UI-UX%20for%20O3DE.md.
What is the strategy for adoption?
Yuyi and myself will be test driving the process within the next couple of weeks to make sure we haven't incorrectly defined any details and making any minor adjustments as we encounter new use cases. We will append those details to this document if any are encountered.
O3DE Sig UX/UI - process, guidelines and quality standard
In May 2021 we began working on our goal “Build a UX charter with scalable process and guidelines to support community autonomy”. The definition of this goal is; establish the UX process, guidelines and quality standard to enable the community to build consistent and quality user experience in O3DE.” The definition define below is not the finish line for us but a baseline we intend to continue to work on and refine. We are currently testing for a broad number of contributors and learning styles in the community to improve on this model.
If you're curious about our other Sig Ux UI charter documents, you can read them here. UX charterhttps://github.com/o3de/sig-ui-ux/blob/main/governance/SIG%20UI-UX%20Charter.md, Interacting with UX Sighttps://github.com/o3de/sig-ui-ux/blob/main/governance/UI-UX%20for%20O3DE.md, Patterns for O3DE UX /UIhttps://github.com/o3de/sig-ui-ux/blob/main/governance/UX%20Patterns%20for%20O3DE.md
So what does the Sig UX-UI charter already have defined?
- Roles and responsibilities of the Sig UX-UI group.
- How do we handle disagreements.
- Define our cross-cutting activities and how do we process them.
- How the Sig UX-UI patterns can be changed or added to by community contributions.
- How do developers submit new UX content that doesn’t require Sig UX UI oversite.
- A bi-weekly meeting office hours and design review.
- A bi-weekly Sig-UX-UI Charter meeting (Review open tickets, RTE improvements, answer open questions from community).
- Promote design engagement with the O3DE community by openly doing our own internal design review externally.
- On-call UX rotation (Used for discord responses)
- Create a customer engagement model.
- Maintaining the Sig email channel for updates and feedback.
- Maintaining Sig calendar to keep track of meetings and times
- Established patterns for meeting notes and documentation for GitHub.
- Rules for reviewing content (office hours / design review) + document guidelines.
Sig UX-UI charter items still in progress:
- Creating a plan on how we will handle new RFC incoming to the Sig UX-UI.
- Begin publishing our UX pattern (BlueJay design system) so the community can have the same knowledge that we do as UX designers.
New items we are adding below.
- How do we process GitHub tickets?
- New "tags" for the GitHub ticket triage process.
- Established new rules on how to evaluate and processing tickets.
- How to promote community contributions.
Mission Statement (the why):
As the Sig UX UI group. Our job is to be the voice of the customer and actively improve the vision, workflows, and patterns of O3DE. This is accomplished by reviewing and improving user reported problems through different forms of UX methodologies. We are here to promote our UX foundational guidelines and give expert feedback. The Sig-ui-ux team is an active contributors/owner of new features or services being added to O3DE. Unlike most other Sig’s UX-UI is a cross cutting team and that means we need the ability to review tickets and potentially request for additional changes, change direction, or reject work. Each of these kinds of decision would be done in close collaboration with PM or SDM to verify stakeholder agreement.
How are we processing tickets?
We have now established some ground rules about how ticket triage will work. These are the steps until we learn better.
- A Sig-UI-UX Maintainer will drive our Bi-weekly Wednesday Sig Triage calls on tickets. As well as attend the #Sig-Release O3DE Issue Triage on Monday and Wednesday. During these meetings in conjunction with the Sig UI-UX Reviewer community we will apply our tags and status
- A reviewer will have the ability to add remove tags in open conversation with the community. During that time the reviewer (Sig UI-UX representative) will be able to drive the conversation around what labels should be added and removed. Long term, I would expect that specific reviewer members who earn the label "Sig UX UI staff" would earn these same abilities and could step in to drive these conversations. Please see more about leveling up below.
- During this triage session this representative needs to make a few calls. Does the ticket we are looking at have a UX workflow that will affect the user’s visual understanding of O3DE in any way. If it does, one or more of the following tags should be applied.
- Sig/ui-ux: This indicates there is some unspecified amount of work needed to be review by the UX team. This tag doesn’t give any specific details about complexity, approval needs or any specificity about time. This is a mere indicator that UX involvement is needed to some degree. This tag should only be removed by someone representing our UX group.
- needs-ux-action: We would add this tag in addition to the previous tags. So, someone has identified that this ticket cannot proceed without action being taken from the UX team. This will need a specific UX owner. Time for assigning owners will be allotted in the Sig-UI-UX triage session for this. However, owners can be added by anyone. This tag should only be removed by someone representing our UX group.
- status/needs-ux-approval: This tag will be added to a ticket where there is some unspecified amount of changes that impact the workflow and or UI and it requires UX eyes before it can be delivered to production. This tag doesn’t mean UX is required to deliver mock or graphics for this ticket. However, it does require a UX person to give a sign off on the ticket that it doesn’t conflict with any known design patterns, upcoming work, or breaks any foundational patterns we have already established. This tag should only be removed by someone representing our UX group.
- ui-ux/in-design: After a ticket has been assigned to a designer. The ticket should be marked ui-ux/in-design“ indicating this ticket is active and In progress by a design resource. This tag would be removed if the task is resolved or if the ticket is being moved out of the UX workstream. This ticket tag can be added and removed as many times as needed.
- status/ux-approved: This tag is added to ticket who have UX final sign off for a ticket. This should not be added to a ticket until all UX actions are completed including, design, research, feedback. This ticket does not mean sign off is good from PM or SDM. This means from the UX point of view all task related to UX have hit the quality and clarity bar that we are ok with proceeding with this solution. This tag should only be added by the UX designer who owns this work. When marking approved on a ticket the user should also re-assign the ticket back to the developer or SDM who owns the workstream (if one is not already included).
- Sometime it will be obvious and we can assign a feature label if known.
- if it needs UX action we need to go through the list a second time and assign specific owners to items that need action. If no UX owner this mean the item is pending triage ownership.
- If UX reviews a ticket and determine that ux is not needed we will remove our tag but also add a comment specifying please follow ux patterns, ok to proceed without ux.
- When processing UX tickets either in Sig-UX-UI or Sig-Release meeting please keep in mind the following use cases that don’t get resolved by a tag.
How would development and UX share a single ticket?
From an ownership perspective GitHub allows for more than one owner of a ticket. This means the ticket that have UX should have two assigned contributors. UX owners will not remove development resources. We will try to keep most details in the ticket comments. However, some documentation might be linked outside GitHub Including Figma designs or Qualtrics research data.
Which team should own this ticket: Development or UX?
UX can be assigned as a co-owner from a team perspective. No single threaded ownership is required anymore. You can assign two teams.
How is a ticket marked as “rejected” or “please fix“ if it’s just UX rejected?
If a ticket is rejected or asked for additional updates, we will change the status of the ticket to match its current state regardless of split deliverables. This means a ticket can be set as rejected with qualifiers but still be good from a code point of view. We imagine this might change as we learn more.
When should we be removing any of the labels?
The primary time when we can remove label is when the ticket is marked “Status/ux-approved”. At that point you can remove “need-ux-action” and “ui-ux/in design”
During our bi-weekly Sig-ui-ux charter meeting we will do the following actions:
- Review all the tickets labeled Sig/ui-ux ** that have not already been processed. (Open tickets only)
- Review any tickets we have recently closed that would be useful for the group to understand any major changes to the workflow.
- Identify any new patterns / icons that need to be added to our library or BlueJay design system documentation.
- Help unblock designers if they need clarification on next step or resources to reach out to.
- Add team and specific UX owners to the tickets for processing.
- Assign which UX contact should be looked at the ticket (if one is known).
- Try to categorize the tickets into different buckets during triage. Completed, in-progress, not started, and backlog / rejected.
What's our plan for more community contribution?
- We have externalized all of our major design related activities so that the public can attend. This includes ticket triage, UX design review, Rev the engine updates, Blue Jay Design system reviews, and open office hours.
- The Sig-ui-ux team holds two standing meetings. This meeting meets every Wednesday but alternates discussion points based on week.
- These meetings are communicated on the O3DE calendar, O3DE UX mailing list, GitHub issues (mtg-agenda), and on discord before every meeting.
- For these meeting we will look for creative ideas of topic name to peak user interest (Example from JT: UX smacking. Test-drive Tuesday, etc.)
- Get the community involved in the conversation (if possible).
- Lurkers can often be our next best customer. So help them feel included but don’t be forceful with the conversations or topic. Let them lurk and join the conversation when ready.
- Don’t ghost the community.
- Make sure after a decision has been made in the public that you don’t forget to relay the outcome to the group.
- Do our best to answer question posted in the group as soon as possible. A lack of response can chase people away.
- We will help prioritize use case or problems effecting the expert. Then secondarily hobbyist and influencers.
- Expert discussions: as we are working on specific topics of conversation, we plan on reaching out to different members of different game teams directly to give different demos or test a specific workflow. In these situations we might provide gift cards as a thank you for your time and energy. More details about the specific contribution will be made available as we have them.
How do we make sure that community contribution is rewarded?
- First and foremost. Not all good ideas come from just us. So, we want to make sure we acknowledge the people who contribute good ideas. This is either in conversation amongst the group or writing shared amongst Sig-ui-UX group. Please note that this Sig-ui-ux group doesn’t have the power to make announcement on behalf of O3DE, but related to UX when we are given the floor, we intend to recognize your contribution.
- Individual contributors have the option of earning different status among the UX team including Git privileges.
- An assigned UX designer on a ticket will note on that ticket any external contributions which helped. Based on the number of tickets this individual has been helpful in accomplishing he will be assigned a badge level. Badge level will indicate your status.
- Beginner-level - 0 to 5 tickets (5 tickets)
- Green-level - 6 to 16 tickets (10 tickets)
- Mid-Level - 17 - 32 tickets (15 tickets)
- Advanced-level - 33 to 53 tickets (20 tickets)
- Staff - 54 and above
Other ideas to raise customer engagement: (Thanks JT for your contribution)
- As a system we should work in close collaboration with 3rd party tools. These contributors will bring with them a ton of their own developers and users. So, supporting the smaller ecosystem will help make community contribution higher.
- When working on issues, try not refer to a “unspecific task name/number” instead refer to the customer problem we are looking at when announcing topics of conversation for meetings. This will attract people to very specific conversations that interest them.
- Consider using some kind of voting system to allow people to participate who might not have the time to be vocal in their contributions.
- Use a system called “Graphic-all” which allows user to download experimental builds with maybe two alternative UX workflows. People become invested in seeing their option do well.
- Pay attention to YouTube comments specific to UX and follow up with individuals that have something to say but maybe are not active contributors.
- Beware and have strict rules around people who want to get leadership abilities by paying for their badge system. The badges should be earned not paid for.
- Help promote learning tutorial videos and ask to be a contributor and or ask them to promote Sig-ux-ui group.
- Go into all the social media and engage in the conversation on these other platforms.
rainbj
Summary:
The Sig UX-Ui team has been working on our ticket triage process. We've defined some of the new rules around how and what actions should be taken. We have worked with @forhalle, @yuyihsu, @AMZN-Liv, and @mcphedar to establish the best rules we can based on the most current process we have in place. Please note that anything added can be changed at a later point, but these will act as guiding principles until we know better.
What is the motivation for this suggestion?
Why is this important? We already have three Sig Ux Ui documents that captures some of our rules, but these documents don't define the ticket triage process. We want to keep these documents up to date with the latest perspective.
What are the use cases for this suggestion? I as a Sig Ux Ui member want to understand the rules of triage and how its performed. How would I learn about these rules?
What should the outcome be if this suggestion is implemented? We will post this RFC for one week to receive feedback and address any open concerns about the process. If there are no major objections. We will add our content to the following governance charter documentation.
What is the strategy for adoption?
Yuyi and myself will be test driving the process within the next couple of weeks to make sure we haven't incorrectly defined any details and making any minor adjustments as we encounter new use cases. We will append those details to this document if any are encountered.
O3DE Sig UX/UI - process, guidelines and quality standard
In May 2021 we began working on our goal “Build a UX charter with scalable process and guidelines to support community autonomy”. The definition of this goal is; establish the UX process, guidelines and quality standard to enable the community to build consistent and quality user experience in O3DE.” The definition define below is not the finish line for us but a baseline we intend to continue to work on and refine. We are currently testing for a broad number of contributors and learning styles in the community to improve on this model.
If you're curious about our other Sig Ux UI charter documents, you can read them here. UX charter, Interacting with UX Sig, Patterns for O3DE UX /UI
So what does the Sig UX-UI charter already have defined?
Sig UX-UI charter items still in progress:
New items we are adding below.
Mission Statement (the why):
As the Sig UX UI group. Our job is to be the voice of the customer and actively improve the vision, workflows, and patterns of O3DE. This is accomplished by reviewing and improving user reported problems through different forms of UX methodologies. We are here to promote our UX foundational guidelines and give expert feedback. The Sig-ui-ux team is an active contributors/owner of new features or services being added to O3DE. Unlike most other Sig’s UX-UI is a cross cutting team and that means we need the ability to review tickets and potentially request for additional changes, change direction, or reject work. Each of these kinds of decision would be done in close collaboration with PM or SDM to verify stakeholder agreement.
How are we processing tickets?
We have now established some ground rules about how ticket triage will work. These are the steps until we learn better.
Search queries:
Tags
How would development and UX share a single ticket?
From an ownership perspective GitHub allows for more than one owner of a ticket. This means the ticket that have UX should have two assigned contributors. UX owners will not remove development resources. We will try to keep most details in the ticket comments. However, some documentation might be linked outside GitHub Including Figma designs or Qualtrics research data.
Which team should own this ticket: Development or UX?
UX can be assigned as a co-owner from a team perspective. No single threaded ownership is required anymore. You can assign two teams.
How is a ticket marked as “rejected” or “please fix“ if it’s just UX rejected?
If a ticket is rejected or asked for additional updates, we will change the status of the ticket to match its current state regardless of split deliverables. This means a ticket can be set as rejected with qualifiers but still be good from a code point of view. We imagine this might change as we learn more.
When should we be removing any of the labels?
The primary time when we can remove label is when the ticket is marked “Status/ux-approved”. At that point you can remove “need-ux-action” and “ui-ux/in design”
During our bi-weekly Sig-ui-ux charter meeting we will do the following actions:
What's our plan for more community contribution?
How do we make sure that community contribution is rewarded?
Other ideas to raise customer engagement: (Thanks JT for your contribution)