{{Header}} {{title|title= First-Time Source Code Contributor Policy }} {{#seo: |description=Guidelines and expectations for first-time contributors to ensure a smooth and respectful development experience. }} {{policy_mininav}} {{intro| This page outlines our expectations for first-time contributors to the source code of this project. It's designed to keep the development process productive and respectful of everyone's time - yours and ours. }} == Getting Started == We love seeing new contributors join the project. To make the most of your first contribution, we recommend: * '''Start with code:''' The best introduction is a small, working code contribution. * '''Keep it simple:''' Fix something straightforward or improve an area that's well isolated. * '''Be self-guided:''' Your first contribution should be self-contained and require minimal discussion beforehand. == Requirements == * '''Use of Git:''' All contributions must be made using the git version control system (not the GitHub web editor). * '''Build the project yourself:''' You should be able to build and run the code locally without requiring step-by-step help. == GitHub Web Contributions == * '''No GitHub Web based contributions:''' First-time contributions should not be made via the GitHub web interface. Exceptions may be granted in rare cases. '''Rationale:''' In some cases, we've seen misuse of GitHub web + AI tools to submit low-effort or non-functional pull requests. Using git directly helps show genuine intent and familiarity with the development process. * '''No AI policy:''' Contributions cannot be purely AI generated. AI-generated content must be clearly marked as such. See also [[Policy_On_Artificial_Intelligence|Policy On Artificial Intelligence (AI)]] applies. == Exemptions == This policy is intended for new contributors who have not yet demonstrated prior experience or familiarity with the codebase. You may be exempt from the first-time contributor policy if you meet any of the following: * '''Public verifiable skills:''' You have a public history of software contributions (e.g. GitHub, GitLab, personal repositories). You can provide links to projects or code samples that demonstrate moderate to advanced programming skills. ** '''Verification required:''' Simply claiming to be someone is not sufficient. Evidence is required to verify identity and prevent impersonation. See footnote for acceptable verification options. Verification is not yet governed by a fixed policy and may evolve over time. However, many reasonable methods are currently acceptable, including: * '''Social media-based:''' Posting a verification message from a known social media account (e.g. a tweet or direct message from your Twitter/X profile). * '''Signed message:''' Sending a signed message using OpenPGP from a key known to be associated with you. * '''Email-based verification:''' Emailing from an address associated with your past contributions (e.g. one used in your git commit history). * '''Forum + git match:''' Using a forum or project account that uses the same email address as your git commits. * '''Past contributors:''' You have previously contributed to this project under your current identity. * '''Bypass via source code:''' No verification is required if you submit a working, self-contained code contribution. == Not Considered Valid Exemptions == * '''Claiming anonymous past contributions:''' Claims of past contributions under anonymous or pseudonymous identities that cannot be verified. * '''Non-code activity only:''' Prior contributions limited to issue comments, suggestions, or other non-technical participation without source code implementation. == Why This Policy Exists == This policy is not meant to gatekeep contributors - it’s here to protect everyone’s time and ensure the project stays focused and sustainable. * '''Extended discussions without code:''' In Open Source, it's common for well-meaning users (and sometimes trolls or bots) to engage in long conversations without ever submitting working code. * '''Source contributions require initiative:''' While general questions are welcome in discussion channels, code contributions demand technical skill, follow-through, and independent effort. * '''Idea nudging without action:''' We've seen cases where non-programmers unintentionally nudge maintainers into building features through vague suggestions or persistent questioning - without offering implementation. * '''Time cost for maintainers:''' These exchanges often take more time to respond to than it would take to write the code ourselves, reducing time available for actual development. To help explain this dynamic, here’s a quote: {{quotation |quote= [...] Contributing to open-source can be great. You should do it because you're actually really interested in one particular project, like it's something you actively use, and you'd like to contribute your own skill to making it better. If you do it, the rule of thumb is that you should be able to build and run the code without assistance, and you should be able to find a bug that you can actually make some progress towards fixing on your own, before you should consider reaching out offering to help. For the projects I've maintained, for every 10 people who offer to contribute, I'm lucky if 1/10 actually manage to contribute anything, and even then most people leave after one contribution. Only a small fraction stick around to actually create more value than they took. The others have the best of intentions. But because they're beginners, they have trouble building the code, so we help them. Then they have trouble understanding the code, so we point them in the right direction. Then they have trouble debugging, so we give them some pointers on how to use their debugger and some good places to set breakpoints. Then they struggle to figure out how to fix the bug they were trying to work on, and eventually give up because the code is a lot more complex than anything they've ever worked on before, and they're just not ready. So it ends up being several hours wasted on our end, teaching a beginner some skills, and we get nothing out of it, because they lose interest. And that's taking away time that we could have spent making that project better. We only have so much time - whether paid time (if we work on the project for some company) or free time (if this is a passion project). [...] |context=https://www.reddit.com/r/learnprogramming/comments/1gtxwbz/how_do_i_prepare_myself_for_a_open_source/ }} This is a common issue: * https://www.reddit.com/r/learnprogramming/comments/10v709r/im_finding_it_difficult_to_start_contributing_to/ * https://goauthentik.io/blog/2024-03-07-why-contributing-to-open-source-is-scary/ * https://antirez.com/news/129 * https://www.reddit.com/r/golang/comments/1gp833w/how_can_a_beginner_contribute_to_opensource/ * https://medium.com/deffectivego/onboarding-issues-in-large-scale-open-source-projects-lets-talk-kubernetes-part-1-a1a64c9c9cfe * https://opensource.guide/best-practices/ == Final Notes == * '''No need to reference this policy:''' If you’re doing real work, your contributions will speak for themselves. * '''Support is available for genuine contributors:''' We’re happy to assist contributors who show initiative and effort - this policy exists to protect that energy, not to discourage it. * '''Not sure where to start?''' Check out open issues tagged as "good first issue" or take a look through the codebase and reach out with concrete questions. * '''More contribution, more support:''' The more source code evidence of skill and initiative you demonstrate, the more support and guidance you’ll naturally receive. == Illustrative Examples == Pull requests that were minimal and required no prior communication. * https://github.com/Kicksecure/legacy-dist/pull/1 = Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Development]] [[Category:MultiWiki]]