Guidelines for raising a PR

[DevashishRaghav]

Title and Description

Clear and Concise Title: The PR title should be concise and describe the purpose or nature of the changes. It should be easy to understand at a glance.
Detailed Description: Provide a detailed description of the problem your PR is solving or the feature it's introducing. Include any relevant context that will help reviewers understand the changes.
Link Issues: If your PR addresses a specific issue, reference it by linking to the relevant GitHub issue.

Code Quality

Coding Standards: Follow the coding standards and style guidelines established for cQube. Consistency in coding style is crucial for maintainability.
Testing: Ensure that your code is adequately tested. Write unit tests for new code and ensure existing tests pass. Describe the testing approach in your PR description.

Documentation

Update Documentation: If your changes affect user documentation, update it accordingly. This includes README files, code comments, and any relevant documentation resources.
Changelog: If your PR introduces user-facing changes, consider adding an entry to the changelog to inform users about the new features or changes.

Commits

Granular Commits: Break your changes into small, focused commits that represent logical units of work. Each commit should have a clear purpose.
Commit Messages: Write clear and descriptive commit messages in the present tense. Summarize what the commit does and why.

Testing and Review

Self-Review: Before submitting the PR, review your own code changes to catch any obvious issues or oversights.
Peer Review: Encourage peer review by tagging relevant team members or maintainers. Reviewers can provide valuable feedback and ensure code quality.

Continuous Integration

Ensure CI Passes: Make sure that all continuous integration checks, including tests and code quality checks, pass successfully.

Feedback and Collaboration

Respond to Feedback: Be responsive to feedback from reviewers. Address and discuss any suggested changes or concerns promptly.
Collaborate: Collaborate with other contributors and maintainers to refine your code changes. Be open to suggestions and improvements.

Timeline

Timely Updates: Keep your PR up to date with the latest changes from the main branch. Resolve any merge conflicts promptly.

Closing and Merging

Maintainer Responsibility: The final decision to merge a PR rests with the project maintainers. Once all checks are passed, a maintainer will review and merge the PR.

These guidelines will help maintain a high standard of code quality and collaboration within the cQube community. Always aim to make your contributions as clear and valuable as possible, ensuring that they align with the project's goals and coding standards.

[rhwarrier]

CONTRIBUTING TO SARAL

Successful contributions to Sunbird can be in any form. For example, one can engage by:

Contributing by actively engaging with the community on the discussion forum
Contributing by identifying the needs i.e. bugs, documentation and installation issue, proposing new features and proposing enhancements to existing features
Contributing by developing new features, enhancements or fixing bugs
Contributing documentation changes
Contributing installation related changes
Contributing towards release testing

Everyone will have access to create a new discussion, add comments to existing discussions and tag groups or individuals to the discussion thread.

How to start ?

Every Building block publishes their list of issues with the latest status in the issue tracker and the link for the same is available on the microsite. The issues that are not yet taken up for development are part of backlog - the issues in the backlog are available to be taken up for development

Every issue will have a complexity field which will give a sense of ease or difficulty involved in developing the issues. The issues will also have a Priority field which will give a sense of urgency of developing the issue. Both these fields will help in identifying the appropriate issue to be picked up for development.

Once an issue is picked up for development, updating the status of the issue by the contributor in the issue tracker is very important as it keeps the community updated on the latest status of the issue. It also helps to plan the testing and other release related activities.

Once the development is completed by the contributor, the changes are finally validated and tested by the community QA team to sign-off the changes for inclusion in the latest version of the building block. Any issues found during this testing has to be fixed by the contributor and validated by the QA team within the published release timelines

Additional details on the Contribution Workflows can be found on the Sunbird Community Practices document.