Contributor Rulebook

01

Eligibility

• Open to currently enrolled students at a participating IIT.
• Register with your official institute email address — it's used to verify eligibility.
• Each student may register for at most 2 projects at a time.

02

Timeline and Tracks

• Only PRs opened between 1 and 31 October 2026 count towards scoring.tbc
• PRs opened after 31 October won't be scored, but may still be reviewed during wrap-up.tbc

03

Getting Started

Before you touch any issue, you must have the project running locally and understand how it is laid out.

Found a gap or error in the setup instructions? Fixing it is a valid first contribution.

• Register for the programme, join the Hello FOSS Discord server, then join your project's channel.
• Attend your project's onboarding session (29–30 September), or watch the recording if one exists.
• Read the repository's README and CONTRIBUTING guidelines end to end.
• Fork the repository and set up the development environment by following the README exactly.
• Run the project and its tests locally before claiming any issue.
• If setup fails, search existing issues and Discord history first. Still broken? Report it in the project channel with your OS, the command you ran, and the full error.

04

Picking and Claiming Issues

Don't start coding until a mentor assigns the issue to you. Unassigned PRs may be closed.

• Use labels to match your level (good first issue, beginner, intermediate, advanced) and type (bug, feature, documentation).
• Read the whole issue, including comments, and check nobody is assigned and no open PR already addresses it.
• Comment on the issue asking to be assigned, with one or two lines on how you plan to approach it.
• Hold at most 2 assigned issues at a time on the Beginner track, or 3 on the Advanced track.tbc
• Post a progress update at least every 5 days. Issues with no activity for 5 days may be reassigned.tbc
• Can't continue? Say so on the issue and unassign yourself.
• For architectural or advanced issues, post your proposed approach and wait for mentor feedback before implementing.
• Want to report a bug or propose a feature? Search for duplicates, give clear repro steps or motivation, and wait for a mentor to label and approve it first.

05

Git, Commits and Pull Requests

1. Get assigned

   Comment on the issue, wait for a mentor

2. Branch

   One branch per issue, on your fork

3. Open PR

   Link the issue in the description

4. Review

   Address feedback on the same branch

5. Merged

   Lands upstream and scores

06

Review and Feedback

Mentors review your PR as maintainers: does it solve the issue, fit the project's conventions, handle edge cases, and include tests and docs where needed?

• Respond to every review comment, either with a change or a reasoned reply.
• Push fixes to the same branch — don't open a new PR for the same issue.
• Reply within 3 days of a review. PRs inactive for 7 days after a review may be closed and reassigned.tbc
• Disagree politely and with reasons. The mentor's decision on project direction is final.
• Re-request review once all comments are resolved.
• Mentors aren't expected to reply instantly. Wait a reasonable time, then ping once.

07

Scoring and Prizes

Each merged PR earns a score based on its priority, code volume, and complexity. The highest totals at the end of the programme are eligible for prizes.

• Mentors may add up to +50% for high-priority issues or unusually complex work.tbc
• Only merged PRs score. Open or closed-unmerged PRs score zero.
• The PR must be linked to an issue that was assigned to you.
• Volume means meaningful change, not line count. Splitting one fix into many PRs, padding code, or trivial edits won't be scored.
• Mentors' scoring decisions are final; organisers handle disputes.
• Leaderboards are tracked separately for the Beginner and Advanced tracks.tbc

08

Asking for Help

Ask in public, after you've tried yourself. Mentors aim to make you independent, so they'll point you to answers rather than hand them over.

Don't DM mentors for technical help unless they invite you to. Public answers help the next person.

• Project questions go in your project's Discord channel or on the GitHub issue; setup and general debugging go in the global channels.
• Before asking, read the README, CONTRIBUTING file, and issue comments, and search existing issues, PRs, and Discord history.
• When you ask, say what you're trying to do, what you tried, what happened, and what you expected.
• Paste errors as text in code blocks, not screenshots.
• Ping a mentor at most once per question, and only after a reasonable wait.
• Blocked by something outside your project (repo down, missing access, conduct issues)? Tell your mentor — they'll escalate.

09

Conduct and Integrity

Be respectful, do your own work, and be able to explain every line you submit.

• Treat mentors, maintainers, and fellow contributors with respect, on Discord and GitHub alike.
• No harassment, discrimination, insults, spam, or self-promotion.
• Follow each repository's own Code of Conduct, including upstream projects beyond Hello FOSS.
• No sniping assigned issues or copying another contributor's open PR.
• Submit only your own work. Copying code without credit or breaking a licence is not allowed.
• Respect upstream projects: follow their contribution rules and don't flood them with low-quality PRs.

10

AI Toolstbc

• AI assistants may be used for learning and drafting, but you are responsible for every line you submit.
• You must understand, test, and be able to explain your changes when a mentor asks.
• Disclose significant AI assistance in the PR description.
• Bulk AI-generated PRs, unreviewed code, or AI-written review replies are not allowed.

11

Violations and Consequencestbc

Mentors report violations to the organising team, which makes the final decision.

12

Before Every PR

Tick these off as you go — your progress is saved in this browser.