Skip to content

Commit 6b5b650

Browse files
shadil-rayyanshadil-rayyan
committed
docs: overhaul open-source and social-media sections
- Expanded open-source guide with contribution workflows, project finding tips, and etiquette. - Refactored social-media section: specialized guides for Reddit, Discord, YouTube, etc. - Renamed linkedln.md to linkedin.md and improved content. - Added Arsh Goyal to whatsapp-channel.md.
1 parent c278206 commit 6b5b650

13 files changed

Lines changed: 544 additions & 335 deletions

‎docs/open-source/etiquette.md‎

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
# 🤝 Open Source Etiquette & Soft Skills
2+
### How to Not Be "That Guy"
3+
4+
Open Source is built by humans, not robots. Most maintainers are volunteers working in their free time. Being polite and professional is often **more important than your code quality**.
5+
6+
---
7+
8+
## 📜 Rule #1: Read the CONTRIBUTING.md
9+
10+
Most repos have a `CONTRIBUTING.md` file. It contains the "House Rules":
11+
* "Use this code style."
12+
* "Run these tests before pushing."
13+
* "Use this template for Pull Requests."
14+
15+
**If you ignore this file, your PR will be closed immediately.** It shows you didn't respect their time.
16+
17+
---
18+
19+
## 🙋‍♂️ How to Ask for Help
20+
21+
**Bad:** "This doesn't work. Help."
22+
(The maintainer has no idea what you did).
23+
24+
**Good:** "I'm trying to run the setup script on Ubuntu 20.04. I got error X. I tried doing Y to fix it, but it didn't work. Here is a screenshot of the log."
25+
26+
> **Tip:** Google your error first. If the answer is on the first page of Google, the maintainer will be annoyed that you didn't look.
27+
28+
---
29+
30+
## 👻 The "Ghosting" Problem
31+
* If you say "I'm working on this!", **do it**.
32+
* If you get busy and can't finish it, **tell them**. "Hey, sorry, I have exams. Unassigning myself so someone else can take it."
33+
* This is totally fine! Ghosting (disappearing silently) blocks others from fixing the bug.
34+
35+
---
36+
37+
## ⚔️ Handling Feedback (Code Reviews)
38+
When a maintainer requests changes, **don't take it personally**.
39+
* They aren't saying *you* are bad.
40+
* They are saying *the code* needs to fit their project standards.
41+
* **Reply:** "Thanks for the review! I'll make those changes tonight."
42+
43+
---
44+
45+
## 🚫 Don't be a "Spam Contributor"
46+
* **Don't** submit PRs just to add your name to a list.
47+
* **Don't** fix typos that don't exist.
48+
* **Don't** use AI to generate broken code and dump it in a PR.
49+
50+
**Quality > Quantity.** One meaningful bug fix is worth more than 50 "Fixed typo" PRs.

‎docs/open-source/finding_projects.md‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# 🔎 How to Find Open Source Projects
2+
### "Where do I even start?"
3+
4+
The biggest blocker for students isn't *coding skill*—it's **finding a project** that fits their level. You don't want to start with the Linux Kernel!
5+
6+
---
7+
8+
## 🏷️ The Magic Keyword: "Good First Issue"
9+
10+
Maintainers often label easy tasks specifically for beginners. These are usually small bug fixes, documentation updates, or simple UI tweaks.
11+
12+
### How to search for them:
13+
1. **GitHub Search:** Type `label:"good first issue" language:python` (or your preferred language) in the GitHub search bar.
14+
2. **Dedicated Websites:**
15+
* [**GoodFirstIssue.dev**](https://goodfirstissue.dev/): Curates reputable projects with easy issues.
16+
* [**Up-For-Grabs.net**](https://up-for-grabs.net/): A classic directory of beginner-friendly projects.
17+
* [**CodeTriage.com**](https://www.codetriage.com/): Sends you one open issue a day to your inbox.
18+
19+
---
20+
21+
## 🏥 Assessing Project "Health"
22+
Before you dive in, check if the project is alive and friendly.
23+
24+
1. **Last Commit Date:** Is it from 3 days ago or 3 years ago? (Avoid dead projects).
25+
2. **Activity:** Are people replying to Issues and PRs?
26+
3. **CONTRIBUTING.md:** Does this file exist? If yes, it's a green flag that they welcome new contributors.
27+
4. **Readme Quality:** A good README means the maintainers care about user experience.
28+
29+
---
30+
31+
## 🏟️ Starter Projects (Hall of Fame)
32+
Some repositories are famous for being good training grounds:
33+
34+
* **FreeCodeCamp:** Huge, active, and very beginner-friendly.
35+
* **Microsoft/VSCode:** Surprisingly organized, with many tagged issues.
36+
* **Documentation Repos:** Most major frameworks (React, Vue, Django) have separate docs repos. Fixing a typo in documentation **is** a valid open source contribution!
37+
38+
---
39+
40+
## 🛑 What to Avoid (Red Flags)
41+
* **"Dump" Repos:** Projects with no description, 1 commit, and zero stars.
42+
* **Angry Maintainers:** If you see maintainers being rude in the Issue comments, run away.
43+
* **Complex Core Logic:** Don't try to rewrite the garbage collector of a language for your first PR. Start small.

‎docs/open-source/how_to_contribute.md‎

Lines changed: 96 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,96 @@
1+
# 🛠️ How to Contribute: The Workflow
2+
### Your Step-by-Step Guide to Making Your First Pull Request
3+
4+
So you found a bug to fix or a feature to add. Awesome! But how do you actually get your code into their project?
5+
6+
This is the standard **Fork & Pull Request Workflow** used by almost every open-source project.
7+
8+
---
9+
10+
## 🏗️ Step 1: Fork the Repository
11+
12+
A **Fork** is your personal copy of someone else's repository. You can't write directly to their project (you don't have permission), so you write to your copy first.
13+
14+
1. Go to the project page on GitHub (e.g., `facebook/react`).
15+
2. Click the **Fork** button in the top-right corner.
16+
3. GitHub will create a copy under your account (e.g., `your-username/react`).
17+
18+
---
19+
20+
## 📥 Step 2: Clone Your Fork
21+
22+
Now, bring that code to your local machine.
23+
24+
```bash
25+
# Don't clone the original! Clone YOUR fork.
26+
git clone https://github.com/your-username/project-name.git
27+
cd project-name
28+
```
29+
30+
---
31+
32+
## 🌿 Step 3: Create a New Branch
33+
34+
**Never** work on the `main` or `master` branch. Always create a separate branch for your specific task.
35+
36+
```bash
37+
# Standard naming: feature/feature-name or fix/bug-name
38+
git checkout -b fix/typo-in-readme
39+
```
40+
41+
---
42+
43+
## ✍️ Step 4: Make Your Changes
44+
45+
1. Open the code in VS Code.
46+
2. Fix the bug or add the feature.
47+
3. **Test your changes!** (Run the project locally to make sure it works).
48+
49+
---
50+
51+
## 💾 Step 5: Commit and Push
52+
53+
Save your changes and send them up to *your* fork on GitHub.
54+
55+
```bash
56+
git add .
57+
git commit -m "Fix typo in documentation"
58+
git push origin fix/typo-in-readme
59+
```
60+
61+
---
62+
63+
## 🔀 Step 6: Open a Pull Request (PR)
64+
65+
1. Go to your fork on GitHub.
66+
2. You will see a yellow banner: **"Compare & pull request"**. Click it.
67+
3. **Title:** Be clear (e.g., "Fixed broken link in CONTRIBUTING.md").
68+
4. **Description:** Explain *what* you changed and *why*.
69+
5. Click **Create Pull Request**.
70+
71+
🎉 **Congratulations! You just submitted a contribution!**
72+
73+
---
74+
75+
## ⏳ Step 7: The Review Cycle (Wait & Iterate)
76+
77+
The maintainers will get a notification. Now, three things can happen:
78+
79+
1. **Merged!** 🥳 (They accept your code).
80+
2. **Changes Requested:** They like the idea but want you to fix something (style, variable names, etc.).
81+
* *What to do:* Make changes locally, `git add`, `git commit`, and `git push`. The PR updates automatically!
82+
3. **Closed:** They decided not to merge it. (Don't feel bad, it happens to everyone).
83+
84+
---
85+
86+
## 🔄 Pro Tip: Keeping Your Fork Sync'd
87+
88+
While you were working, the original project might have moved forward. To keep your fork up to date:
89+
90+
```bash
91+
# Add the 'upstream' (original) repository
92+
git remote add upstream https://github.com/original-owner/project-name.git
93+
94+
# Pull the latest changes
95+
git pull upstream main
96+
```

‎docs/open-source/program.md‎

Lines changed: 99 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -1,13 +1,99 @@
1-
| Program | Organizer | When it Happens | Who Can Apply | Benefits |
2-
| ------------------------------------------- | ------------------------------- | --------------------------------------- | ----------------------------------------- | ---------------------------------------------------------------------------------- |
3-
| **Google Summer of Code (GSoC)** | Google | Every summer (May–Aug) | Students & beginners in open source (18+) | Stipend 💰, mentorship, chance to work on big open-source orgs, global recognition |
4-
| **Google Season of Docs** | Google | Annual (around April) | Technical writers, students, developers | Stipend, mentorship, contribute documentation to open source |
5-
| **Outreachy** | Software Freedom Conservancy | Twice a year | Underrepresented groups in tech | Paid remote internships, mentorship |
6-
| **Linux Foundation Mentorship Program** | Linux Foundation | Year-round (multiple rounds) | Students, beginners, developers | Mentorship in Linux kernel & related projects, stipend |
7-
| **MLH Fellowship** | Major League Hacking | 3 batches per year | Students/new grads | Mentorship, work on real projects, stipend, networking |
8-
| **GitHub Externships (India only)** | GitHub + Partners | Summer/Winter | Indian students | Work with startups & open-source projects, stipend |
9-
| **Season of KDE** | KDE Community | Annual (Dec–Feb) | Students & beginners | Mentorship, certificate, experience |
10-
| **Hacktoberfest** | DigitalOcean + GitHub | Every October | Anyone | Free swag 👕, open-source contributions, beginner-friendly |
11-
| **FOSSASIA CodeHeat** | FOSSASIA | Annual | Students & developers | Mentorship, swag, possible stipend, recognition |
12-
| **Google Code-In (retired, but important)** | Google | Used to run for pre-university students | High-school students | Swag, exposure, mentorship (now merged into GSoC focus) |
13-
| **Bitcoin Summer of Code** | Bitcoin/crypto open-source orgs | Summer | Students, blockchain enthusiasts | Mentorship, stipend, blockchain open-source exposure |
1+
# 🌟 Open Source Student Programs & Internships
2+
3+
Getting involved in open source is one of the best ways to build your resume, earn a stipend, and get mentorship from world-class engineers.
4+
5+
Instead of a confusing table, here is a curated list of the best programs, categorized by type.
6+
7+
---
8+
9+
## 🏆 The "Big League" Programs
10+
*These are the most prestigious, often paid, and competitive programs.*
11+
12+
### 1. Google Summer of Code (GSoC)
13+
* **🗓️ When:** Applications open around March/April (Summer program).
14+
* **🎯 Who:** Students and beginners (18+).
15+
* **💰 Benefits:** Generous stipend (varies by country), mentorship, global recognition.
16+
* **📝 Details:** The "Holy Grail" of open source. You work on a specific project for an open-source organization (like Python, TensorFlow, or KDE) for about 3 months.
17+
18+
### 2. Outreachy
19+
* **🗓️ When:** Twice a year (May-Aug & Dec-Mar).
20+
* **🎯 Who:** People from underrepresented groups in tech (women, minorities, etc.).
21+
* **💰 Benefits:** $7,000 stipend + travel budget.
22+
* **📝 Details:** A very supportive, remote internship program. It focuses heavily on mentorship and inclusivity.
23+
24+
### 3. LFX Mentorship (Linux Foundation)
25+
* **🗓️ When:** Year-round (Spring, Summer, Fall terms).
26+
* **🎯 Who:** Anyone (students & professionals).
27+
* **💰 Benefits:** Stipend (varies), huge networking with Linux/Cloud professionals.
28+
* **📝 Details:** Work on serious infrastructure projects like **Linux Kernel, Kubernetes, and Hyperledger**. Great for those interested in Cloud & DevOps.
29+
30+
### 4. MLH Fellowship
31+
* **🗓️ When:** Fall, Spring, Summer (12-week batches).
32+
* **🎯 Who:** Aspiring software engineers.
33+
* **💰 Benefits:** Educational stipend, real-world experience.
34+
* **📝 Details:** Unlike GSoC (where you work alone), here you are placed in a "pod" of students and work as a team on open-source projects for companies like Meta and Adobe.
35+
36+
---
37+
38+
## 🇮🇳 Popular in India & Beginner Friendly
39+
*Great stepping stones before tackling GSoC.*
40+
41+
### 5. GirlScript Summer of Code (GSSoC)
42+
* **🗓️ When:** Annually (Usually summer).
43+
* **🎯 Who:** Everyone (Very beginner-friendly).
44+
* **💰 Benefits:** Swag, certificates, strong community feel.
45+
* **📝 Details:** A 3-month long open-source program. It is **not** paid like GSoC, but it is excellent for learning the basics of Git/GitHub in a low-pressure environment.
46+
47+
### 6. GitHub Externships
48+
* **🗓️ When:** Winter/Summer cohorts.
49+
* **🎯 Who:** Students currently enrolled in Indian colleges.
50+
* **💰 Benefits:** Stipend, potential job offers.
51+
* **📝 Details:** GitHub partners with companies to provide mentorship and real project work.
52+
53+
### 7. Social Summer of Code (SSoC)
54+
* **🗓️ When:** Annual.
55+
* **🎯 Who:** Beginners.
56+
* **💰 Benefits:** Mentorship, badges, certificates.
57+
* **📝 Details:** Similar to GSSoC, focused on social impact projects and getting beginners started.
58+
59+
---
60+
61+
## 🍂 Short-Term & Seasonal Events
62+
*Fun events to get quick wins and swag!*
63+
64+
### 8. Hacktoberfest (October Only)
65+
* **🗓️ When:** Every October.
66+
* **🎯 Who:** EVERYONE.
67+
* **💰 Benefits:** Digital badges (formerly free T-shirts), knowing you contributed.
68+
* **📝 Details:** Hosted by DigitalOcean. The goal is simple: Submit 4 valid Pull Requests to ANY public GitHub repo during October. It's the biggest open-source event of the year.
69+
70+
### 9. Season of KDE
71+
* **🗓️ When:** January - April.
72+
* **🎯 Who:** Students.
73+
* **💰 Benefits:** Mentorship, T-shirts/Merch, Certificate.
74+
* **📝 Details:** A structured outreach program for the **KDE** community (famous for the Linux Desktop environment).
75+
76+
### 10. FOSSASIA CodeHeat
77+
* **🗓️ When:** Annual (usually starts later in the year).
78+
* **🎯 Who:** Students.
79+
* **💰 Benefits:** Prizes, opportunity to present at the FOSSASIA summit in Singapore.
80+
* **📝 Details:** Focuses on FOSSASIA projects like Pocket Science Lab and Susper.
81+
82+
---
83+
84+
## ✍️ Not a Coder? No Problem!
85+
86+
### 11. Google Season of Docs (GSoD)
87+
* **🗓️ When:** Annual.
88+
* **🎯 Who:** Technical Writers (Professional or Student).
89+
* **💰 Benefits:** Stipend.
90+
* **📝 Details:** Open source projects usually have bad documentation. Google pays you to fix that.
91+
92+
---
93+
94+
## 💎 Niche & Other Programs
95+
* **Summer of Bitcoin:** Focuses on Bitcoin & Blockchain open-source development.
96+
* **Hyperledger Mentorship:** Specifically for enterprise blockchain technologies.
97+
* **24 Pull Requests:** A "coding calendar" event in December (submit a PR every day till Christmas).
98+
99+
> 💡 **Pro Tip:** Don't just wait for applications to open! Pick a project you like, join their Discord/Slack, and start fixing small typos *today*. That's how you get selected when the program starts.

‎docs/open-source/software_licenses.md‎

Lines changed: 69 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,69 @@
1+
# 📜 Understanding Software Licenses
2+
3+
When you create or use open-source software, **licenses** dictate what you can and cannot do with that code and how you must treat it.
4+
5+
Think of a license as the **"Terms and Conditions"** for code — but usually much friendlier!
6+
7+
---
8+
9+
## ❓ What is a Software License?
10+
11+
A software license is a legal document that governs the use or redistribution of software. In the open-source world, licenses give others permission to use your code, but often with some conditions attached.
12+
13+
Without a license, **nobody else has the legal right to use, copy, or distribute your code**, even if you put it on GitHub publicly!
14+
15+
---
16+
17+
## 🏎️ The MIT License
18+
**"The 'Do Almost Anything' License"**
19+
20+
* **Type:** Permissive
21+
* **Best for:** Simple, small projects, or when you want maximum adoption.
22+
* **What it says:** You can do whatever you want with this code (use it, change it, sell it), as long as you **keep the original copyright notice** and license file in your copy.
23+
* **Popular projects:** React, Node.js, VS Code (core).
24+
25+
> ✅ **Summary:** Short, simple, and very flexible.
26+
27+
---
28+
29+
## 🪶 The Apache License 2.0
30+
**"The 'Do Anything, But With Patent Protection' License"**
31+
32+
* **Type:** Permissive
33+
* **Best for:** Larger open-source projects, corporate-backed tools.
34+
* **What it says:** Similar to MIT (do whatever you want), but it adds an explicit grant of **patent rights** from contributors to users. It also requires you to document significant changes to the files.
35+
* **Popular projects:** Android, Apache HTTP Server, TensorFlow, Kubernetes.
36+
37+
> ✅ **Summary:** Like MIT, but safer for big companies and patents.
38+
39+
---
40+
41+
## 🛡️ GNU General Public License (GPLv3)
42+
**"The 'Copyleft' or 'Share-Alike' License"**
43+
44+
* **Type:** Copyleft (Protective)
45+
* **Best for:** Ensuring the software *stays* free and open forever.
46+
* **What it says:** If you base your software on GPL code and distribute it, **your software must ALSO be open source** under the same GPL license. You cannot take GPL code, modify it, close it up, and sell it as a proprietary secret.
47+
* **Popular projects:** Linux Kernel (GPLv2), Git, WordPress, GIMP.
48+
49+
> ⚠️ **Summary:** Sticky! If you use GPL code in your project, your project essentially becomes GPL too.
50+
51+
---
52+
53+
## ⚖️ Quick Comparison for Students
54+
55+
| License | Can I use it for private work? | Can I sell it? | Must I share my changes? | Complexity |
56+
| :--- | :--- | :--- | :--- | :--- |
57+
| **MIT** | ✅ Yes | ✅ Yes | ❌ No | Low |
58+
| **Apache 2.0** | ✅ Yes | ✅ Yes | ❌ No | Medium |
59+
| **GPLv3** | ✅ Yes | ✅ Yes | ✅ **Yes** (if distributed) | High |
60+
61+
---
62+
63+
## 🧠 Which one should I choose?
64+
65+
* **For most student projects:** Go with **MIT**. It's simple and encourages people to use your code.
66+
* **If you care about patents:** Use **Apache 2.0**.
67+
* **If you believe code should always remain free:** Use **GPL**.
68+
69+
👉 *Check out [ChooseALicense.com](https://choosealicense.com/) for a non-lawyer explanation of every license.*

0 commit comments

Comments
 (0)