|
|
@@ -0,0 +1,71 @@
|
|
|
+# RFC: Update merge permissions for `o3de.org` repo
|
|
|
+
|
|
|
+## :no_entry: If you submit a pull request to implement a process change without going through the RFC process, it may be closed with a polite request to submit an RFC first. :no_entry:
|
|
|
+
|
|
|
+### When using this template, you do not have to fill out every question below. The questions are there for guidance.
|
|
|
+
|
|
|
+This issue template should be used when filing an RFC related to _Documentation and Community processes and practice changes_ only. As a result, this RFC format should be used exclusively for discussions relating to SIG business which require extensive feedback from the community because it adds a new (or fundamentally changes an existing) process. Whether this process affects only the members of the SIG or all contributors, discussion is conducted in the open.
|
|
|
+
|
|
|
+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 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 developers beforehand. Talking to the core team members will help you prepare for a successful RFC.
|
|
|
+
|
|
|
+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
|
|
|
+
|
|
|
+This RFC proposes that we change the merge permissions for the `main` branch in `o3de/o3de.org` repo, requiring that 1 docs-reviewer and 1 technical reviewer approves the PR before it can be merged.
|
|
|
+
|
|
|
+### What is the motivation for this suggestion?
|
|
|
+
|
|
|
+Incoming PRs to the `o3de.org` repo should be reviewed by the appropriate people.
|
|
|
+
|
|
|
+* 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
|
|
|
+
|
|
|
+A few things need to be set up for this to take effect:
|
|
|
+1. We set up a CODEOWNERS file, as indicated by https://github.com/o3de/sig-docs-community/issues/61. The CODEOWNERS file that results from RFC#61 will affect this proposed RFC by setting up docs-reviewers and technical-reviewers group as owners of `/content/docs/*` directory.
|
|
|
+1. We change the merge permissions in `o3de.org` repo so that it requires requires approvals from the designated owners that's set in the CODEOWNERS file.
|
|
|
+
|
|
|
+
|
|
|
+### What are the advantages of the suggestion?
|
|
|
+
|
|
|
+* Explain the advantages of using this suggestion.
|
|
|
+
|
|
|
+### What are the disadvantages of the suggestion?
|
|
|
+
|
|
|
+- Explain any disadvantages of this change. Please take counterarguments in good faith and accurately represent any concerns that you or others have shared about the suggestion.
|
|
|
+
|
|
|
+### How will this be work within the O3DE project?
|
|
|
+
|
|
|
+- Explain how this suggestion will be work within the O3DE project.
|
|
|
+
|
|
|
+### Scope of work
|
|
|
+
|
|
|
+Include an estimation of the scope of work, so the SIG can determine if it can be reduced to a single issue (or small set of issues) an individual can perform, or if it needs to be a coordinated effort as an official SIG 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?
|
|
|
+
|
|
|
+- Point out any efforts needed if it requires coordination with multiple SIGs or other projects.
|
|
|
+- Explain how it would be adopted by new and existing contributors.
|
chanmosq