Scribd
Upload
18 views5 pages

Open Source 2

Uploaded by

Shawayar Fatma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
18 views5 pages

Open Source 2

Uploaded by

Shawayar Fatma
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 5

OPEN SOURCE SOFTWARE

ASSIGNMENT-2

Submitted By-
Shawayar Fatma
2022MT93760
1
Code Review Policy For Collaborative White Board For
Developers

Implementing a code review policy speci ically for an open-source collaborative whiteboard
project brings unique challenges and bene its. Open-source projects often have contributors
from diverse backgrounds, varying skill levels, and time zones, which requires a structured
yet welcoming review policy. Here’s how to tailor an e ective code review process for such a
project.

1. De ine Clear Contribution Guidelines


Establish contribution guidelines to set expectations for contributors and reviewers,
detailing:
• Coding Standards: De ine style guides and naming conventions, which can
include things like indentation, comments, and ile structure. These should be
accessible in a CONTRIBUTING.md ile.
• Commit Message Guidelines: Encourage contributors to use concise, descriptive
commit messages with tags, such as [Fix], [Feature], or [Refactor], to
indicate the nature of changes.
• Branching Strategy: De ine a branching model (e.g., GitFlow) to keep the main
codebase stable and organized. A common setup includes main for releases,
develop for integration, and feature branches for new contributions.
•
2. Establish a Transparent Review Process
Clear review steps help contributors understand the expectations and reduce
misunderstandings. Consider:
• Code Review Stages:
◦ Initial Triage: On PR submission, have a team member or bot review if the PR
follows guidelines (e.g., formatting, tests) before assigning reviewers.
◦ Peer Review: Assign at least two reviewers for each PR. This not only ensures
multiple perspectives but also distributes the workload.
• Review Completion Criteria: De ine speci ic requirements for PR approval, such as at
least one non-blocking review and passing all automated checks. Clarify when a PR is
ready to merge versus when further review is necessary.
• Public Status and Progress: Use GitHub’s labels (e.g., needs review, in review,
approved) to indicate where each PR stands, so contributors know the status of their
submissions.

3. Automated Checks and Testing


Automated checks are crucial for maintaining consistency and quality in a project with
multiple contributors. Implement the following:

2
f
f
f
f
f
f
f
f
f
ff
• Continuous Integration/Continuous Deployment (CI/CD): Set up a CI/CD pipeline
(e.g., with GitHub Actionsor GitLab CI/CD) to automatically run tests, linters, and
build checks on every pull request.
• Code Formatting: Use Prettier or ESLint to automatically format and lint code,
ensuring consistency without manual intervention.
• Automated Security Scans: Open-source projects can bene it from tools like Snyk or
CodeQL to identify security vulnerabilities. This is essential for a collaborative
whiteboard, where user data and real-time interactions must be secure.

4. Code Review and Feedback Guidelines


Establishing constructive feedback guidelines is crucial for open-source communities,
especially to keep the environment welcoming:
• Encourage Speci ic Feedback: Reviewers should highlight speci ic lines or code
blocks rather than general comments like “improve readability.” Encourage the use of
positive language, even when pointing out areas for improvement.
• Use Blocking vs. Non-Blocking Comments: Indicate which issues are blocking (must
be resolved before merging) versus non-blocking (optional improvements). This helps
contributors prioritize ixes.
• Feedback Loop: If the contributor addresses review comments, they should @mention
the reviewer to notify them of updates. This keeps the review process moving forward
and avoids stale PRs.

5. De ine a Path for New Contributors


Open-source projects bene it from new contributors but often need additional guidance for
them. To encourage contributions, consider:
• Good First Issues: Label simpler issues with good first issue for beginners and
provide additional context or mentoring for these issues.
• Documentation for Setup and Development: Provide a README.md with instructions
on how to set up a local environment, install dependencies, and run tests.
• Contributor Mentorship: Pair new contributors with experienced reviewers, which
helps them learn the codebase while allowing experienced contributors to mentor
others.

6. Encouraging Collaboration and Discussion


For a collaborative whiteboard, features often need discussion and iteration to ensure they
meet user needs. Encouraging collaborative dialogue around reviews is key:
• Discussion Forums: Use GitHub Discussions, a dedicated Slack/Discord channel, or
similar for contributors to discuss their approach to issues before submitting a PR. This
can prevent rework if the feature or approach needs modi ication.
• Design and Architecture Proposals: For signi icant features or refactoring, encourage
contributors to open a design proposal (like an ADR, Architecture Decision Record)
before coding. This helps align on big decisions early and minimizes rework during
reviews.

3
f
f
f
f
f
f
f
f
7. Setting Code Review Turnaround Times
Setting expectations around response times is crucial to keep the open-source project
moving forward while respecting contributor availability:
• Initial Review Response: Aim for an initial review within 1-3 days. This responsiveness
can encourage continued engagement and reduce contributor churn.
• Clarify High-Priority Issues: For urgent bug ixes or critical feature updates, establish a
policy for faster review turnaround, ideally within 24 hours. Mark these issues or PRs
with a high-priority label.

8. Documentation of the Code Review Process


Good documentation is essential in an open-source environment, where contributors may
come and go over time. Here’s how to document the process:
• Detailed Contribution Guide: Include a CONTRIBUTING.md ile in the repository,
covering:
◦ Steps for setting up the development environment.
◦ Guidelines for opening issues, submitting PRs, and the review process.
• Code Review Checklist: Provide a checklist of items reviewers should consider, such
as:
◦ Functionality and adherence to requirements.
◦ Security and error handling.
◦ Code readability and maintainability.
◦ Proper test coverage and passing tests.
• Feedback Etiquette Guide: Outline best practices for feedback, including respect,
constructive comments, and acknowledging contributions. This can be part of a
CODE_OF_CONDUCT.md.

9. Continuous Improvement Through Retrospectives


Since open-source projects evolve with the community, regularly improve the review process
by gathering input from contributors:
• Periodic Review of the Process: Conduct retrospectives (monthly or quarterly) to
evaluate what’s working and what’s not. Use surveys or GitHub Discussions to gather
feedback.
• Automated Data Collection: Tools like GitHub Insights can track metrics (e.g., PR cycle
time, review turnaround time) to understand the e iciency of the review process.
• Community Feedback: Regularly solicit community input on improving the review
process, which can bring new insights and keep contributors engaged.

Example Code Review Work low for a Collaborative Whiteboard


PR Creation and Initial Checks:

Contributor submits a pull request (PR) with a clear title, description, and relevant issue links.
Automated checks (e.g., CI/CD pipelines, code quality scans, linting) run, ensuring the PR
meets baseline standards.

4
f
f
ff
f
Assignment of Reviewers:

CODEOWNERS or maintainers assign relevant reviewers based on the code area affected.
Reviewer completes an initial review within the target turnaround time (e.g., 1-3 days).
Code Review:

Reviewer examines code quality, security, functionality, and adherence to guidelines. They
leave constructive feedback, marking blocking versus non-blocking comments.
Contributor addresses the feedback, @mentions the reviewer to notify them of updates.
Approval and Merge:

Once the PR meets the quality standards and required approvals, a maintainer or lead
approves the PR.
The PR is merged into the main branch if all tests and checks pass.
Periodic Retrospective:

Review the code review process periodically with contributors to gather feedback and
improve the process.

In Summary

By implementing these tailored steps, an open-source collaborative whiteboard project can


maintain high standards while fostering an inclusive, productive environment for
contributors. The process keeps code quality high while ensuring contributors feel
welcomed, valued, and supported.

You might also like