Tier1 CONTRIBUTING.md

[Ulrond]

Tier 1 Operator Guide: Branching for Direct Contributions

Overview of Contributions

We welcome contributions from all community members, both Tier 1 (direct access) and Tier 2 (forked workflow) contributors. Your participation is vital to the project's success. Here's how you can get involved:

• Code Contributions: We invite you to contribute code, whether it's new features or bug fixes. Please follow the detailed steps below to ensure your contributions align with our project standards.
• Issue Reporting: If you discover bugs or have enhancement suggestions, please raise an issue in the repository. Your reports help us improve the project efficiently.
• Discussions and Ideas: We encourage you to initiate discussions on various topics related to the project. Your insights and feedback drive continuous improvement and innovation.

Access Levels and Workflows

• Tier 1 Operators (Direct Access): You have direct write access to the main repository. Follow the branching workflow detailed below.

• Tier 2 Operators (Forked Workflow): You don't have direct write access. Contribute by forking the repository, see the Tier 2 Guide for detailed instructions.

Contributor License Agreement (CLA)

Before your contributions can be accepted into the project, you must sign the RDK Contributor License Agreement (CLA). This legal document ensures that you have the rights to contribute the code and that the community can use your contributions freely. First-time contributors will need to complete the license agreement before their code can be merged:

Getting Started with Git Collaboration

1. Clone the Repository

To start, clone the repository to your local machine:

git clone https://github.com/rdkcentral/ut-core.git

2. Set Up Git Flow

We use the Git Flow branching model for managing branches. If you're new to Git Flow, please review this guide:

Example of initialising git flow:

git flow init -d

3. Create a Feature Branch

Create a new feature branch from the 'develop' branch for both new features and bug fixes, adhering to the naming convention: feature/gh_. The should briefly summarize the branch's purpose.

Example of creating a feature branch:

git flow feature start gh123_add-logging-enhancements

Compliance Notice: All contributors must strictly follow our Git branching guidelines. Every branch must be accurately named using the corresponding issue ID from our issue tracker, ensuring traceability and upholding automated workflow integrity. Incorrectly named or untraceable branches will fall under a retention policy, allowing for correction within 30 days before removal. This policy is crucial for maintaining the clarity and reliability of our project management processes.

4. Implement Changes

Make changes according to the project’s coding guidelines.

5. Commit Your Changes

Ensure your commits are clear and adhere to the 50/72 rule:

• Summary: Start with an imperative verb, include the GitHub issue ID, and succinctly describe the change.
• Body: Optionally, provide a detailed explanation, keeping lines to 72 characters.

Example of a Commit Message:

Fix #123: Update error handling in authentication module

This commit enhances error detection and adds comprehensive logging to address frequent issues reported by users.

6. Push Changes

Push your changes to the repository:

git push origin feature/gh123_add-logging-enhancements

7. Open a Pull Request

Create a pull request from your branch to the develop branch. It will be automatically assigned for review based on the CODEOWNERS file.

8. Merge the Pull Request

Once approved, merge your branch using Git Flow:

git flow feature finish gh123_add-logging-enhancements

9. Code Ownership and Releases

CODEOWNERS are responsible for reviewing and approving changes. They also manage the release and tagging of components according to the project’s schedule.

Example of the CODEOWNERS file:

# Default owners for everything in the repo
*       @rdkcentral/ut-core_codeowner

Requirements for Contributions

Please ensure your contributions meet the following:

• Adherence to Git Flow
• Clear and Concise Commit Messages
• Peer Review Approval
• Open Discussions and Contributions

By following these guidelines, you help maintain the quality and integrity of the project while fostering an inclusive and collaborative community environment. We look forward to your contributions and thank you for being part of our community-driven project.

[mhughesacn]

Hi Gerald: Do you want to mention the need to sign the CLA? Existing rdk-halif and gerrit components say "In order to contribute code, first-time users are requested to agree to the license" while other rdkcentral github components say "Before RDK accepts your code into the project you must sign the RDK Contributor License Agreement (CLA)."

[Ulrond]

updated @mhughesacn have a re-read

[mhughesacn]

Thanks Gerald. Just one thing - please change the CLA link ("this License agreement") from https://wiki.rdkcentral.com/signup.action to https://wiki-staging.rdkcentral.com/claagreement.action as the former is old and doesn't work.

[Ulrond]

done, is that ok now?

[mhughesacn]

Thanks Gerald: Just noticed two things: the second link "this license agreement" is unchanged and still broken, but probably doesn't need to be a hyperlink anyway, because you have already linked it two sentences back.
Second is our (i.e. my!) problem in that gerrit CONTRIBUTING.md file also use this broken link.

[Ulrond]

updated changes this license to the license, since we've already talked about it.

[Ulrond]

Final Doc Moved to here -> https://github.com/rdkcentral/ut-core/wiki/1.0.-Standards:-Tier-1-Operator-Guide:-Branching-for-Direct-Contributions