Editing First Time Source Code Contributor Policy

{{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 <code>git</code> 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.
* '''No AI policy:''' Contributions cannot be purely AI-generated. AI-generated content must be clearly marked as such, as per [[Policy_On_Artificial_Intelligence|Policy On Artificial Intelligence (AI)]]. AI might be useful for reviewing your code, but you must still write and understand your own code.

== GitHub Web Editor Contributions ==
* '''No GitHub Web Editor based contributions:''' First-time contributions should be made via the <code>git</code> command line and not via the GitHub web editor interface. Exceptions may be granted in rare cases. <ref>
'''Rationale:''' In some cases, we have seen misuse of GitHub web editor + AI tools to submit low-effort or non-functional pull requests. Using <code>git</code> directly helps show genuine intent and familiarity with the development process.
</ref>
* '''GitHub Pull Requests:''' Optional. Permitted. Any <code>git</code> branch anywhere is permissible.

== 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. <ref>
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 <code>git</code> commit history).
* '''Forum + git match:''' Using a forum or project account that uses the same email address as your <code>git</code> commits.
</ref>
* '''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 is 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.
* '''Contributing is difficult:''' Most people cannot perform heart surgery. Even a doctor who does not specialize in it may not be able to perform it. There is no shame in that.

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:

* {{Github_link|
https://github.com/Kicksecure/legacy-dist/pull/1
}}

== Good First Issues ==

We do not have a list of good first issues. This is because after {{project age years}} years, most easy tasks have already been completed. The remaining tasks are difficult research tasks.

A good and self-contained task would be to take existing scripts and improve their coding style as per:

* {{kicksecure_wiki
|wikipage=Dev/bash
|text=bash scripting (development)
}}
* {{kicksecure_wiki
|wikipage=Dev/coding_style
|text=coding style
}}

This would improve code quality and, at the same time, introduce you to the codebase.

There are also a number of relatively self-contained source code repositories. Self-contained meaning that they have a low number of easily installed dependencies and are relatively easy to build.

Examples of mostly self-contained repositories include:

* {{Github_link|
https://github.com/Kicksecure/sysmaint-panel
}}
* {{Github_link|
https://github.com/Kicksecure/sdwdate
}}
* {{Github_link|
https://github.com/Kicksecure/sdwdate-gui
}}

Try finding a task from our [[Reporting_Bugs#Issue_Tracker|Issue Tracker]].

* [https://forums.{{project_name_short}}/search?expanded=true&q=tags%3Astatus_open_issue_todo all <code>status_open_issue_todo</code> issues]

Also [[Stay_Tuned|Follow {{project_name_short}} Developments]].

= See Also =
* [https://forums.whonix.org/t/focus-on-low-effort-maintainability/9067 Focus on low-effort maintainability]
* {{kicksecure_wiki
|wikipage=Dev/maintainability
|text=maintainability
}}
* {{kicksecure_wiki
|wikipage=Stable_Version_User_Experience
|text=Stable Version User Experience
}}

= Footnotes =
provide more value than expenses

refrain from third-party bounties

quick rejections due to volume
no explanation 
no debate
human traffic alone challenging to deal

exponential extra workload
lots of automated communications cannot be added

could prompt myself
no need to middle man through a forum discussion or pull request 

otherwise what's effects happening, projec devs talk talk to machine for purpose of third-party earning a bounty (financial compensation) and additional maintenance load

be emphatic
don't overestimate priority
speaker analogy

<references />
{{Footer}}
[[Category:Development]]
[[Category:MultiWiki]]