Program Guidelines

Finding an issue

• Start on the Projects page and pick a project whose tech stack you know or want to learn.
• Look for issues labelled “good first issue”, “beginner”, or “help wanted” if you are new.
• Check that nobody is already assigned and that there is no open pull request for the issue.
• Comment on the issue to ask to be assigned, briefly explaining how you plan to approach it. Wait for a maintainer to assign you before starting.
• Work on one or two issues at a time. Release an issue you can no longer work on, so someone else can pick it up.

Getting started with a repository

• Read the README, CONTRIBUTING.md, and Code of Conduct of the project before you write any code.
• Set up the project locally and make sure it builds and its tests pass before you make changes.
• Follow the project’s coding style, commit conventions, and branch naming rules.

Git and GitHub workflow

1. Fork the repository and clone your fork.
2. Create a new branch for each issue, e.g. fix/123-navbar-overflow. Never work directly on main.
3. Make small, focused commits with clear messages.
4. Keep your branch up to date with the upstream default branch.
5. Push your branch and open a pull request against the upstream repository.

New to this? Follow the step-by-step guides in Resources.

Contribution quality

• Solve the issue you were assigned. Keep unrelated changes out of the pull request.
• Test your change locally and add or update tests where the project has them.
• Update documentation when your change affects how something is used.
• Meaningful contributions matter more than the number of pull requests.

Pull request requirements

• Link the issue your PR resolves (for example, “Closes #123”).
• Describe what you changed, why, and how you tested it. Add screenshots for UI changes.
• Follow the project’s pull request template if it has one.
• Make sure checks and tests pass, and resolve merge conflicts before requesting review.

Collaboration etiquette

• Be respectful and patient. Maintainers and mentors are volunteers.
• Don’t ask to be assigned to issues someone else is already working on.
• Don’t repeatedly ping maintainers for reviews or merges.
• Follow the Code of Conduct in every channel: GitHub, Discord, and sessions.

Communicating with maintainers

• Keep discussion about an issue or PR on GitHub, in that issue or PR, so context stays in one place.
• Use the project’s Discord channel for general questions about the project.
• When you’re stuck, explain what you tried, what you expected, and what happened, including error messages.
• Give maintainers reasonable time to respond before following up.

Responsible use

• You may use AI coding assistants to explore a codebase, understand errors, draft code, or write tests.
• You are responsible for every line you submit, whether you wrote it or a tool did.

Understand what you submit

• Only submit code you can explain. Maintainers and mentors may ask you how your change works.
• If you can’t answer questions about your pull request, it may be closed.

Test and verify

• Run and test AI-generated code before submitting it. Check it against the project’s conventions.
• Check for invented APIs, outdated dependencies, security problems, and licensing issues.

Be transparent

• Mention significant AI assistance in your pull request description when a project asks for it.
• Write issue comments and PR descriptions in your own words.

No low-effort or mass-generated contributions

• Do not submit bulk, auto-generated, or copy-pasted pull requests to collect points.
• Low-effort contributions waste maintainers’ time. They can be closed without review and may not count towards the leaderboard.

Respect project policies

• Some projects restrict or forbid AI-generated contributions. A project’s own policy always takes precedence over this one.
• If you’re unsure, ask the maintainers before using AI tools on their project.

Learning over volume

WOCS values collaboration and learning over the number of pull requests. A single well-understood, well-tested contribution is worth more to you and to the project than many shallow ones.

What counts as an accepted contribution

Points are awarded for merged pull requests to participating WOCS projects during the coding period (November 1, 2026 – January 31, 2027). Pull requests that are closed without being merged do not earn points.

How points are earned

Points are scaled by issue difficulty:

How quality is considered

The leaderboard rewards meaningful work, so read the AI-assisted contribution policy and the contribution quality guidelines above.

Spam submissions

Spam pull requests don’t earn points. Points can be deducted if you’re reported for spam submissions.

Reporting someone or an issue

Types of recognition

• Certificates for participants.
• Top contributors announced at the end of the program.
• Swags and goodies for top contributors, where available.

When

Certificates are distributed and winners announced on February 10, 2027.

Eligibility and how to qualify

To be eligible for a certificate, you need at least one merged pull request.