Proposal: Efficient Code Review Tracking

Proposals/code_review_tracking_proposal.md

@@ -0,0 +1,65 @@
+# Tracking Code Reviews
+
+## Introduction
+
+Code reviews are an integral part of our development process, ensuring code quality, collaboration, and knowledge sharing. To enhance this crucial process, various options for tracking code reviews are proposed. In this document, two primary options will be explored: creating a separate code review channel and integrating GitHub with Slack notifications.
+
+### Option 1: Separate Code Review Channel
+Establish a dedicated Slack channel to streamline code review communication and progress tracking.
+
+**_Benefits:_**
+1. **Focused Communication:**  Keep code review discussions organized and separate from other team conversations.
+2. **Clear Visibility:** Easily monitor the status of ongoing reviews and track the progress of each review thread.
+3. **Enhanced Collaboration:** Encourage team members to engage in discussions within the dedicated channel, fostering collaboration.
+
+**_Implementation Steps:_**
+1. **Create a New Channel:** Establish a new Slack channel dedicated to code reviews (e.g., "#cloud-content-code-reviews").
+2. **Invite Relevant Members:** Invite clound content team members involved in the code review process to join the channel.
+
+_**Using Emojis to Indicate Review Stages:**_
+**1. Start of Review:**
+When initiating a review, use a specific emoji 👀 in a threaded reply to the PR announcement in the channel. This signals that a team member has started reviewing the code.
+_Example:_
+Requesting Reviews: New feature implementation! - <link> 🚀
+Threaded Reply: 👀 Starting the review now!
+
+**2. End of Review:**
+Upon completing the review, reply with emoji ✅ to indicate that the review is finished. Include any comments or feedback directly in the thread for clarity.
+_Example:_
+Threaded Reply: ✅ Review completed. All looks good!
+
+**3. Request Changes:** 
+The 🛑 emoji communicates the need for changes in the code. Team members can use this emoji alongside specific feedback or comments to highlight areas requiring attention or modification.
+_Example:_
+Threaded Reply: �� Please address the formatting issue
+
+**_Drawbacks:_**
+Using a separate Slack channel for PR reviews comes with certain disadvantages, like the risk of channel overload, communication fragmentation, limited visibility for non-involved team members, potential notification fatigue, difficulty in context switching, challenges for new team members, and maintenance overhead.
+
+### Option 2: GitHub Integration with Slack Notifications
+Leverage GitHub and Slack integration to receive real-time notifications for code review events.
+
+**_Benefits:_**
+
+  1. **Automated Notifications:** Receive instant notifications in Slack for code review events, such as pull request creation, comments, and approvals.
+  2. **Seamless Integration:** Align code review updates directly with the version control system, ensuring real-time visibility.
+  3. **Customizable Notifications:** Tailor the integration to receive notifications for specific code review events based on team preferences, ensuring that relevant information is highlighted.
+
+**_Implementation Steps:_**
+1. **GitHub Slack Integration:** Configure GitHub to send notifications to the desired Slack channel.
+2. **Selective Notifications:** Customize the integration to receive notifications for specific code review events (e.g., new pull requests, comments, approvals).
+3. **Review and Collaboration:** Engage in code review discussions directly within the GitHub interface and Slack, creating a seamless workflow.
+
+**_Drawbacks:_**
+Potential drawbacks of this option include notification overload, contextual disruption, security concerns, integration maintenance, learning curve, and dependency on external services.
+
+_**The following are possibilities that require additional investigation.**_
+
+### Option 3: Automated Reminders
+1. Implement automated reminders for pending code reviews.
+2. Utilize GitHub Actions or third-party tools to send reminders for unaddressed comments or pending approvals.
+
+### Option 4: Pull Request Labels:
+1. Define a set of labels for pull requests to categorize them (e.g., "Ready for Review," "In Progress," "Blocked").
+2. Periodically inspect the cloud content repositories for pull requests labeled with code review-related tags using a script.
+

Proposals/scheduled_reminders_for_PR_review.md

@@ -0,0 +1,33 @@
+# Scheduled Reminders
+
+Scheduled reminders will aid the team in prioritizing review requests that demand attention. For pull requests, these reminders will dispatch a Slack message to the team channel, containing all open pull requests that the team need to review, at a designated time.
+
+For this process to function, the individual submitting the PR must either add additional team members individually or include the 'ansible-collections/cloud' team as reviewers.
+
+## Settings:
+
+**Slack Channel**: ansible-cloud-team
+
+**Reminder Scheduled Days**: Monday, Wednesday, Friday
+
+**Time**: 9:00 AM EST
+
+**Repositories**: `amazon.aws`, `amazon.cloud`, `cloud-content-handbook`, `cloud.common`, `community.aws`
+
+**Ignore Drafts**: yes
+
+**Require Review Requests**: yes
+
+**Remind Authors after Review**: yes, after one review
+
+**Ignore Approved Pull Requests**: yes, after two approvals
+
+**Miniumum Age**: 0 hours. All new PRs will be included in the reminder.
+
+**Minimum Staleness**: 0 hours. All old PRs, that are not waiting on reviews will be included in the reminder.
+
+**Ignored Terms**: `WIP`, `DNM`
+
+**Ignored Labels**: None
+
+**Required Labels**: None