Bible for Reviewers

[kavuong]

Objectives
To document a comprehensive and clear guide for reviewers' responsibilities: quality assurance, code reviews, pull requests, etc.

Please start pull requests to the "Managers-Bible" branch. Also do start by making a variant and then making a pull request to the Managers-Bible branch.

• Receiving module assignments documentation

  • Based on "Pre-approval" and "Post-approval" Checklists
  • Sections (or info that should be covered)
    • Pre-approval: What To Do
    • Explanation of Role of Epics + Assigning Epic Points
      • Module epic points = activity epic points + lab epic points + workshop epic points
    • Explanation of Role of Issues (curriculum issues)
      • issues should be made constantly
    • Explanation of Role of Milestones
    • Adding Issues to Epics (Modules + Activities + Labs)
      • point of discussion: should there be epic points on curriculum issues?
    • Long-term Plan with examples
    • Zenhub Calendar

• Weekly Manager's Tasks documentation (directions on what manager should complete every week)

  • Based on "Weekly Manager Checklist"
  • Sections (or what info should be provided)
    • Fri/Sun/Tues Timeline + "first draft" explanation + "final draft" explanation
    • Explanation of issues to be set-up each week (long-term plan) and first-timer issues
      • emphasis that issues have to fully address the long-term plan
    • Setting up Milestones
    • Adjusting long-term plan and epic points for each activity + lab epic based on activity last week + feedback

• Role of GitHub Projects

• Weekly Code Review Documentation (directions on reviewing devs' pull requests)

  • How to start a code review
  • Should include "Pull Request Checklist" in review for each pull request
    • Explanation of each part - why is each part important?
  • Process of commenting based on devs' issues addressed and where code is added/subtracted

• Documentation on Specific QA procedures for managers and developers (

  • Goal: Complete projects as swiftly as possible while incorporating developers' and managers' input into and throughout the entirety of the project.
  • Preliminary idea
    • Managers and I (Kevin) must conduct code reviews on GitHub
      • Checking issues and contributions
        • In every pull request, there needs to be a list of checkboxes addressed
        • Managers: Need to make sure all assigned issues in milestone were completed and that checkbox contributions match the assigned issues
      • Every PR must have comments that address checkboxes
        • Every checkbox needs to be addressed with a comment
          • Comments can be positive or constructive

• Documentation on Specific QA for Kevin and Daniel

• Kevin will audit a random PR from dev to manager to ensure comments are being left.
• Overall similar to code reviews
  • Kevin: Need to make sure that all assigned issues and checkbox contributions are connected with the long-term plan
  • Daniel: checking after Kevin
  • Daniel's Code Review
  • Daniel will audit a random one of Kevin's code reviews, Kevin will audit a random one of each manager's code reviews

• Role of Writing Team (Victoria Xu right now)
  • Essentially when all curriculum is merged to master after Kevin and Daniel's QA there needs to be a procedure for proofreading

Collaborators
@ismaildude - Module Assignments Documentation (first task)
@ojgao - Weekly Manager Checklist and GitHub projects (second and third tasks)
@mxthu313 - Weekly Code Review Documentation (fourth task)
@JasonL24 - Documentation on Specific QA procedures for managers and developers (fifth task)
@jeffchhen - Documentation on Specific QA procedures for Kevin and Daniel (sixth task)

Deadlines
Monday, 3/30
Tuesday, 3/31 @mxthu313

[jeffchhen]

Documentation on Specific QA processes for Kevin and Daniel

---

Here at Bit, we place heavy emphasis that all content and material developed by Bit is up to our standards. In addition to material being reviewed by respective managers, the material will undergo further review by the head of Develop Relations, Kevin Vvuong, as well as the President of Bit Project, Daniel Kim. We have many developer teams at Bit and this process is necessary to ensure all material is synchronous and consistent.
Every each manager's deadline, Kevin will review all material pushed by managers. If the content passes Kevin standards, it will then be forwarded to Daniel for further review before it is pushed to master. If their is any inconsistencies with the material, Kevin raises an issue and the respective manager is assigned to resolve such issue.
Ultimately, the Quality Assurance Process has three checkpoints.

1. Pass by Manager
2. Pass by Kevin Vvoung
3. Pass by Daniel Kim
   Only then can the material be pushed to master .

[kavuong]

Compiled all of their initial work into #73