docs: split CONTRIBUTING.md into contributor and maintainer guides

[vincent067]

docs: split CONTRIBUTING.md into contributor and maintainer guides

This PR addresses #4589 by splitting the CONTRIBUTING.md into two focused documents.

Summary

The current CONTRIBUTING.md contains both contributor-focused and maintainer-specific content. This PR separates these concerns to make the documentation more approachable for new contributors while giving maintainers a dedicated space for internal processes.

Changes

CONTRIBUTING.md (Refactored)

• Removed maintainer-specific sections (Backporting Fixes, Creating a New Release)
• Focused on contributor onboarding and development workflow
• Cleaned up table of contents to reflect only contributor content
• Retained all essential contributor guidance:
  • Reporting issues and security issues
  • Creating pull requests
  • Local development setup
  • Testing procedures
  • Code style guidelines

MAINTAINERS.md (New)

Created a comprehensive maintainer guide covering:

• Backporting fixes using Mergify bot
• Manual backporting procedures
• Complete release process with step-by-step instructions
• Post-release tasks

Benefits

1. Clearer separation of concerns: Contributors see only what they need to get started
2. Easier maintenance: Maintainers can update internal processes without affecting contributor docs
3. Better onboarding: New contributors aren't overwhelmed with maintainer-specific information
4. Improved discoverability: Each audience can find relevant information more quickly

Testing

• Verified markdown formatting renders correctly
• Checked all internal links are valid
• Reviewed content for clarity and completeness

Related Issues

Fixes #4589

---

Thanks for maintaining Atlantis! It's been a pleasure working with this project. The documentation was already quite good - hopefully this separation makes it even easier for future contributors to get started. 😊

I'm happy to make any adjustments based on your feedback!

[Copilot]

Pull request overview

Splits contributor vs. maintainer documentation by refocusing CONTRIBUTING.md on contributor onboarding/workflow and expanding MAINTAINERS.md into a maintainer process guide (backports + releases), addressing #4589.

Changes:

• Refactors CONTRIBUTING.md headings/TOC and removes maintainer-only sections.
• Replaces the previous MAINTAINERS.md maintainer roster with a maintainer guide covering backports and releases.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
MAINTAINERS.md	Reworked into a maintainer process guide for backports and releases.
CONTRIBUTING.md	Reorganized into a contributor-focused guide with updated heading structure and TOC.

Comments suppressed due to low confidence (2)

CONTRIBUTING.md:113

• The fenced code block after the list item "Start Atlantis in server mode..." isn’t indented as part of the list, so GitHub Markdown will break the list structure. Indent the code fence/content (and add a blank line if needed) so the command stays associated with the bullet (same issue repeats for the ngrok command block below).

- Create a personal access token for Atlantis. See [Create a GitHub token](https://github.com/runatlantis/atlantis/tree/main/runatlantis.io/docs/access-credentials.md#generating-an-access-token).
- Start Atlantis in server mode using that token:
```sh
atlantis server --gh-user <your username> --gh-token <your token> --repo-allowlist <your repo> --gh-webhook-secret <your webhook secret> --log-level debug

**CONTRIBUTING.md:141**
* Markdown list formatting: the lines starting with `because it is...` and `time of the error...` are not indented, so they render outside their preceding list items. Indent these continuation lines (or merge them into the bullet lines) to keep the "Errors" guidelines readable and properly grouped.

• ALWAYS use lowercase unless the word requires it
• ALWAYS use fmt.Errorf("additional context: %w", err)" instead of fmt.Errorf("additional context: %s", err)
  because it is less likely to result in mistakes and gives us the ability to trace calls
• NEVER use the words "error occurred when...", or "failed to..." or "unable to...", etc. Instead, describe what was occurring at
  time of the error, ex. "cloning repository", "creating AWS session". This will prevent errors from looking like

</details>

[Copilot]

The backporting instructions here reference using Mergify labels (e.g., backport-release-0.27), but this repo’s existing release docs describe using Google’s cherry-pick-bot via /cherry-pick … (see RELEASE.md). There’s also no other repo reference/config for Mergify. Please align this section with the actual backport mechanism (or update/remove RELEASE.md to avoid conflicting maintainer guidance).

Suggested change

	We use the [Mergify](https://mergify.com/) bot to automatically backport changes to previous release branches.
	To use Mergify for backporting, add a label to your PR in the format `backport-<branch>` where `<branch>` is the target release branch.
	For example, to backport to the `release-0.27` branch, add the label `backport-release-0.27`.
	### Manual Backporting Fixes
	If Mergify cannot automatically backport a change, you can do it manually:
	We use Google's cherry-pick-bot to backport changes to previous release branches.
	To request a backport, add a comment on the merged PR using `/cherry-pick <branch>` where `<branch>` is the target release branch.
	For example, to backport to the `release-0.27` branch, comment `/cherry-pick release-0.27`.
	### Manual Backporting Fixes
	If cherry-pick-bot cannot automatically backport a change, you can do it manually:

[Copilot]

This release flow diverges from the existing RELEASE.md process (e.g., RELEASE.md suggests using GitHub’s “Generate Release Notes”, while this doc says to copy from CHANGELOG.md). To prevent docs drift, consider making MAINTAINERS.md reference RELEASE.md (or move the canonical steps into one place) and ensure both documents describe the same procedure.

Suggested change

	1. **Determine the version number**
	We follow [Semantic Versioning](https://semver.org/):
	- **MAJOR**: Incompatible API changes
	- **MINOR**: Backward-compatible functionality additions
	- **PATCH**: Backward-compatible bug fixes
	2. **Update the CHANGELOG**
	Ensure the CHANGELOG.md is updated with all notable changes since the last release.
	3. **Create a new release branch (if it's a minor or major release)**
	For patch releases, use the existing release branch.
	```sh
	git checkout -b release-0.28
	git push origin release-0.28
	```
	4. **Create a new release on GitHub**
	- Go to https://github.com/runatlantis/atlantis/releases
	- Click "Draft a new release"
	- Choose "Choose a tag" and enter the new version (e.g., `v0.28.0`)
	- Click "Create new tag: v0.28.0 on publish"
	- Set the target to the appropriate branch (main for new releases, release branch for patches)
	- Fill in the release title: `v0.28.0`
	- Copy the relevant section from CHANGELOG.md into the release description
	- Click "Publish release"
	5. **Verify the Docker images are built**
	Docker images are automatically built and pushed via GitHub Actions. Verify they appear at:
	https://github.com/runatlantis/atlantis/pkgs/container/atlantis
	6. **Update the website documentation**
	If there are documentation changes, ensure they are deployed to the website.
	7. **Announce the release**
	- Post in the #atlantis Slack channel
	- Tweet from the official Twitter account (if applicable)
	Follow the canonical release instructions in [RELEASE.md](./RELEASE.md).
	`RELEASE.md` is the source of truth for the release procedure, including:
	- determining the next version number
	- preparing any required changelog or release notes updates
	- creating or selecting the correct release branch
	- drafting and publishing the GitHub release
	- verifying release artifacts such as Docker images
	- completing any release announcement or follow-up tasks
	To avoid documentation drift, do not duplicate or override the detailed release steps here; update `RELEASE.md` if the process changes.

[Copilot]

PR description says MAINTAINERS.md is a new file, but this change overwrites the existing MAINTAINERS.md content (maintainer roster table). Please update the PR description to reflect this, and consider whether the maintainer list should be preserved elsewhere (or linked, e.g., to the @runatlantis/maintainers team / CODEOWNERS) so readers can still find current maintainers.

[Copilot]

Markdown list formatting: the continuation line open your browser... isn’t indented under the bullet, so it will render as a separate paragraph instead of part of the list item. Indent the continuation line (or keep it on the same line) so the list renders correctly.

Suggested change

	open your browser to http://localhost:8080.
	open your browser to http://localhost:8080.