Introduction

Contributing to open-source projects can be a fulfilling way to give back to the community and enhance your coding skills.

So, we are going to discuss two open-source software projects with different licenses.

React by Facebook, MIT License.
STL( Standard Template Library ) by Microsoft, Apache License.

React

React Review Process Overview

The React community's review process is centred around GitHub, where all development work occurs. Whether you're a core team member or an external contributor, the process remains the same. Let's break down the key steps:

1. Branch Organization

React follows a simple branch organization strategy. All changes are submitted directly to the main branch. There are no separate branches for development or upcoming releases. This ensures that the main branch is always in good shape, with all tests passing. Any code landing in the main branch must be compatible with the latest stable release.

2. Feature Flags

To maintain the main branch's stability, breaking changes and experimental features must be behind feature flags. Feature flags are defined in specific files and are statically typed, making it easy to ensure they are correctly implemented. React's build system removes disabled feature branches before publishing.

3. Bugs

React uses GitHub Issues for public bug tracking. They encourage contributors to check existing issues before filing new ones. Providing a reduced test case is the best way to get a bug fixed. For security issues, there's a dedicated process separate from public bug tracking.

4. Proposing a Change

For substantial changes or public API modifications, it's recommended to file an issue first to discuss the proposal. For simple bug fixes, you can submit a pull request directly, but it's still advised to create an issue detailing the problem.

5. Sending a Pull Request

Before submitting a pull request, you need to follow several steps, including forking the repository, running tests, formatting code, and ensuring code linting.

let's observe the entire review process for a successful patch

Issue Opening:
- Issue #14362 was opened on Nov 30, 2018, by a user named TrySound.
- The issue was labelled as a bug report.
Issue Description:
- The issue described a problem with the React hooks linter failing with a specific code pattern.
- Two code examples were provided to illustrate the problem—one that failed and another that passed the linter.
Initial Comments:
- TrySound opened the issue and provided the initial description.
- Dan Abramov (gaearon), a React contributor, added the "Type: Bug" label and expressed interest in investigating the issue.
Discussion and Investigation:
- TrySound attempted to understand the codebase but found it non-trivial.
- User LosYear provided some insights into the issue, suggesting that the bug occurs when an additional operand is added to the for loop condition.
- LosYear also identified potential issues with caching and provided a detailed analysis of the problem.
- BruceWeng mentioned successfully reproducing the issue and planned to dig deeper into it.
Related Issues:
- A related issue (#14478) was mentioned by gaearon, which was labelled as a good first issue with challenging difficulty.
- Another user, Yurickh, mentioned a potential fix in issue #14661.
Pull Request:
- Yurickh opened a pull request (#14661) with a possible solution based on the analysis provided by LosYear.
- The pull request was mentioned in the issue discussion.
Issue Closure:
- gaearon closed the original issue #14362 as completed when the pull request #14661 was merged on Jan 25, 2019.

Microsoft's C++ Standard Library (STL)

Key Features and Components

Before we delve into the inner workings of Microsoft's STL, let's take a look at some key features and components that make it an essential part of the C++ development landscape:

Changelog and Status Chart: Microsoft maintains a comprehensive changelog that tracks updates to the STL, making it easy for developers to stay informed about the latest changes. Additionally, the status chart provides an overview of the library's progress over time.
Contribution Opportunities: STL welcomes contributions from the C++ community. Developers can report issues, comment on pull requests, and contribute code to improve the library's functionality. Guidelines for contributing can be found in the CONTRIBUTING.md file.
Build System and Integration: Microsoft is actively working on a CMake-based build system for the library. This build system is capable of building various flavors of the STL, ensuring compatibility with different MSVC toolset configurations.
Testing and Continuous Integration: The STL relies on three test suites—std, tr1, and libcxx—to validate its functionality under various configurations and compilers. Continuous integration with Azure Pipelines helps ensure the library's reliability and adherence to standards.
Conformance and Performance: Microsoft's primary goals for the STL are conformance, performance, usability, and compatibility. Conformance involves aligning with the latest C++ Working Draft, while performance optimizations are crucial to meet the high-performance demands of C++ developers.
Compatibility and Non-Goals: STL aims to maintain binary and source compatibility across different versions of Visual Studio. However, it's important to note that certain non-goals, such as porting to other platforms or adding non-standard extensions, are outside the scope of this project.

How to Contribute

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit Microsoft CLA.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

Types of Contributions

Submitting a Pull Request

The STL repo has many open issues that track work that needs to be completed. If you're unsure of where to start, you may want to:

Look for pinned issues, or
Check issues under the labels "good first issue," "high priority," or "help wanted."

Reviewing a Pull Request

We love code reviews from contributors! Reviews from other contributors can often accelerate the reviewing process by helping a PR reach a more finished state before maintainers review the changes. As a result, such a PR may require fewer maintainer review iterations before reaching a "Ready to Merge" state.

To gain insight into our Code Review process, you can check out:

Pull requests undergoing review

PR Checklist

Before submitting a pull request, please ensure:

Any non-standard identifiers in product code (including local variables, exposition-only members, etc.) begin with an underscore and a capital letter, as per [lex.name]/3.1.
Your changes don't affect the ABI for any type or function that a user may use (including adding or removing non-static data members, adding or removing virtual member functions, changing whether a type is an aggregate or trivially copyable, etc.).
Your changes are written from scratch using only acceptable sources:
- this repository,
- the C++ Working Draft (including any cited standards),
- other WG21 papers (excluding reference implementations outside of proposed standard wording),
- LWG issues, or
- a project listed in NOTICE.txt (make sure to cite the project in the PR description!).

If your changes are derived from any other project, you must mention it in the pull request description, so we can determine whether the license is compatible and whether any other steps need to be taken.

Running Tests and Benchmarks

To ensure the library's reliability and performance, Microsoft provides tools for running tests and benchmarks. This allows developers to validate their changes and optimizations.

Debugging with Visualizers

Developers can enhance their debugging experience by using custom visualizers provided by Microsoft's STL. These visualizers offer a clearer view of components when debugging C++ code in Visual Studio.

Let's observe the entire review process for a successful patch

The review process for the patch titled "Errors when linking x64 OBJ files into ARM64EC programs #3382" in the community involves several steps and participants. Here's an overview of the process:

Issue Creation:
- StephanTLavavej opened this issue on Feb 2.
- Highlighted the problem of errors when linking x64 OBJ files into ARM64EC programs.
- Provided details about the issue and mentioned its relation to other issues (#2635 and #2740).
Issue Discussion:
- Several community members joined the discussion.
- StephanTLavavej initiated the conversation and described the problem in detail.
Issue Labeling:
- StephanTLavavej added labels to the issue:
  - "bug"
  - "high priority"
  - "ARM64"
- Labels helped categorize and prioritize the issue.
Additional Comments:
- Over time, other members like driver1998 and CaseyCarter commented on the issue.
- Shared their experiences and related problems.
- CaseyCarter mentioned a similar issue in a different context.
Self-Assignment:
- CaseyCarter, a community member, self-assigned the issue on May 24.
- Indicated responsibility for working on the problem.
Pull Request Creation:
- CaseyCarter created a pull request titled "Support x64-only symbols on ARM64EC #3732" on May 25.
- The pull request aimed to address the issue discussed in #3382.
Issue Closure:
- StephanTLavavej closed the original issue #3382 as completed in pull request #3732 on May 30.
- Indicated that the problem had been resolved.
Labeling the Pull Request:
- StephanTLavavej added the "fixed" label to pull request #3732.
- Signified that it had successfully addressed the issue.

In this review process:

Participants:
- Multiple community members were involved, including StephanTLavavej, CaseyCarter, and driver1998.
- Each played a different role in discussing, self-assigning, or addressing the issue.
Duration:
- The issue was opened on Feb 2 and closed on May 30.
- The review process spanned several months, likely including discussions, development, and testing.
Responsiveness:
- The participants seemed responsive to updates in the process.
- Discussions occurred over several months, and the issue was ultimately resolved with a pull request.
Issues Discussed:
- The primary issue was related to errors when linking x64 OBJ files into ARM64EC programs.
- Participants also discussed related issues and potential solutions.
Issue Resolution:
- The issue was resolved through a pull request (#3732) created by CaseyCarter.
- It was subsequently closed by StephanTLavavej.

Personal Perspective

Contributing to open-source projects provides valuable insights. My exploration of React's review process revealed:

Efficiency: React's streamlined branch organization ensures code stability and accelerates updates.
Collaboration: Active engagement among contributors fosters a vibrant community.
Newcomer-Friendly: Labeling issues as "good first issue" welcomes new contributors.
Noteworthy Moments: Rapid responses, technical discussions, and smooth transitions from issues to pull requests are impressive.

Comparison with STL

Comparing React to Microsoft's C++ Standard Library (STL), we find:

Licensing: React's MIT License encourages adoption, while STL's Apache License focuses on contributions and legal clarity.
Approaches: React prioritizes simplicity and speed, while STL emphasizes compatibility, performance, and adherence to standards.
Duration: React's rapid cycle leads to quick resolutions, while STL's comprehensive testing and collaboration span several months.

Conclusion

Understanding open-source review processes is crucial. React's efficiency and inclusivity showcase transparency, and the diverse landscape of open source, represented by React and STL, invites developers to contribute. By giving back, we shape the future of software and our coding skills.

Let's embark on an open-source journey, where collective effort creates exceptional software for all.

Lab 1 - SPO600

Table of contents