From 14f28b1a53a07268de9d752d2574406ba5bf0499 Mon Sep 17 00:00:00 2001 From: anyreso Date: Sat, 13 Apr 2024 16:11:01 -0400 Subject: [PATCH] =?UTF-8?q?=F0=9F=93=9D=20update=20CONTRIBUTING?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- CONTRIBUTING.md | 44 ++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 40 insertions(+), 4 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f0f08d8..f51d82f 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -8,19 +8,51 @@ Whether you're an experienced developer or just starting out, we welcome your co ## Reporting Issues -If you encounter any bugs or issues, please report them in the [Issue Tracker](https://gitlab.com/godotribes/godotribes/-/issues). Include as much detail as possible, such as steps to reproduce the issue and expected vs. actual behavior. +If you encounter any bugs or issues, please report them in the [Issue Tracker][#issue_tracker]. + +Include as much detail as possible, such as steps to reproduce the issue, expected vs. actual behavior, screenshots or logs. ## Merge Requests and Releases We highly recommend using [gitmoji](https://gitmoji.dev) for expressive and visually appealing commit messages, as it provides an easy way of identifying the purpose or intention of a commit simply by looking at the emojis used. -Every **merge request** (MR) must be merged into the `develop` branch before any release is made on the `main` branch. +Every [merge request (MR)][#create_merge_requests] must be merged into the `develop` branch before any release is made on the `main` branch. The `develop` branch serves as the staging area for upcoming features and fixes. When the `develop` branch is deemed stable and ready for release, it is merged into the `main` branch to create a new release. -This practice ensures that everyone remains updated on ongoing tasks, fostering transparency and encouraging collaboration within the team. +This practice ensures that everyone remains updated on ongoing tasks, fostering transparency and encouraging collaboration. + +## Fork-based workflow + +If you want to contribute changes without write access to the repository, you can still do so by forking. This is a simple way for anyone to contribute by creating your own copy of the project where you can make changes freely. + +1. First, you'll need to fork the repository. +2. Once you have a fork, clone it to your local machine. +3. Then, you can make changes just like you would if you were a member of the project. +4. After you've made your changes, you commit them locally and push these back to your fork on gitlab. +5. Finally, you can [create a merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#when-you-work-in-a-fork) from your fork's branch to upstream's branch. + +> We encourage you to [allow commits from upstream members](https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaboration.html#allow-commits-from-upstream-members) so that they can [push to the fork as the upstream member](https://docs.gitlab.com/ee/user/project/merge_requests/allow_collaboration.html#push-to-the-fork-as-the-upstream-member) in order for you to reach out for help. + +The merge request notifies project maintainers that you've made changes and allows them to review your code and potentially merge it into the main project. + +When your branch is merged, you may want to [update your fork](https://docs.gitlab.com/ee/user/project/repository/forking_workflow.html#update-your-fork) to be synced with upstream. + +## Repository membership + +Access to our [gitlab repository][#repo_url] is essential for collaborative development and ensuring the integrity of our project. If you're interested in contributing to our codebase or becoming a member, please follow these guidelines: + +1. **Contribution**: Get involved in the project by contributing code, reporting issues, or participating in discussions on our [discord](https://discord.gg/tdmV3MxCn5) or [gitlab repository][#repo_url]. +2. **Familiarization**: Read about development guidelines, coding style, conventions. Understanding these aspects will help you make meaningful contributions to our codebase. +3. **Request**: Upon a single merge request merged in `develop`, anyone can request to become a member, reach out to other members for access. +4. **Review**: We will assess factors such as the quality of your contributions, adherence to our guidelines and alignment with our project's vision. +5. **Access**: Upon approval, a membership will be granted to our [gitlab repository][#repo_url], allowing you to directly contribute, review changes and collaborate with others. + +While we welcome contributions from everyone, access to our repository is granted at our discretion. + +We greatly value enthusiasm within our community and we can't wait to see what you'll bring to the table! # Development Guidelines @@ -66,7 +98,7 @@ git commit -am "📝 update CONTRIBUTIONS.md" git push ``` -4. Create a [Merge Request (MR)](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html) with a clear description of your changes +4. Create a [merge request (MR)][#create_merge_requests] with a clear description of your changes ## Excluding local files without creating a _.gitignore_ file @@ -79,3 +111,7 @@ Use your favorite text editor to open the file called `.git/info/exclude` within By following these guidelines, we aim to streamline our development process, maintain code quality, and ensure that our releases are stable and reliable. Happy coding! 🎮✨ + +[#create_merge_requests]: https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html +[#issue_tracker]: https://gitlab.com/open-fpsz/open-fpsz/-/issues +[#repo_url]:https://gitlab.com/open-fpsz/open-fpsz \ No newline at end of file