Kaynağa Gözat

Updated with new structure

Royal OBrien 4 yıl önce
ebeveyn
işleme
a5ac39018c

+ 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-Docs 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-Docs Voice Room](https://discord.gg/p3padwr58u)
+- **Moderator:** TBA
+- **Note Taker** Person
+
+The [SIG-Docs Meetings](https://github.com/o3de/sig-docs-community/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.

+ 171 - 0
governance/SIG Docs Charter.md

@@ -0,0 +1,171 @@
+# Documentation and Community SIG Charter
+
+## Overview of SIG
+
+The Documentation and Community SIG (“the SIG”) maintains the content of the official O3DE website, the publishing infrastructure for the site, API reference building pipelines, and other community resources. Broadly, the team is responsible for:
+
+* Contents of the Open 3D Engine user guide
+* Documentation for core Gems that ship with Open 3D Engine, including the Atom renderer
+* Minimum viable API documentation standards
+* Documentation requirements for engineering contributions
+* Official blogs, samples, demos, tutorials, and training
+* Managing forums, Discord, and other community engagement channels
+
+The SIG is *not* responsible for maintaining and writing all documentation. It's expected that engineers will write appropriate minimum viable documentation for each feature that they submit, though the SIG members may assist with review, editorial, and cleanup after the initial draft.
+
+
+## Goals
+
+Goals are divided by category.
+
+
+### Documentation goals
+
+* Handle issues reported with the documentation of O3DE.
+* Produce and manage official blog posts, samples, tutorials, demos, and training.
+* Manage official documentation releases.
+* Maintain infrastructure related to the O3DE site such as publishing pipelines and analytics.
+* Maintain documentation build tasks contained in the main O3DE repo, for APIs and other supplementary documentation.
+* Lead cross-cutting efforts requiring the involvement of other SIGs in review and accuracy of documentation.
+
+### Community goals
+
+* Maintain and moderate community communication channels such as forums and Discord.
+* Represent the interests of the community at large in all official O3DE business.
+* Maintain the website UX.
+* Manage contests, events, meetups, conferences, webinars, and other community-focused engagements.
+
+## Scope
+
+* Sets the standards for feature documentation and provides clear paths for docs contribution.
+* Establishes, coordinates, and maintains documentation review processes including the participation of other SIGs in technical review.
+* Maintains the Open 3D Engine website's infrastructure, tooling, and analytics.
+* Responsible for maintaining core content and UX for the site.
+* Maintains the official samples, tutorials, and demos for Open 3D Engine.
+* Assist in the submission of 3rd party Open 3D Engine components for indexing.
+* Creates subprojects or sub-SIGs to handle specific parts of the Open 3D Engine documentation and community resources as necessary.
+* Ensures the availability of resources to perform SIG work.
+
+## In scope
+
+* O3DE Website
+* Site UX
+* Site deployment and build pipelines
+* Site versioning
+* Analytics tools and data analysis
+* Non-documentation content:
+    * Blogs
+    * Community engagement
+    * Soliciting contributions and general contrib guidelines (cross-cut)
+    * Content (ex: general announcements, upcoming events) on channels such as O3DE Forums and O3DE Discord
+    * O3DE YouTube Channel videos
+* Documentation content:
+    * Core O3DE engine
+    * Core O3DE tools (asset building/processing, project config, etc.)
+    * O3DE Editor
+    * Screenshot maintenance (cross-cut)
+    * Official samples, tutorials, and demos
+    * 3rd party shepherding
+    * 3rdparty gem index guidelines
+    * 3rdparty samples/tutorials/demos index guidelines
+    * Generated references (API reference, manpages, etc.)
+* Community contributions
+* Guidelines for documentation submissions such as minimum viable content, screenshot requirements, etc.
+* Guidelines for minimum viable API reference.
+* Guidelines for manpages or other standalone tools documentation.
+* Guidelines for video content submissions
+* Maintenance of a style guide
+* Review of documentation pull requests.
+    * Maintain and manage the usual SIG group of contributors and approvers for PR review, in addition to a group of approved technical reviewers from other teams.
+    * Pull request review automation and approval workflows (cross-cut)
+    * Standards and guidelines for review process
+    * Editorial support
+* Maintain a public roadmap for SIG work.
+* Manages releases of documentation for bundled versions of O3DE.
+* Track and report on milestones.
+* Participate in binary releases by updating relevant materials on the site (i.e. download links, version number updates, etc.)
+* Processes and improvements
+* Work with other SIGs regarding contribution processes to help with messaging and standardized criteria.
+* Work with 3rd parties to ensure O3DE users can find their resources
+* Continually evaluate SIG processes against work and feedback to provide concrete improvements.
+* Provide templates and general guidance for Request For Feature (RFF) documents
+* Localization support
+
+## Cross-cutting Processes
+
+Aside from site maintenance and direct community interactions, the Documentation and Community SIG is primarily responsible for being involved in other SIGs when they need a voice representing community interests. The SIG also provides editorial review and support for other SIGs when requested.
+
+The SIG will also perform the occasional ad-hoc advisement or other work regarding community relations for the O3DE Foundation. The SIG may work with critical third parties on an as-needed basis provided availability.
+
+### Documentation and Community output to other SIGs
+
+* Minimum viable product standards for documentation, including API reference. Other SIGs are allowed to provide stricter standards, but should consult with Documentation and Community before doing so.
+* UX advisement for new features, including in-editor text
+
+### Documentation and Community input from other SIGs
+
+* Community materials such as dev diaries, blog posts, and other technical-focused materials better written by engineers.
+* Technical review on documentation pull requests
+* Standards for content: style guide, contributor guide, PR reviews. We are sometimes informally invited to consult on branding and design decisions, but we have no formal responsibility for such work.
+* Coordinating docs contributions for point releases
+* O3DE blog: The O3DE blog is a subproject of SIG Docs. SIG Docs provides tooling and workflow support for publishing the blog, but does not directly review blog posts or work with blog contributors. The blog subproject provides its own approvers and reviewers, and sets independent standards for creation and review of blog content.
+* Other project documentation: SIG Docs is sometimes advises on O3DE components outside of the Open 3D Foundation GitHub repository, or on other O3DE subprojects, but is not responsible for the documentation of any of these components or projects.
+
+## Out of Scope
+
+* Creating new feature documentation.
+* Docs will advise on feature documentation, but committers are expected to produce appropriate minimum viable documentation for their feature at the time of code submission.
+* End-user support.
+* Docs and Community are not technical support teams, but will contribute to Foundation-wide efforts and policies regarding support.
+* Branding, marketing, logos, or other website content which is not explicitly claimed by the SIG.
+* Localization. Docs and Community are not localization teams, but will provide infrastructure to support localization and may create subprojects to target specific high-priority languages for i18n.
+* RFF production, review, and technical requirements. The docs team helps create templates and guidance based on feedback from governance, and may provide writing or editorial assistance for high-priority internal RFFs.
+* Release notes and changelog. These are materials that should be produced for each release by the Release SIG, although docs will post/host on the O3DE website.
+
+## SIG Links and lists
+
+* Joining
+* Slack/Discord
+* YouTube Channel
+* Forums
+* Mailing list
+* Issues/PRs
+* Meeting agenda & Notes
+
+## Roles and Organization Management
+
+The Documentation and Community SIG adheres to the standards for roles and organization management as specified by . This SIG opts in to updates and modifications to .
+
+## Individual Contributors
+
+If you are targeting a particular release, make sure the pull request and issue is marked with the corresponding release milestone. This must be the same release identifier for both docs and code commits.
+
+## Maintainers
+
+Each release cycle, the current SIG Chair(s) must update membership. Maintainers of the  GitHub team are defined as follows:
+
+* SIG chair(s)
+* Documentation lead / sub-chair
+* Community lead / sub-chair
+
+To request membership to  or update the team:
+
+1. File a PR to o3de/org making changes to the o3de-docs-community-sig team config here. In your PR, include the reason you're requesting access in the description, as well as a comment next to your username in the team config e.g.,   * o3deusera # Gem / PM / Docs   * somefellowb # 1.14 Core / Testing
+2. Assign an approver from the group you'll be joining. If you are an incoming chair, request from the current lead(s).
+3. Once your request is approved by the appropriate group, you can now assign to the PR to a SIG Release Chair for final approval.
+
+## Additional responsibilities of Chairs
+
+Chairs also serve as Tech Leads. Chairs are responsible for coordinating efforts between the sub-SIGs as necessary.
+
+## Subproject Creation
+
+SIG Chairs can create subprojects without requiring member votes. Subprojects may be found in the subproject directory.
+
+## Deviations from sig-governance
+
+Per readme:
+
+* Meetings are biweekly
+* Once per month, weekly meeting time changes for easier attendance from APAC contributors
+* Once per quarter, leads and other interested parties meet to discuss quarterly goals and achievements

+ 1 - 0
meetings/media/readme.md

@@ -0,0 +1 @@
+# O3DE Meetings - Media

+ 1 - 0
meetings/notes/readme.md

@@ -0,0 +1 @@
+# O3DE Meetings - Notes

+ 35 - 0
meetings/readme.md

@@ -0,0 +1,35 @@
+# O3DE Docs 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/sig-docs-community/issues?q=is%3Aopen+label%3Amtg-agenda+).
+
+Please [reach out on Discord](https://discord.gg/p3padwr58u) 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-docs channel on [O3DE Discord](https://discord.gg/p3padwr58u) 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/sig-docs-community/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/sig-docs-community/issues?q=label%3Amtg-agenda+) under the O3DE [Foundation repository](https://github.com/o3de/sig-docs-community).
+
+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.**

+ 1 - 0
meetings/resources/readme.md

@@ -0,0 +1 @@
+# O3DE Meetings - Resources