浏览代码

c:\o3de\gpush

Royal OBrien 4 年之前
父节点
当前提交
3ccdf918c8

+ 37 - 0
.github/ISSUE_TEMPLATE/Meeting-Agenda-Template.md

@@ -0,0 +1,37 @@
+---
+name: 'Meeting Agenda: Create New'
+about: Use this template to create a new meeting agenda.
+title: Proposed SIG-UI-UX meeting agenda for MMMM-DD-YY
+labels: mtg-agenda
+assignees: ''
+
+---
+
+## Meeting Details
+
+- **Date/Time:** Month Date, Year @ XX:XXpm UTC / XX:XXpm ET
+- **Location:** [Discord SIG-UI-UX Voice Room](https://discord.gg/Mc6jStmuMK)
+- **Moderator:** TBA
+- **Note Taker** Person
+
+The [SIG-UI-UX Meetings](https://github.com/o3de/sig-ui-ux/tree/main/meetings) repo contains the history past calls, including a link to the agenda, recording, notes, and resources.
+
+## SIG Updates
+
+**What happened since the last meeting?**
+
+## Meeting Agenda
+
+**Discuss agenda from proposed topics**
+
+## Outcomes from Discussion topics
+
+**Discuss outcomes from agenda**
+
+## Action Items
+
+**Create actionable items from proposed topics**
+
+## Open Discussion Items
+
+List any additional items below!

+ 73 - 0
.github/ISSUE_TEMPLATE/rfc-feature.md

@@ -0,0 +1,73 @@
+---
+name: RFC Feature request
+about: Create Feature RFC for this project
+title: Proposed RFC Feature: =description=
+labels: 'rfc-feature'
+assignees: ''
+
+---
+
+# O3DE RFC Feature Template
+
+### When using this template, you do not have to fill out every question below. The questions are there for guidance.
+
+This RFC feature template should be used for any feature that is not a bug or a substantial reorganization of the O3DE product.
+
+If you submit a pull request to implement a new feature without going through the RFC process, it may be closed with a polite request to submit an RFC first.
+
+A hastily proposed RFC can hurt its chances of acceptance. Low-quality proposals, proposals for previously-rejected features, or those that don't fit into the near-term roadmap may be quickly rejected, demotivating the unprepared contributor. Laying some groundwork ahead of the RFC can make the process smoother.
+
+Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other project developers beforehand to ascertain that the RFC may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building.
+
+The most common preparations for writing and submitting an RFC include:
+- Talking the idea over on our Discord server.
+- Discussing the topic on our GitHub RFCs discussions page.
+- Occasionally posting "pre-RFCs" on the GitHub RFCs discussion page.
+You may file issues in the RFCs repo for discussion, but these are not actively looked at by the teams.
+
+As a rule of thumb, receiving encouraging feedback from long-standing project developers, and particularly members of the relevant sub-team, is a good indication that the RFC is worth pursuing.
+
+# ----- DELETE EVERYTHING FROM THE TOP TO THE SUMMARY LINE BELOW WHEN USING TEMPLATE ----- #
+
+### Summary:
+Single paragraph explanation of the feature
+
+### What is the relevance of this feature?
+Why is this important? What are the use cases? What will it do once completed?
+
+### Feature design description:
+- Explain the design of the feature with enough detail that someone familiar with the environment and framework can understand the concept and explain it to others. 
+- It should include at least one end-to-end example of how a developer will use it along with specific details, including outlying use cases. 
+
+- If there is any new terminology, it should be defined here.
+
+### Technical design description:
+- Explain the technical portion of the work in enough detail that members can implement the feature. 
+
+- Explain any API or process changes required to implement this feature
+
+- This section should relate to the feature design description by reference and explain in greater detail how it makes the feature design examples work.
+
+- This should also provide detailed information on compatibility with different hardware platforms.
+
+
+### What are the advantages of the feature?
+- Explain the advantages for someone to use this feature
+
+### What are the disadvantages of the feature?
+- Explain any disadvantages for someone to use this feature
+
+### How will this be implemented or integrated into the O3DE environment?
+- Explain how a developer will integrate this into the codebase of O3DE and provide any specific library or technical stack requirements.
+
+### Are there any alternatives to this feature?
+- Provide any other designs that have been considered. Explain what the impact might be of not doing this.
+- If there is any prior art or approaches with other frameworks in the same domain, explain how they may have solved this problem or implemented this feature.
+
+### How will users learn this feature?
+- Detail how it can be best presented and how it is used as an extension or a standalone tool used with O3DE.
+- Explain if and how it may change how individuals would use the platform and if any documentation must be changed or reorganized.
+- Explain how it would be taught to new and existing O3DE users.
+
+### Are there any open questions?
+- What are some of the open questions and potential scenarios that should be considered?

+ 61 - 0
.github/ISSUE_TEMPLATE/rfc-suggestion.md

@@ -0,0 +1,61 @@
+---
+name: RFC Suggestion request
+about: Create Suggestion RFC for this project
+title: Proposed RFC Suggestion: =description=
+labels: 'rfc-suggestion'
+assignees: ''
+
+---
+
+# O3DE Suggestion RFC Template
+
+### When using this template, you do not have to fill out every question below. The questions are there for guidance.
+
+This RFC template should be used for any suggestion that is not based upon code or content related to the O3DE product itself. This template is for proposing new process models, approaches, or ideas to improve the O3DE community.
+
+A hastily proposed RFC can hurt its chances of acceptance. Low-quality proposals, proposals for previously rejected features, or those that do not have any substantive value to the project may be quickly rejected, demotivating the unprepared contributor. Laying some groundwork with others in the community ahead of the RFC can make the process much smoother.
+
+Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from other project members beforehand. Keep in mind that you want other members to contribute and back your suggestion, which can drastically improve the chances of implementation.
+
+The most common preparations for writing and submitting an RFC include:
+- Talking the idea over on our Discord server.
+- Creating a discussion on our GitHub RFCs discussions page.
+- Occasionally posting "pre-RFCs" on the GitHub RFCs discussion page.
+You may file issues in the RFCs repo for discussion, but these are not actively looked at by the teams.
+
+As a rule of thumb, receiving encouraging feedback from long-standing community members is a good indication that the RFC is worth pursuing.
+
+# ----- DELETE EVERYTHING FROM THE TOP TO THE SUMMARY LINE BELOW WHEN USING TEMPLATE ----- #
+
+### Summary:
+Single paragraph explanation of the suggestion
+
+### What is the motivation for this suggestion?
+Why is this important? 
+What are the use cases for this suggestion?
+What should the outcome be if this suggestion is implemented?
+
+### Suggestion design description:
+- Explain the suggestion with enough detail that someone familiar with the process and environment of the project can understand the suggestion and explain it to others.
+- It should include at least one end-to-end example of how the community will use it along with the specific details with outlying use cases. 
+
+- If there is any new terminology, it should be defined here.
+
+### What are the advantages of the suggestion?
+- Explain the advantages of using this suggestion
+
+### What are the disadvantages of the suggestion?
+- Explain any disadvantages or trade-offs to using this suggestion
+
+### How will this be work within the O3DE project?
+- Explain how this suggestion will be work within the O3DE project.
+
+### Are there any alternatives to this suggestion?
+- Provide any other alternative ways that have been considered. 
+- Explain what the impact might be of not implementing this suggestion.
+- If there are other similar suggestions previously used, list them and explain which parts may have solved some or all of this problem.
+
+### What is the strategy for adoption?
+- Explain how new and existing users will adopt this suggestion.
+- Point out any efforts needed if it requires coordination with multiple SIGs or other projects. 
+- Explain how it would be taught to new and existing O3DE users.

+ 7 - 1
README.md

@@ -1 +1,7 @@
-# sig-ui-ux
+# O3DE UI-UX SIG - Meeting resources
+
+Meeting notes from the [O3DE Meetings](https://o3de.github.io/foundation/sigs/sig-ui-ux/).
+
+The [full table of previous meetings](https://o3de.github.io/foundation/sigs/sig-ui-ux/?id=previous-meetings) is available here.
+
+# General Resources

+ 125 - 0
governance/SIG UI-UX Charter.md

@@ -0,0 +1,125 @@
+# ****SIG UX Charter****
+
+**This charter adheres to the Roles and Organization Management specified in <sig-governance>. Team information may be found in the <readme.md>**
+****Overview of SIG****
+**Two concise lines explaining what this SIG does with bullet points of the major responsibilities**
+The UX SIG is an overarching SIG that creates and approves all future interface direction for Open 3D Engine. This SIG major role is to validate design direction and provide materials to help establish future direction of the interface. This includes documenting all patterns for all developers to follow when submitting code to our repository. 
+** **** **
+****Goals****
+
+* Major goals that  SIG seeks to generally achieve
+    * It is the responsibility of this group validate all design direction based on customers feedback or usability studies to confirm direction.
+
+****Scope****
+
+* Generalized  overall scope of work
+
+****In scope****
+
+    * Define and publish requirements for project Information Architecture designs.
+    * Research and publish UX standard best practices and approaches.
+    * Define and publish standard strings and terminology.
+    * Define and publish tooltip formatting and mouse over context dynamic help display guidelines. 
+    * Define and publish iconography and standard XYZ
+* ****Design System** **
+    * Best practices
+    * Alignment to our [Style  guide](https://tbd.o3de.org/UI+Style+Guide)
+    * Alignment to our [pattern  library](https://tbd.o3de.org//Pattern+Library)
+    * Changes or modifications to  existing controls (UI 2.0)
+    * Adjustment to the existing layout  or color.
+    * Updates to UX documentation 
+* ****Information Architecture (IA)****
+    * Sitemap
+    * Journey map
+* Architecture and navigation help
+* ****UX Research****
+    * Customer feedback
+    * Personas
+    * Survey / polls
+    * System Usability scale (SUS)
+    * Stakeholder reviews
+    * Customer review 
+    * Mental model
+* ****Content****
+    * UI strings / Terminology
+    * Errors 
+    * Tooltip text
+    * Communication (Voice and tone)
+* ****UI (User interface)****
+    * Use cases
+    * Sign off review 
+    * Prototype / Sketching
+    * Interaction design
+    * Workflows / Screen-flow
+    * wire-framing 
+* ****Visual design****
+    * Graphical help
+    * Text help
+    * Graphics or imagery 
+    * Motion design.
+    * Added, removed or modified an  icon(s)
+
+ 
+
+* Items that are  the core responsibilities of SIG
+
+****Cross-cutting Processes****
+
+* Consult with SIG  teams on feature development of UI/UX feature experience
+* Provide verification  and approval of feature interface design to ensure consistency.
+* Design and implement  processes for design review and approval across SIGs for features
+* Work with SIG  chairs to ensure compliance
+* Notify SIGs when  feature is not compliant, and escalate if required to TSC
+* Maintain involvement  of cross sig member representative in UI/UX SIG.
+    
+    
+* ****Items that span  or require other SIGs or groups and how it relates to this SIG’s  responsibilities****
+
+****Out of Scope****
+
+* Not responsible  for developing and maintaining UI/UX code features.
+* Not responsible  for designing feature user interfaces, but may be consulted with for guidance  and assistance.
+* Not directly responsible  for developing graphics or iconography for features, but may be consulted  with for guidance and assistance.
+* Items that are  optional or are not the responsibility of this SIG.
+
+****SIG Links and lists:****
+
+* Joining this SIG
+* Slack/Discord
+* Mailing list
+* Issues/PRs
+* Meeting agenda  & Notes
+
+****Roles and Organization Management****
+SIG Docs adheres to the standards for roles and organization management as specified by <sig-governance>. This SIG opts in to updates and modifications to <sig-governance>
+****Individual Contributors****
+Include review document to provide alignment and understanding of proposed contribution.
+ 
+****Additional information not found in the sig-governance related to contributors.****
+****Maintainers****
+Ensure contributions follow design standards and patterns before merged.
+****Additional information not found in the sig-governance related to contributors****
+****Additional responsibilities of Chairs****
+Additional information not found in the sig-governance related to SIG Chairs
+****Subproject Creation****
+Additional information not found in the sig-governance related to subproject creation
+****Deviations from sig-governance****
+Explicit Deviations from the sig-governance
+
+* * *
+Open conversation topics: 
+
+* What are our core tenants? 
+* How do outside designers submit changes?
+* What do we do if someone outside our group  submits stuff we hate?
+* How do we break a disagreement between (two  designers) (two contributors). This could be from different companies.
+* What is the submission request process for our  team?
+* How often should we be communicating with the global  and local communities?
+* What are our expectations of developers when submitting  UX content?  
+* What are the roles and responsibilities? 
+* What happens if we find work that shouldn’t have  gone to production without UX feedback?
+* Can someone hire the O3DE UX team to make a  specific tool for their game team?
+* What will we do?
+* What won’t we do?
+* Will we show our current task and roadmap somewhere  online? 
+

+ 35 - 0
meetings/readme.md

@@ -0,0 +1,35 @@
+# O3DE UI-UX SIG - Meetings
+
+## Meetings
+
+Each SIG hosts a regular community meeting to update the community about the progress of the project and the SIG's contribution to the project. It is a recurring event to give everyone a chance to have their voice heard. The SIG holds its meetings each - TBD - , and future meetings are held based on the [agendas on GitHub](https://github.com/o3de/foundation/issues?q=is%3Aopen+label%3Asig%2Fui-ux+label%3Amtg-agenda+).
+
+Please [reach out on Discord](https://discord.gg/F8jjUmpCBG) or [Sign up on the Mailing Lists](https://lists.o3de.org/groups) to get notifications for the recurring events.
+
+## Who can Attend
+
+O3DE cannot work without the help and input from as many of its community members as possible. *You do not need anyone’s permission to get involved and contribute to the project.* The #sig-ui-ux channel on [O3DE Discord](https://discord.gg/Mc6jStmuMK) is a great place to begin getting involved. Many of our community members regularly share ideas, updates, and resources there. You can also find a number of topics under the [GitHub Discussions area](https://github.com/o3de/foundation/discussions) which need your input.
+
+## Agenda Items
+
+You can find a link to the proposed agenda for the next call in the table below. The agenda for each meeting is saved as [an issue on Github](https://github.com/o3de/foundation/issues?q=label%3Asig%2Fui-ux+label%3Amtg-agenda+) under the O3DE [Foundation repository](https://github.com/o3de/foundation).
+
+Please feel free to propose any of your topics, thoughts, or areas you feel are important to discuss.
+
+# Previous Meetings
+
+Below is a list of all prior completed meetings and related resources.
+
+## Documentation Special Interest Group
+
+| No   | Date       | Time | Agenda  | Media | Notes | Resources |
+| ---- | ---------- | ---- | ------- | ----- | ----- | ---- |
+| 0001 | 2021-00-00 | 0000 UTC | n/a | n/a | Link | Link |
+
+# General Resources
+
+See [O3DE Resources](https://o3de.github.io/o3de/foundation) for additional information related to any SIG in O3DE.
+
+# Licensing
+
+The O3DE/foundation repository and all contributions under this repository herein are licensed under [Creative Commons Attribution 4.0 International License](http://creativecommons.org/licenses/by/4.0/). Please note that, by contributing to this repository, whether via commit, pull request, issue, comment, or in any other fashion, **you are explicitly agreeing that all of your contributions will fall under the same permissive license.**