Spaces:
Sleeping
Sleeping
| # Contributing Guide | |
| Second Me is an open and friendly community. We are dedicated to building a collaborative, inspiring, and exuberant open source community for our members. Everyone is more than welcome to join our community to get help and to contribute to Second Me. | |
| The Second Me community welcomes various forms of contributions, including code, non-code contributions, documentation, and more. | |
| ## How to Contribute | |
| | Contribution Type | Details | | |
| |------------------|---------| | |
| | Report a bug | You can file an issue to report a bug with Second Me | | |
| | Contribute code | You can contribute your code by fixing a bug or implementing a feature | | |
| | Code Review | If you are an active contributor or committer of Second Me, you can help us review pull requests | | |
| | Documentation | You can contribute documentation changes by fixing a documentation bug or proposing new content | | |
| ## Before Contributing | |
| * Sign [CLA of Mindverse](https://cla-assistant.io/mindverse/Second-Me) | |
| ## Here is a checklist to prepare and submit your PR (pull request). | |
| * Create your own GitHub branch by forking Second Me | |
| * Checkout [README](README.md) for how to deploy Second Me. | |
| * Push changes to your personal fork. | |
| * Create a PR with a detailed description, if commit messages do not express themselves. | |
| * Submit PR for review and address all feedbacks. | |
| * Wait for merging (done by committers). | |
| ## Branch Management Strategy | |
| We follow a structured branching strategy to manage releases and contributions from both internal and external contributors. | |
| ### Branch Structure | |
| ``` | |
| master (stable version) | |
| ^ | |
| | | |
| release/vX.Y.Z (release preparation branch) | |
| ^ | |
| | | |
| develop (development integration branch) | |
| ^ | |
| | | |
| feature/* (feature branches) / hotfix/* (hotfix branches) | |
| ``` | |
| ## Development Workflow | |
| ``` | |
| hotfix/fix-bug | |
| / \ | |
| master ---------+---------+-----+--- ... --> Stable Version | |
| \ / | |
| \ / | |
| release/v1.0 -----+-----------+--- ... --> Release Version | |
| \ / | |
| \ / | |
| develop --------------+-----+---+--- ... --> Development Integration | |
| / / | |
| / / | |
| feature/new-feature +----------- ... --> Feature Development (from master) | |
| ``` | |
| ### Step 1: Fork and Clone (External Contributors Only) | |
| If you're an external contributor, you need to fork the repository first: | |
| 1. Visit https://github.com/Mindverse/Second-Me | |
| 2. Click the "Fork" button in the top-right corner | |
| 3. Clone your fork to your local machine: | |
| ```bash | |
| cd working_dir | |
| # Replace USERNAME with your GitHub username | |
| git clone git@github.com:USERNAME/Second-Me.git | |
| cd Second-Me | |
| ``` | |
| 4. Configure upstream remote: | |
| ```bash | |
| # Add the upstream repository | |
| git remote add upstream git@github.com:Mindverse/Second-Me.git | |
| # Verify your remotes | |
| git remote -v | |
| ``` | |
| ### Step 2: Create a Feature Branch | |
| All contributors should create feature branches from the `master` branch: | |
| ```bash | |
| # First, ensure you have the latest changes | |
| git fetch origin # or upstream if you're working with a fork | |
| # Checkout the master branch | |
| git checkout master | |
| git pull | |
| # Create your feature branch from master | |
| git checkout -b feature/your-feature-name | |
| ``` | |
| ### Step 3: Develop Your Feature | |
| - Make changes in your feature branch | |
| - Commit regularly with descriptive messages | |
| - Follow the project's coding style | |
| - Add tests if applicable | |
| - Update documentation as needed | |
| ### Step 4: Commit Your Changes | |
| ```bash | |
| # Add your changes | |
| git add <filename> | |
| # Or git add -A for all changes | |
| # Commit with a clear message | |
| git commit -m "feat: add new feature X" | |
| ``` | |
| ### Step 5: Update Your Branch Before Submitting | |
| Before submitting your PR, update your feature branch with the latest changes: | |
| ```bash | |
| # Fetch latest changes | |
| git fetch origin # or upstream if you're working with a fork | |
| # Rebase your feature branch | |
| git checkout feature/your-feature-name | |
| git rebase origin/master # or upstream/master for forked repos | |
| ``` | |
| If you're an external contributor, you may need to push to your fork: | |
| ```bash | |
| git push origin feature/your-feature-name | |
| ``` | |
| ### Step 6: Create a Pull Request | |
| 1. Visit the repository (or your fork) | |
| 2. Click "Compare & Pull Request" | |
| 3. Select: | |
| - Base repository: `Mindverse/Second-Me` | |
| - Base branch: `develop` (all features and fixes go to develop first) | |
| - Head repository: Your repository | |
| - Compare branch: `feature/your-feature-name` | |
| 4. Fill in the PR template with: | |
| - Clear description of your changes | |
| - Any related issues | |
| - Testing steps if applicable | |
| - Target version if applicable | |
| ### Step 7: Address Review Feedback | |
| - Maintainers will review your PR | |
| - Address any feedback by making requested changes | |
| - Push new commits to your feature branch | |
| - Your PR will be updated automatically | |
| ### Step 8: PR Approval and Merge | |
| - All checks must pass before merging | |
| - Once approved, maintainers will merge your PR to the appropriate branch | |
| - Your contribution will be included in the next release cycle | |
| ## Release Management | |
| The following describes how releases are managed by project maintainers: | |
| ``` | |
| PR Merge Flow | |
| | | |
| master -------------------------+------ ... --> Stable Version | |
| | | |
| | | |
| release/vX.Y.Z ---------------+------- ... --> Release Version | |
| / | | |
| / | | |
| develop --------------------+--+------ ... --> Development Integration | |
| ^ | |
| | | |
| feature branches --------------+ | |
| ``` | |
| ### Creating a Release | |
| 1. When `develop` branch contains all features planned for a release, a `release/vX.Y.Z` branch is created | |
| 2. Only bug fixes and release preparation commits are added to the release branch | |
| 3. After thorough testing, the release branch is merged to `master` | |
| 4. The release is tagged in `master` with the version number | |
| ### PR Merge Strategy | |
| - All feature PRs are initially merged to the `develop` branch | |
| - Critical bug fixes may be merged directly to the current `release` branch | |
| - Maintainers are responsible for ensuring PRs are merged to the appropriate branch | |
| ### Hotfixes | |
| 1. For critical bugs in production, create a `hotfix/fix-description` branch from `master` | |
| 2. Fix the issue and create a PR targeting `master` | |
| 3. After approval, merge to both `master` and `develop` (and current `release` branch if exists) | |
| ## Tips for Successful Contributions | |
| - Create focused, single-purpose PRs | |
| - Follow the project's code style and conventions | |
| - Write clear commit messages | |
| - Keep your fork updated to avoid merge conflicts | |
| - Be responsive during the review process | |
| - Ask questions if anything is unclear | |