Contributions to the Sunbird building blocks can be in any form. For ex., one can contribute by:
Actively engaging with the community on the discussion forum
Identifying the needs i.e. bugs, documentation and installation issue, proposing new features and proposing enhancements to existing features
Developing new features, enhancements or fixing bugs
Identifying and filling documentation gaps
Enhancing installation related changes, release testing or any other area of interest
Any contribution proposal - it could be fixes for bugs, documentation issues, installation issues, new feature ideas or enhancements etc. should ideally should be brought in via a discussion forum post for alignment with the community.
An item is added to the issue tracker only after there is clarity around what needs to be done, and alignment with the community / working group in terms of the approach or the design, as the case may be.Note:
Any RFC or Enhancement issues created in the issue tracker should have a high level details of the what is expected in the feature
If an issue (Bug/documentation/installation) requires a change in another building block then the corresponding issue should be created in the other building block and linked (as - depends on) across the issue trackers
The Complexity and Priority should be discussed in the discussion forum and ideally should get updated when the issue is created
Once an item is picked up for contribution it is important for the contributor to update the status of the issue in the tracker, so that there is visibility for the community into progress being made. 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 timelinesFurther details on contribution issue statuses and workflows are available in the Sunbird Community Practices document.Some important points to keep in mind while making contributions:
The test cases and results are to be shared with the building block QA community. The test cases need to be shared before creating a review and merge request. The test result should be documented and shared before the issue can be submitted for validation.
The contributor QA team should also plan to contribute towards the release testing of the changes developed by them as per the release testing process
The contributor has to ensure that the code merge and the defect fixes happen as per the release timeline. Incase the issue is not completed as per the release timeline then the changes needs to be reverted back and a fresh PR request needs to be raised to revert the code changes
The issue will be tested by community QA Team for the release sign-off as well as its status updated as “Done” post successful completion of release testing.