Fix lint and format errors

issue-ops · Nov 1, 2023 · e92184d · e92184d
1 parent 53e8747
commit e92184d
Show file tree

Hide file tree

Showing 3 changed files with 10 additions and 12 deletions.
diff --git a/docs/content/setup/index.mdx b/docs/content/setup/index.mdx
@@ -12,5 +12,5 @@ IssueOps workflow. This includes setup and configuration of the following:
 - [Repository](/setup/repository)
 - [GitHub App](/setup/github-app)
 - [Issue form](/setup/issue-form)
-- [Issue create workflow](/setup/issue-create-workflow)
-- [Issue comment workflow](/setup/issue-comment-workflow)
+- [Issue workflow](/setup/issue-workflow)
+- [Comment workflow](/setup/comment-workflow)
diff --git a/docs/content/setup/issue-form.mdx b/docs/content/setup/issue-form.mdx
@@ -28,7 +28,7 @@ once they submit their issue.
 ```yaml
 name: Create a new repository
 description: |
-  Once created, this issue will cause a new GitHub repository to be created in
+  Once opened, this issue will cause a new GitHub repository to be created in
   the `octocat` organization. You will be granted access as a collaborator so
   you can build something awesome!
 labels:

diff --git a/docs/content/setup/repository.mdx b/docs/content/setup/repository.mdx
@@ -33,8 +33,8 @@ can set the visibility to `private` and add those users as
 
 ## Permissions
 
-Users only need `read` access to create issues! Unless there is a specific
-reason to do otherwise, you should only ever need to grant `read` access.
+Users only need `read` access to open issues! Unless there is a specific reason
+to do otherwise, you should only ever need to grant `read` access.
 
 The primary reason to grant `write` access is if your IssueOps flow uses pull
 requests instead of issues, but only if you want users to create pull requests
@@ -79,28 +79,26 @@ workflows at all. However, this may not be practical for your workflow. Here are
 some recommended settings:
 
 <DoDontContainer>
-  <Dont indented>Send write tokens to fork pull requests</Dont>
   <Do indented>
     Document required permissions for contributors to run the workflows
     themselves
   </Do>
+  <Dont indented>Send write tokens to fork pull requests</Dont>
 </DoDontContainer>
 
 <DoDontContainer>
-  <Dont indented>
-    Send secrets and variables to workflows from fork pull requests
-  </Dont>
   <Do indented>
     Document the required secrets and variables and how to generate them
   </Do>
+  <Dont indented>
+    Send secrets and variables to workflows from fork pull requests
+  </Dont>
 </DoDontContainer>
 
 One alternative to consider is to "wrap" the creation of the PR into part of
 your IssueOps flow. If the content of the PR will follow a known format, you can
 use a GitHub Action to create the PR on behalf of the user. This will allow you
-to remove the need to allow any GitHub Actions access to fork pull requests. For
-an example of this scenario, see the
-[IssueOps Actions](/reference/issueops-actions) page.
+to remove the need to allow any GitHub Actions access to fork pull requests.
 
 {/* TODO: Direct link to specific example */}