copyedit publishing

Author: ethanpalm

editor/publishing.mdx

@@ -1,31 +1,12 @@
 ---
 title: "Publishing your changes"
-description: "Deploy your documentation updates directly or through pull requests"
+description: "Deploy your documentation updates directly to production or through pull requests"
 ---
 
-The web editor offers two publishing paths depending on which branch you're working on: direct publishing to your live site or pull request workflows for review.
+How your changes are published depends on which branch you are working on:
 
-## Publishing workflows
-
-### Direct publishing (deployment branch)
-When working on your deployment branch (usually `main`):
-
-1. Make your changes in the editor
-2. Select **Publish** in the top-right corner  
-3. Your changes deploy immediately to your live documentation site
-
-**Use this for**: Quick fixes, typos, and urgent updates when you're confident in your changes.
-
-### Pull request workflow (feature branches)  
-When working on any other branch:
-
-1. Make and save your changes
-2. Select **Publish Pull Request**
-3. Add a title and description for review
-4. Create the pull request for team review
-5. Merge when approved to deploy to your live site
-
-**Use this for**: New features, major content updates, and collaborative work that benefits from review.
+* **Deployment branch**: Publishing updates your live site immediately.
+* **Other branches**: Publishing creates a pull request so you can review changes before they are deployed to production.
 
 <Frame>
   <img 
@@ -40,29 +21,33 @@ When working on any other branch:
   />
 </Frame>
 
-## Creating a pull request
+## Pull requests and reviewing changes
+
+Pull requests let you propose changes from your branch so that other people can review them before merging into your live documentation. This helps ensure that your changes are correct and gives your team a chance to collaborate on content.
+
+<Tip>
+  Even if you're working solo, pull requests are valuable for previewing changes and maintaining a clear history of updates.
+</Tip>
 
-When you're ready to publish changes from a feature branch:
+### Creating a pull request
 
 <Steps>
   <Step title="Save your work">
     Make sure all your changes are saved on your branch using **Save Changes**.
   </Step>
-  <Step title="Start the pull request">
+  <Step title="Create the pull request">
     Select **Publish Pull Request** in the top-right corner of the editor.
   </Step>
-  <Step title="Add context">
+  <Step title="Add a title and description">
     Write a clear title and description explaining:
     - What changes you made
-    - Why you made them  
+    - Why you made them
     - Any specific areas that need review
   </Step>
   <Step title="Create and share">
-    Select **Publish Pull Request**. The editor will provide a link to view your pull request in GitHub or GitLab.
-  </Step>
-</Steps>
+    Select **Publish Pull Request**. The editor will provide a link to view your pull request.
 
-<Frame>
+  <Frame>
   <img 
     src="/images/editor/pull-request-light.png" 
     alt="Publish pull request button emphasized in the Mintlify web editor" 
@@ -73,50 +58,16 @@ When you're ready to publish changes from a feature branch:
     alt="Publish pull request button emphasized in the Mintlify web editor" 
     className="hidden dark:block" 
   />
-</Frame>
-
-## Review and approval process
-
-### For reviewers
-Once a pull request is created:
-
-1. **Review changes**: Check the diff in GitHub or GitLab to see exactly what changed
-2. **Test locally**: Pull the branch locally if you want to test changes  
-3. **Leave feedback**: Add comments or request changes if needed
-4. **Approve**: Approve the pull request when you're satisfied with the changes
-
-### For authors  
-After creating your pull request:
-
-1. **Address feedback**: Make additional changes in the web editor if reviewers request them
-2. **Update automatically**: Saving changes in the editor automatically updates your pull request
-3. **Merge when ready**: Once approved, merge your pull request to deploy changes
-
-<Tip>
-  Even if you're working solo, pull requests are valuable for previewing changes and maintaining a clear history of updates.
-</Tip>
-
-## Best practices
-
-### Writing good pull request descriptions
-- Explain the **why** behind your changes, not just the what
-- Include screenshots for visual changes
-- List any breaking changes or considerations for reviewers
-- Reference related issues or tickets if applicable
-
-### Choosing the right workflow
-- **Direct publish** for: Typo fixes, minor updates, emergency changes
-- **Pull requests** for: New content, restructuring, collaborative work, experimental features
-
-### Managing multiple changes
-- Keep pull requests focused on a single feature or fix
-- Create separate branches for unrelated changes
-- Merge or close old pull requests before starting new major work
-
-## Troubleshooting publishing
+  </Frame>
+  </Step>
+</Steps>
 
-**Changes not appearing**: Check your deployment status in the Mintlify dashboard and try hard refreshing your browser.
+## Reviewing pull requests
 
-**Permission errors**: Verify you have the correct repository access and that your Git integration is properly configured.
+Once your pull request is created:
 
-**Merge conflicts**: If someone else changed the same content, you may need to resolve conflicts in your Git provider before merging.
+1. **Review changes**: You and your team members can review your pull request in your Git provider like GitHub or GitLab.
+2. **Leave feedback**: Add comments or request changes.
+3. **Make additional changes**: Make additional changes in the web editor. When you save changes, the editor pushes them to your pull request.
+4. **Approve**: Approve the pull request when you're satisfied with the changes.
+5. **Merge**: Merge the pull request when you're ready to deploy your changes to production.