Getting Started With Open Source Contributions for Beginners

Getting Started With Open Source Contributions for Beginners ![rw-book-cover](https://img.youtube.com/vi/WldXhauP024/maxresdefault.jpg) 🔗 **Source:** [Getting Started With Open Source Contributions for Beginners](https://www.youtube.com/watch?v=WldXhauP024) > [!note]+ Document Notes > tags: #open-source #github #software-development > author: GitHub > source: YouTube > reference: https://www.youtube.com/watch?v=WldXhauP024 > date created: 2024-12-19 15:42 > > # 🏷️ Title: Getting started with open source contributions for beginners >  ## 🧰 Action Inbox - [H1] Use GitHub Copilot Chat to find beginner-friendly projects — filter by good first issue label #open-source - [H2] Create fork of target repository and make documentation changes — practice safe contribution workflow #github - [H3] Read contributors guide and check for active maintenance — verify project health before contributing #software-development ## 🧭 Table of Contents - [[#📝 Summary]] - [[#📖 Main Content]] - [[#🗒️ Notes]] - [[#📚 References]] - [[#🗣️ Paraphrase]] - [[#📰 Newsletter]] - [[#✅ Action Items]] - [[#🧪 Hypotheses]] - [[#📊 Methodology]] - [[#❓ Questions]] - [[#🔮 Future Research]] - [[#💡 Implications]] - [[#🧠 Learning Styles Assessment]] - [[#📊 Accessibility Assessment]] - [[#🌍 DEIB Assessment]] - [[#✅ Logical Validity]] - [[#🛡️ DARVO Analysis]] - [[#🎯 Conclusion]] ### 🔗 References - [GitHub Open Source Guide](https://gh.io/gfiboss) - [VS Code Repository](https://github.com/microsoft/vscode) ## 📝 Summary - What happened: GitHub tutorial covering open source contribution basics for beginners - Why it matters: Provides accessible entry point for new developers to participate in impactful projects - Key stakeholders: Beginning developers, open source maintainers, GitHub community - Risks and tradeoffs: Need to verify project health and follow contribution guidelines to avoid wasted effort - Bottom line: Open source contribution is achievable with proper project selection and fork-based workflow ## 📖 Main Content This tutorial introduces open source software (OSS) as publicly available code that anyone can use and build upon, contrasting it with closed source alternatives. The presenters demonstrate how to use GitHub Copilot Chat to discover beginner-friendly projects by filtering for specific programming languages and "good first issue" labels. They establish criteria for evaluating project health including documentation quality, active maintenance, community engagement metrics, and clear contribution guidelines. The practical demonstration shows the complete fork-based contribution workflow from identifying issues through creating pull requests. ## 🗒️ Notes #### ⏱️ [00:00](https://youtu.be/WldXhauP024?t=0) — [H1] Introduction to open source contribution tutorial - Key idea: Complete beginner's guide to making first open source contribution - Evidence: "By the end of this video, you'll know what open source is, how to find projects to work on, how to read an open source repo" #### ⏱️ [01:15](https://youtu.be/WldXhauP024?t=75) — [H2] Definition of open source software - Key idea: OSS features freely available source code for public use and building - Evidence: "Open source software is publicly available for anyone to use and build upon" #### ⏱️ [01:45](https://youtu.be/WldXhauP024?t=105) — [H3] GitHub as home for open source software - Key idea: GitHub serves as primary platform for discovering and contributing to OSS projects - Evidence: "GitHub is the home for open source software" #### ⏱️ [02:30](https://youtu.be/WldXhauP024?t=150) — [H1] Using GitHub Copilot Chat to find projects - Key idea: Copilot Chat can filter projects by language and beginner-friendliness - Evidence: "I'm looking for a list of open source projects written in TypeScript that are accepting new contributors" #### ⏱️ [03:45](https://youtu.be/WldXhauP024?t=225) — [H2] Good first issue label significance - Key idea: This label indicates beginner-friendly issues suitable for new contributors - Evidence: "The good first issue label indicates that an issue is beginner-friendly and a great starting point" #### ⏱️ [04:30](https://youtu.be/WldXhauP024?t=270) — [H3] Finding issues in VS Code repository - Key idea: Navigate to issues section and filter by good first issue label - Evidence: "On GitHub, go to the VS Code repo and click issues. Then click labels and filter by good first issue" #### ⏱️ [05:00](https://youtu.be/WldXhauP024?t=300) — [H1] Criteria for well-maintained projects - Key idea: Look for documentation, contributors guide, license, stars, active development - Evidence: "Well-documented readme, contributors guide, open source license, at least 100 GitHub stars, active development" #### ⏱️ [06:15](https://youtu.be/WldXhauP024?t=375) — [H2] Evaluating Gitfolio project example - Key idea: Demonstrates applying evaluation criteria to real repository - Evidence: "Well-documented and there is a contributing.md file that shows me how to contribute code to it" #### ⏱️ [07:30](https://youtu.be/WldXhauP024?t=450) — [H1] Forking repository for contributions - Key idea: Create personal copy of repository to safely experiment with changes - Evidence: "A fork is a copy of a repository...allow us to freely experiment with changes without affecting the original project" #### ⏱️ [08:45](https://youtu.be/WldXhauP024?t=525) — [H2] Making changes via GitHub UI - Key idea: Can contribute through web interface or by cloning repository locally - Evidence: "I'll make the change via the GitHub UI, but you can choose to clone the repo or use a code space" #### ⏱️ [09:30](https://youtu.be/WldXhauP024?t=570) — [H3] Creating pull request from fork - Key idea: Use compare across forks to propose changes to original repository - Evidence: "I'll click compare across forks to show my fork's changes compared to the original repository" #### ⏱️ [10:15](https://youtu.be/WldXhauP024?t=615) — [H2] Pull request review and merge process - Key idea: Maintainers review contributions before merging into main branch - Evidence: "Now it's ready for a maintainer to review and hopefully approve" ## 📚 References - [GitHub Open Source Guide](https://gh.io/gfiboss) - [VS Code Repository](https://github.com/microsoft/vscode) - [GitHub Forking Documentation](https://docs.github.com/en/get-started/quickstart/fork-a-repo) ## 🗣️ Paraphrase - Open source software provides freely available code that anyone can examine, use, and improve, making it an excellent learning opportunity for new developers - Finding suitable projects involves using tools like GitHub Copilot Chat and filtering for beginner-friendly labels while evaluating project health through documentation and activity metrics - The contribution process follows a fork-based workflow where contributors create personal copies, make changes, and submit pull requests for maintainer review ## 📰 Newsletter New to open source? This GitHub tutorial removes the intimidation factor! Learn how to find beginner-friendly projects using GitHub Copilot Chat, evaluate project health, and make your first contribution through the fork-based workflow. Perfect for WordPress developers looking to expand their skills beyond the ecosystem. Key takeaway: Look for projects with "good first issue" labels, active maintenance, and clear contribution guidelines. Start with documentation improvements to get familiar with the process. Resources: [Learn WordPress](https://learn.wordpress.org/), [Developer Docs](https://developer.wordpress.org/), [WP-CLI](https://wp-cli.org/) ## ✅ Action Items #### DevRel - Developer advocacy: Create WordPress-specific open source contribution workshops - Education: Develop curriculum connecting WordPress development to broader OSS ecosystem - Developer experience: Document contribution pathways from WordPress to related projects - Developer marketing: Highlight WordPress contributors in other open source projects - Community management: Facilitate connections between WordPress and broader OSS communities #### Community - Contributors: Create mentorship programs for transitioning from WordPress to general OSS - Maintainers: Establish "good first issue" labeling standards for WordPress projects - Sponsors: Fund stipends for WordPress developers contributing to dependency projects - Ecosystem: Map WordPress's open source dependencies and contribution opportunities #### WordPress - Core: Improve "good first issue" labeling and contributor onboarding documentation - Community: Create pathways from WordPress meetups to broader open source engagement - Training: Develop lessons on contributing to WordPress's upstream dependencies - Documentation: Create guides for WordPress developers entering general OSS projects - Meta: Implement GitHub Copilot Chat integration for finding WordPress contribution opportunities ## 🧪 Hypotheses - WordPress developers with general OSS contribution experience become more effective core contributors - Projects using "good first issue" labels receive higher quality initial contributions than those without - Fork-based contribution workflows reduce friction for new contributors compared to direct repository access - GitHub Copilot Chat recommendations correlate with successful first contributions when filtered properly ### 📊 Methodology - Survey WordPress contributors about their general OSS engagement and skill development - A/B test contribution success rates with and without "good first issue" labels - Compare contribution completion rates between fork-based and direct access workflows - Track conversion rates from Copilot Chat project discovery to successful contributions ### ❓ Questions - How can WordPress better prepare developers for contributing to upstream dependencies like PHP and JavaScript libraries? - What barriers prevent WordPress developers from contributing to general open source projects? - Could WordPress adopt GitHub Copilot Chat integration to help contributors find suitable issues? ### 🔮 Future Research - Analysis of WordPress developer career progression through general OSS contributions - Effectiveness of different onboarding approaches for transitioning platform-specific to general OSS developers - Impact of contribution diversity on long-term WordPress ecosystem health ### 💡 Implications - Practice: WordPress developers should seek OSS contribution opportunities to broaden skills - Policy: WordPress projects should adopt consistent "good first issue" labeling standards - Security: Contributing to upstream dependencies improves WordPress ecosystem security posture - Education: Developer training should include general OSS contribution alongside WordPress-specific skills - Funding: Investment in general OSS contributions by WordPress developers benefits the entire ecosystem ### 🧠 Learning Styles Assessment Reading level estimate: 8th grade (accessible to beginning developers) #### 👀 Visual learners - Present: GitHub interface screenshots, repository navigation examples - Improve: Flowchart of contribution process, visual project evaluation checklist #### 🔊 Aural learners - Present: Video format with clear narration and explanation - Improve: Audio summary of key steps, podcast version for review #### 🗣️ Verbal learners - Present: Clear definitions of technical terms, step-by-step explanations - Improve: Glossary of open source terminology, analogy-based explanations #### 🧩 Kinesthetic learners - Present: Hands-on demonstration of GitHub workflow, practical examples - Improve: Interactive tutorial, guided practice exercises #### 🧠 Logical learners - Present: Systematic project evaluation criteria, logical workflow progression - Improve: Decision trees for project selection, troubleshooting guides #### 🧑‍🤝‍🧑 Social learners - Present: Community aspects of open source, collaboration emphasis - Improve: Group contribution challenges, peer review exercises #### 🧘‍♀️ Solitary learners - Present: Self-directed project discovery, individual contribution focus - Improve: Personal reflection prompts, self-assessment checklists #### 🌿 Naturalistic learners - Present: Open source ecosystem concepts, community growth patterns - Improve: Analogies to natural systems, sustainability perspectives ### 📊 Accessibility Assessment #### Screen reader semantics - Present: Clear heading structure, descriptive link text - Improve: Alt text for GitHub interface screenshots, ARIA labels for interactive elements #### Keyboard navigation - Present: Standard video controls accessible via keyboard - Improve: Transcript with timestamp links, keyboard shortcuts documentation #### Contrast and readability - Present: High contrast GitHub interface examples - Improve: Ensure transcript meets contrast requirements, large text options #### Text resizing and reflow - Present: Video scales appropriately across devices - Improve: Responsive transcript layout, zoom-friendly interface examples #### Media and captions - Present: Video format with clear audio - Improve: Accurate captions, downloadable transcript, audio descriptions #### Forms and interactions - Present: Clear demonstration of GitHub form interactions - Improve: Alternative text-based instructions, error handling examples ### 🌍 DEIB Assessment #### Cultural breadth - Present: Global open source community emphasis, inclusive language - Improve: Examples from diverse geographic regions, multiple language project examples #### Inclusive language - Present: Gender-neutral terminology, welcoming tone - Improve: Avoid assumptions about technical background, define all jargon #### Neurodiversity support - Present: Clear structure, logical progression - Improve: Consistent pacing, visual breaks, attention span accommodation #### Representation - Present: Female presenters in technical roles - Improve: Diverse project examples, varied contributor backgrounds highlighted #### Psychological safety - Present: Encouragement for beginners, mistake normalization - Improve: Explicit community guidelines discussion, harassment reporting information ### ✅ Logical Validity #### Strong reasoning - Deductive strength: Strong logical flow from OSS definition to contribution steps - Inductive strength: Good use of specific examples (VS Code, Gitfolio) to illustrate general principles - Causal reasoning: Clear cause-and-effect in fork workflow explanation - Analogical strength: Effective comparison between closed and open source software #### Fallacies - Appeal to popularity: "At least 100 GitHub stars" oversimplifies project quality assessment - Hasty generalization: Single project example may not represent all contribution experiences #### Tone of voice - Overall tone: Encouraging and supportive, appropriate for beginner audience with clear enthusiasm ### 🛡️ DARVO Analysis - Deny: No denial patterns present - Attack: No attacking language or blame shifting - Reverse victim/offender: No victim/offender dynamics present - Emotional cues and rhetoric: Positive, encouraging tone focused on empowerment and capability building ## 🎯 Conclusion This tutorial successfully demystifies open source contribution for beginners by providing concrete steps and evaluation criteria. The fork-based workflow demonstration offers a safe, practical approach to making first contributions. For WordPress developers, this knowledge creates pathways to contribute to upstream dependencies and broaden technical skills while supporting the broader open source ecosystem that WordPress depends upon. ## 🧱 Refactor Appendix ### 📚 Literature Split Pad ### [H1] GitHub Copilot Chat enables targeted project discovery > [!quote] Getting started with open source contributions for beginners by GitHub via YouTube. Published 2024. Accessed 2024-12-19. > "Search GitHub and narrow down the list to repositories that use the good first issue label and have over 100 stars." AI-powered project filtering reduces search friction for new contributors seeking appropriate entry points. [view highlight](https://youtu.be/WldXhauP024?t=150) #xref #articleseed ID:rw_github_copilot_discovery ### [H2] Good first issue labels signal beginner accessibility > [!quote] Getting started with open source contributions for beginners > "The good first issue label indicates that an issue is beginner-friendly and a great starting point for new contributors." Consistent labeling standards help maintainers communicate contribution accessibility to potential contributors. [view highlight](https://youtu.be/WldXhauP024?t=225) #xref ID:rw_good_first_issue_labels ### [H3] Fork-based workflows protect original repositories > [!quote] Getting started with open source contributions for beginners > "Forks allow us to freely experiment with changes without affecting the original project." Repository forking enables safe contribution experimentation while maintaining project stability. [view highlight](https://youtu.be/WldXhauP024?t=450) #xref ID:rw_fork_workflow_safety --- ### 🔖 Atomic Split Pad (Zettel Candidates) #### [Z1] Project health indicators predict contribution success - Applies to repositories with public development activity and community engagement - Reference: 05:00 timestamp covering evaluation criteria - Links: [[Open-Source-Sustainability]] [[Community-Health-Metrics]] #### [Z2] AI-powered project discovery reduces contribution barriers - Effective when combined with specific filtering --- ## Full Transcript [00:00] Want to contribute to open source but [00:01] don't know how to get started? Well, [00:03] today I'm going to teach you how. By the [00:06] end of this video, you'll know what open [00:08] source is, how to find projects to work [00:10] [music] on, how to read an open source [00:12] repo, and much more. [00:18] Hey, [00:18] >> [music] [00:19] >> I'm Kaniesha and I'm so excited that [00:21] you're here with me today. I have my [00:23] friend Angela here to show you how to [00:24] dig into the world of open source and [00:26] help [music] you make your first open [00:28] source contribution. [00:32] Thanks, Kaniesha. [music] [00:34] Open source software, often abbreviated [00:36] as OSS, refers to software that features [00:39] freely available source code. In [00:41] contrast with closed source software, [00:43] open source software is publicly [00:45] available for anyone to use and build [00:47] upon. This means that all of the work, [00:49] including the code base and [00:51] communication amongst users, is [00:52] available for everyone to see. If you're [00:54] just getting started in the world of [00:56] software development, browsing and [00:58] contributing to open source projects is [00:59] a great way to dip your toes into large [01:01] impactful projects used by countless [01:03] users worldwide. GitHub is the home for [01:06] open source software. So, let me show [01:08] you how you can find projects to [01:09] contribute to. [01:14] Contributing to an open source project [01:15] [music] for the first time can feel [01:17] daunting. I know it did for me. The [01:19] first thing you can do to find projects [01:21] to contribute to is to look for projects [01:23] built in a language that you know. You [01:25] can ask GitHub Copilot Chat to find open [01:27] source projects written in a specific [01:29] programming language that is also [01:31] accepting new contributors. On GitHub, [01:33] click the Copilot icon to open a new [01:35] conversation. Then enter the prompt, [01:38] "I'm looking for a list of open source [01:40] projects written in TypeScript that are [01:42] accepting new contributors." Search [01:43] GitHub and narrow down the list to [01:45] repositories that use the good first [01:47] issue label and have over 100 stars on [01:50] GitHub. Copilot returns a list of [01:52] projects that you can explore filtered [01:54] by the good first issue label. The good [01:56] first issue label indicates that an [01:58] issue is beginner-friendly and a great [02:00] starting point for new contributors. [02:02] This is a great way to find issues in a [02:04] project that you can work on. For [02:06] example, let's say you're interested in [02:08] contributing to the VS Code repository [02:10] and wanted to find good first issues. On [02:13] GitHub, go to the VS Code repo and click [02:15] issues. Then click labels and filter by [02:18] good first issue. [02:20] You'll see a list of open issues [02:22] available for you to work on. To start [02:24] working on an issue, you'll need to read [02:26] the contributors guide in the project's [02:28] repository. So, let's take a look at the [02:30] key things to look for in an open source [02:32] project. Well-maintained open source [02:34] projects have a few things in common. [02:36] They have a well-documented readme with [02:38] installation instructions, a [02:40] contributors guide that explains how to [02:42] contribute, an open source license so we [02:44] know the project is free to use, at [02:46] least 100 GitHub stars so we know it's [02:49] well used in the community, active [02:50] development so we know that a maintainer [02:52] of the open source software will be able [02:54] to review our contributions, and a good [02:57] first issue label to indicate being open [02:59] to new contributors. When you're looking [03:01] for a project to contribute to, these [03:03] are the things you should be looking for [03:04] in the repository. [03:09] Let's take a look [music] at this [03:10] project, Gitfolio, to see if it's a good [03:12] fit. This repository seems like [03:14] something I'd be interested in [03:16] contributing to and it's right up my [03:18] alley in terms of programming languages. [03:20] It also seems to be well-documented and [03:23] there is a contributing.md file that [03:25] shows me how to contribute code to it. [03:28] The last update to the repository was [03:30] recent, so I believe it's actively [03:32] maintained, too. So, let me show you how [03:34] to actually make your first contribution [03:36] to an open source repo. [03:39] For more documentation on finding a good [03:41] open source project, go to [03:42] gh.io/gfiboss. [03:45] >> [music] [03:47] >> Navigate to the home page of the project [03:49] and click the fork button and create a [03:51] new fork. A fork is a copy of a [03:53] repository. We usually use forks for [03:56] open source repository contributions [03:58] because they allow us to freely [03:59] experiment with changes without [04:01] affecting the original project. I'll set [04:03] the owner to be myself and keep the [04:05] repository name and description the [04:07] same. [04:08] Great. Now we have our own copy of the [04:10] repository. In the fork's repo, I'll [04:12] make a quick change to the [04:13] documentation, which was one of the good [04:15] first issues listed in the repository. [04:18] I'll make the change via the GitHub UI, [04:20] but you can choose to clone the repo or [04:22] use a code space. I'll make a change [04:24] here and commit this change to a branch [04:27] in my fork of the repository. [04:29] Now I'll open a pull request to the [04:31] original project using my branch with [04:33] the changes. I'll click compare across [04:36] forks to show my fork's changes compared [04:38] to the original repository. Let's give [04:40] our pull request a quick title and [04:42] description [04:44] and voila! Now it's ready for a [04:46] maintainer to review and hopefully [04:48] approve. Once approved and merged, [04:50] GitHub automatically applies the changes [04:52] from my fork into the main branch of the [04:54] original repository, the official source [04:57] of truth for the code base. [04:59] Thanks so much, Angela, for coming on [05:00] and showing us how to make our first [05:02] open source contribution. We've covered [05:04] a lot, from the definition of open [05:07] source software to finding a good open [05:08] source project to contributing to an [05:11] open source project from a fork. I hope [05:13] it inspires you to contribute to your [05:14] favorite [music] projects. Check out the [05:17] links in the show notes to learn more. I [05:19] hope you found [music] this video [05:20] helpful. Remember to subscribe to [05:21] GitHub's YouTube channel so you don't [05:23] miss any of our future uploads and share [05:25] with a dev friend who could use [music] [05:27] this knowledge. Happy coding.  📄 **Full text:** ![[Full Document Contents/Articles/Getting Started With Open Source Contributions for Beginners.md|Getting Started With Open Source Contributions for Beginners by YouTube]] ## Highlights - so I believe it’s actively maintained, too. So, let me show you how to actually make your first contribution to an open source repo. Kedasha: For more documentation on finding a good open source project, go to gh.io/gfb-oss. Angela: Navigate to the homepage of the project, and click the “Fork” button, and create a new fork. A ‘fork’ is a copy of a repository. We usually use forks for open source repository contributions because they allow us to freely experiment with changes, ([View Highlight](https://read.readwise.io/read/01kre5dphf4bpsrv56fbmtqgtb)) - Tags: 👻 ai highlighted