Rules & Guidelines

Document Information

1. Event Overview

1.1 Purpose of the Sprint

BMS Open Source Sprint 2026 is designed as a guided real-world open-source contribution sprint. Instead of limiting contributors to projects submitted by BMS students, the event will curate a fixed pool of active open-source repositories that are participating in programs such as GSSoC/SSoC or are actively accepting beginner and intermediate contributions.

The objective is not simply to produce code or collect GitHub activity. The primary objective is to help each participant experience as much of the authentic open-source workflow as possible: identifying a suitable issue, communicating professionally with maintainers, obtaining assignment or approval where required, implementing a solution, testing it, opening a pull request, responding to review comments, and ultimately getting the work accepted or merged.

1.2 Real Open-Source Workflow

1. Find a suitable issue in an approved repository.
2. Read the repository documentation and contribution guidelines.
3. Check whether the issue is already assigned or has an active PR.
4. Submit the issue through the BMS internal Issue Claim Form.
5. Wait for internal technical verification and difficulty assignment.
6. Follow the upstream repository's rules for assignment, proposals or PR submission.
7. Implement the solution and test it properly.
8. Open the pull request according to the upstream project's guidelines.
9. Submit the PR link through the BMS PR Submission Form.
10. Respond to maintainer feedback and track the contribution through the milestones.

2. Approved Repository Pool

Participants may initially contribute only to repositories approved by the organising and technical teams. The pool may be updated during the event if a maintainer becomes inactive, a repository stops accepting contributions, or a better contribution opportunity becomes available.

2.1 Beginner-Friendly Repositories

2.2 Intermediate Repositories

2.3 Advanced Repositories

3. Mandatory Internal Approval System

Participants must not randomly begin coding on issues. Every scoring contribution must first pass through the BMS internal approval process. This provides coordination, prevents duplicate work, protects external maintainers from unnecessary activity, and allows the technical team to assign a consistent internal difficulty level.

3.1 Issue Claim and Approval Process

1. Choose a repository from the approved repository pool.
2. Find an existing open issue suitable for your skill level.
3. Check whether another contributor is already assigned or has opened a PR.
4. Read the repository's README, CONTRIBUTING guidelines, issue instructions and relevant documentation.
5. Submit the issue to the BMS internal Issue Claim Form.
6. The technical team verifies the issue and approves the claim.
7. After approval, contact the upstream maintainer or request assignment according to that repository's rules.
8. Begin implementation only after satisfying the upstream project's requirements.
9. Open a legitimate, tested PR and submit its link through the BMS PR Submission Form.
10. The organising team tracks milestones according to the scoring system.

4. Upstream Repository Rules Take Priority

Every contribution must comply with the contribution policy of the external repository. BMS Open Source Sprint rules cannot override the rules established by repository maintainers.

Contributors are expected to communicate respectfully with maintainers, follow repository etiquette, and never use the event as a reason to pressure maintainers into accepting work.

5. Contribution Tracks

5.1 Track A — First Open-Source Contribution

This track is intended for beginners experiencing authentic open source for the first time. The goal is to complete one proper contribution lifecycle rather than maximize the number of PRs.

• Small bug fixes
• Good-first issues
• Tests and test improvements
• Documentation improvements
• UI fixes
• Validation fixes
• Accessibility improvements

5.2 Track B — Open Source Challenge

This track is intended for experienced contributors ready to attempt technically deeper work.

• Intermediate bugs
• New features
• Performance improvements
• Testing infrastructure
• CI/CD improvements
• Security fixes
• Backend integrations
• Larger technical contributions

Both tracks participate in the same leaderboard. Difficulty and technical scope determine the recognition awarded.

6. Issues Created by Contributors

Participants may discover genuine bugs or useful feature requests that are not already documented. Simply opening an issue is not enough, preventing unnecessary issue creation and protecting external repositories from spam.

• Maintainer confirms it is a genuine bug.
• Maintainer applies a relevant label.
• Maintainer explicitly confirms the issue as valid.
• Maintainer accepts the feature request.
• The issue directly leads to an accepted PR.

A high-quality, externally validated issue may be approved for credit after verification by the BMS technical team.

7. Activities That Do Not Count

• Starring repositories
• Forking repositories
• Random GitHub comments
• Opening unnecessary issues
• Typo-only PRs
• Adding your name to contributor files
• README formatting-only changes
• Artificially splitting one task into several PRs
• Submitting code without testing
• PRs rejected as spam
• PRs copied from existing contributors
• AI-generated PRs that the contributor cannot explain
• Repositories where the only contribution is adding your name as a first contribution

8. Artificial Intelligence (AI) Policy

AI tools may be used as learning and development assistants, but participants remain fully responsible for the code and content they submit. Every contributor must understand, test and be able to explain their contribution.

8.1 Permitted Uses

• Learning and understanding unfamiliar concepts
• Understanding existing code
• Debugging assistance
• Brainstorming possible approaches
• Test generation assistance
• Documentation assistance

8.2 Verification of Suspicious Contributions

If a PR appears suspicious, excessively generated, copied, or inconsistent with the contributor's demonstrated understanding, the technical team may ask the contributor to:

• Explain the issue and intended solution.
• Explain the submitted code and important functions.
• Run the project and demonstrate the change.
• Explain important design decisions.
• Make a small live modification to demonstrate understanding.

If the contributor cannot explain or demonstrate the contribution, it may be rejected from event scoring. Repeated AI-spam, plagiarism, or deliberate misrepresentation may result in disqualification.

9. Issue Claiming Limits and Inactivity

• To prevent contributors from reserving large numbers of issues without working on them, the event will initially allow one active scoring issue per contributor.
• A contributor may request another issue after their first PR has been submitted or the current contribution is meaningfully progressing.
• Contributors should provide updates when work is delayed or blocked.
• If a contributor remains inactive for 48 hours without an update, the internal claim may be released for another participant.
• Releasing an inactive claim is intended to keep the issue pool available to active contributors and does not automatically imply misconduct.

10. Event Operations and Tracking

10.1 Internal Systems

• Issue Claim Form — request an issue for internal verification.
• PR Submission Form — submit PR links and trigger milestone tracking.
• Leaderboard Sheet/Database — record validated milestones.
• Contributor Communication Group — announcements, support and coordination.
• Technical Domain Assignments — organisers/mentors assigned to Web, Python, AI, C/C++, Cybersecurity and other domains.

10.2 Recommended Contribution Record

11. Contributor Code of Conduct and Etiquette

• Communicate respectfully with maintainers and other contributors.
• Read repository documentation before asking questions.
• Do not repeatedly ping or pressure maintainers for assignment or review.
• Do not claim an issue already assigned to someone else.
• Do not submit unfinished or untested code.
• Clearly communicate blockers to the BMS technical team.
• Respect the external project's contribution guidelines, license and code of conduct.
• Represent BMSCE professionally in all external project interactions.

12. Quality Control and Disqualification

The organising and technical teams may reject event credit for contributions that are clearly low-quality, misleading, duplicated, spam-like, plagiarized, artificially inflated, or inconsistent with the event rules.

• Duplicate or competing contributions may be rejected from scoring.
• Spam PRs or unnecessary issues will be rejected.
• Plagiarized or copied contributions may result in disqualification.
• Repeated inability to explain submitted work may result in disqualification under the AI policy.
• Attempts to manipulate the leaderboard or split one task artificially may result in submission cancellation and further review.

13. Final Event Principle