add dev workflow + code review process

contribute-to-rocket.chat/code-review-process.md → contribute-to-rocket.chat/contribution.md

@@ -1,13 +1,13 @@
-# Code Review Process
-
-Contributing to an open-source project like Rocket.Chat can be an exciting and fulfilling experience. However, it's crucial to understand the process that your contribution will undergo before it can be integrated into the main codebase. This guide aims to help you comprehend the stages involved in the Rocket.Chat code review process.
-
-* **Stage 1: Forking and Cloning**: The first step in contributing to Rocket.Chat is to fork the project on GitHub and clone it to your local development environment. This allows you to work on your changes in a controlled environment without impacting the main project.
-* **Stage 2: Create a Branch**: It's best to create a new branch for each new feature or bug fix. This helps to isolate your changes and makes it easier to track the work that has been done.
-* **Stage 3: Implementing Changes**: This is the stage where you write your code. Make sure you follow Rocket.Chat's coding standards and guidelines ensure consistency and maintainability. Your code should be clean, well-commented, and tested thoroughly.
-* **Stage 4: Committing Changes**: Once you've made your changes, you need to commit them. Each commit should be a single logical change, and the commit message should describe what the change does, why it's needed, and any potential implications it may have.
-* **Stage 5: Submitting a Pull Request**: After you've committed your changes, it's time to submit a pull request (PR). The PR should be detailed and include a description of the changes, the reasons behind them, and any issues that they address. It should also include any necessary documentation changes.
-* **Stage 6: Code Review**: Now, the Rocket.Chat team will review your PR. This involves checking the code for any potential issues, ensuring it aligns with the project's coding standards and that it accomplishes what it is intended to do. This stage might involve some back-and-forth discussions, so be prepared to answer questions and possibly make revisions based on the feedback you receive.
-* **Stage 7: Acceptance or Rejection**: Once the review process is complete, the team will decide whether to merge your PR into the main codebase or not. If your PR is accepted, it will be merged. If it's rejected, you'll be given feedback on why this decision was made. It's important to remember that the decision to merge a PR is at the sole discretion of the Rocket.Chat team. As an open-source project, we value and respect each member of our community. However, contributing code doesn't guarantee that it will be merged. Factors that influence this decision include but are not limited to, the code's quality, alignment with the project's goals, impact on the codebase's stability, and the resources required to support it. We understand that putting time and effort into a contribution only for it to be rejected can be disheartening. However, the aim is always to ensure that the Rocket.Chat codebase remains high-quality, maintainable, and focused on meeting the needs of the project and its users.
-
-We hope this guide gives you a clear picture of our code review process. We look forward to your contributions and to you being part of the Rocket.Chat community. Now that you understand the process, let's proceed to explore the many different [modes-of-contribution](modes-of-contribution/ "mention") to Rocket.Chat.
+# Contribution Process
+
+Contributing to an open-source project like Rocket.Chat can be an exciting and fulfilling experience. However, it's crucial to understand the process that your contribution will undergo before it can be integrated into the main codebase. This guide aims to help you comprehend the stages involved in the Rocket.Chat code review process.
+
+* **Stage 1: Forking and Cloning**: The first step in contributing to Rocket.Chat is to fork the project on GitHub and clone it to your local development environment. This allows you to work on your changes in a controlled environment without impacting the main project.
+* **Stage 2: Create a Branch**: It's best to create a new branch for each new feature or bug fix. This helps to isolate your changes and makes it easier to track the work that has been done.
+* **Stage 3: Implementing Changes**: This is the stage where you write your code. Make sure you follow Rocket.Chat's coding standards and guidelines ensure consistency and maintainability. Your code should be clean, well-commented, and tested thoroughly.
+* **Stage 4: Committing Changes**: Once you've made your changes, you need to commit them. Each commit should be a single logical change, and the commit message should describe what the change does, why it's needed, and any potential implications it may have.
+* **Stage 5: Submitting a Pull Request**: After you've committed your changes, it's time to submit a pull request (PR). The PR should be detailed and include a description of the changes, the reasons behind them, a changeset if the PR is a **fix** or **feat**, and any issues that they address. It should also include any necessary documentation changes.
+* **Stage 6: Code Review**: Now, the Rocket.Chat team will [review](./rocket.chat-core-developers/code-review.md) your PR. This involves checking the code for any potential issues, ensuring it aligns with the project's coding standards and that it accomplishes what it is intended to do. This stage might involve some back-and-forth discussions, so be prepared to answer questions and possibly make revisions based on the feedback you receive.
+* **Stage 7: Acceptance or Rejection**: Once the review process is complete, the team will decide whether to merge your PR into the main codebase or not. If your PR is accepted, it will be merged. If it's rejected, you'll be given feedback on why this decision was made. It's important to remember that the decision to merge a PR is at the sole discretion of the Rocket.Chat team. As an open-source project, we value and respect each member of our community. However, contributing code doesn't guarantee that it will be merged. Factors that influence this decision include but are not limited to, the code's quality, alignment with the project's goals, impact on the codebase's stability, and the resources required to support it. We understand that putting time and effort into a contribution only for it to be rejected can be disheartening. However, the aim is always to ensure that the Rocket.Chat codebase remains high-quality, maintainable, and focused on meeting the needs of the project and its users.
+
+We hope this guide gives you a clear picture of our code review process. We look forward to your contributions and to you being part of the Rocket.Chat community. Now that you understand the process, let's proceed to explore the many different [modes-of-contribution](modes-of-contribution/ "mention") to Rocket.Chat.

contribute-to-rocket.chat/rocket.chat-core-developers/code-review.md

@@ -0,0 +1,11 @@
+# Code Review
+
+This process ensures your code adheres to established coding standards, functions as intended, and catches any potential problems you might have overlooked. The collaborative review fosters knowledge sharing within the team, leading to not only high-quality code but also improved development practices and a stronger overall codebase.
+
+* **Step 1: Title and description**: Look for a clear and concise title and description in the PR. The title should accurately reflect the changes and follow the conventional commits standard, and the description should explain the purpose and functionality of the code.
+* **Step 2: Verify Changeset (Fix/Feature PRs)**: For pull requests categorized as fixes or features, confirm that a changeset has been added. This changeset helps track versioning and simplifies release management.
+* **Step 3: Verify Labels and Milestones**: Look for appropriate labels and milestones assigned to the PR. Labels help categorize the changes, while milestones track progress towards specific release versions. Confirm these are correctly assigned to ensure clear organization and efficient project management.
+* **Step 4: Review Automated Checks**: Verify that all automated checks (linting, type checking, tests, etc.) have passed successfully. These checks help identify potential errors and ensure code quality is maintained.
+* **Step 5: Code Review for Quality**:  Meticulously examine the code for adherence to project standards, architecture principles, security best practices, readability, and maintainability. Furthermore, ensure the PR focuses on a single solution. If the changes involve multiple solutions, suggest splitting them into separate PRs for a clearer and more manageable review process.
+* **Step 6: Review Test Coverage**: Ensure the PR includes relevant tests that thoroughly cover the proposed solution. For exceptional cases (layout changes, external integrations, etc) where testing might be impractical, a comment explaining the rationale is recommended after seeking approval from the manager or tech lead. This fosters a balance between comprehensive testing and acknowledging limitations.
+* **Step 7: Review, Test, and Merge**: : After a thorough team review, your PR enters QA for rigorous testing. Upon successful QA, a label must be added indicating completion. Once all changes have been addressed and necessary approvals are granted, the PR is automatically merged into the codebase by the designated bot.

contribute-to-rocket.chat/rocket.chat-core-developers/development-workflow.md

@@ -0,0 +1,14 @@
+# Development Workflow
+
+To ensure a collaborative and efficient environment, there are key practices Rocket.Chat core developers should follow when contributing to the project. These practices not only benefit the team as a whole but also streamline the development process.
+
+* **Step 1: Squad Task Selection**: The first step is to grab tasks from the squad board. These tasks might be pre-assigned by managers, product managers, or tech leads, or they can be self-selected.
+* **Step 2: Clarify Task Requirements**: Before diving in, ensure you fully grasp the task's details. If anything seems unclear, don't hesitate to communicate with your manager or tech lead. They'll be happy to clarify or involve relevant parties in the discussion.
+* **Step 3: Maintain a Detailed Task Log**: Use comments within the task to document decisions, steps taken, and any other relevant information. This meticulous record-keeping creates a clear history for future reference and assists other developers working on the same project.
+* **Step 4: Update Task Status**: As you progress on the task, remember to update its status on the board. This could be "In Progress", "Waiting Review", "QA", or any other relevant stage. This keeps everyone informed about the task's workflow.
+* **Step 5: Committing Changes**: Strive to write commit messages that clearly describe the change you made. Following a semantic commit style (like "fix: resolved image upload issue") improves code readability and future maintenance.
+* **Step 6: Submitting a Pull Request**: After committing your changes, create a well-defined pull request (PR). The title should adhere to conventional commits standards (e.g., "fix: resolved image upload issue"). Provide a detailed description of the changes, their rationale, and any addressed issues. Include a changeset for fixes or features, and update relevant documentation. Keep your PR focused on the original task. Avoid adding unrelated changes, even minor refactoring. If refactoring is necessary, create a separate PR.
+* **Step 7: Comprehensive Test Coverage**: Whenever possible, include relevant tests (API, UI, or unit) within your PR to validate your code changes. This strengthens code quality and ensures functionalities work as intended. For fixes in particular, tests are crucial to prevent regressions and ensure the issue is truly resolved. Exceptions exist for purely visual changes or those dependent on external tools lacking reliable automated testing methods.
+* **Step 8: Code Review**: The development team will meticulously examine your code. This review ensures it meets coding standards, functions as intended, and addresses any potential problems. We highly encourage active participation from everyone on the team in [code reviews](./code-review.md). Be prepared for discussions and revisions based on their feedback, fostering a collaborative environment.
+* **Step 9: Review, Test, and Merge**: : After a thorough team review, your PR enters QA for rigorous testing. Upon successful QA, it lands in the merge queue for final integration.
+