From ddd4d43966a73efc9526f1752060d3fd206da445 Mon Sep 17 00:00:00 2001 From: Aman Raj <113578582+huamanraj@users.noreply.github.com> Date: Fri, 28 Nov 2025 19:14:03 +0530 Subject: [PATCH 01/36] migrated oss sheets to md --- .../src/app/(main)/dashboard/sheet/page.tsx | 42 +- .../src/app/(main)/sheet/[moduleId]/page.tsx | 370 +++++++----------- apps/web/src/app/api/sheet/modules/route.ts | 57 +++ .../components/sheet/SheetModuleHeader.tsx | 145 +++++++ .../src/components/sheet/SheetSkeleton.tsx | 94 +++++ apps/web/src/data/sheet/content/module-0.md | 102 +++++ apps/web/src/data/sheet/content/module-1.md | 149 +++++++ apps/web/src/data/sheet/content/module-10.md | 15 + apps/web/src/data/sheet/content/module-11.md | 15 + apps/web/src/data/sheet/content/module-12.md | 15 + apps/web/src/data/sheet/content/module-13.md | 15 + apps/web/src/data/sheet/content/module-14.md | 15 + apps/web/src/data/sheet/content/module-15.md | 15 + apps/web/src/data/sheet/content/module-16.md | 15 + apps/web/src/data/sheet/content/module-17.md | 15 + apps/web/src/data/sheet/content/module-18.md | 15 + apps/web/src/data/sheet/content/module-19.md | 15 + apps/web/src/data/sheet/content/module-2.md | 187 +++++++++ apps/web/src/data/sheet/content/module-20.md | 15 + apps/web/src/data/sheet/content/module-21.md | 15 + apps/web/src/data/sheet/content/module-22.md | 15 + apps/web/src/data/sheet/content/module-23.md | 15 + apps/web/src/data/sheet/content/module-24.md | 15 + apps/web/src/data/sheet/content/module-25.md | 15 + apps/web/src/data/sheet/content/module-26.md | 15 + apps/web/src/data/sheet/content/module-27.md | 15 + apps/web/src/data/sheet/content/module-28.md | 15 + apps/web/src/data/sheet/content/module-29.md | 10 + apps/web/src/data/sheet/content/module-3.md | 138 +++++++ apps/web/src/data/sheet/content/module-30.md | 10 + apps/web/src/data/sheet/content/module-31.md | 10 + apps/web/src/data/sheet/content/module-4.md | 12 + apps/web/src/data/sheet/content/module-5.md | 176 +++++++++ apps/web/src/data/sheet/content/module-6.md | 174 ++++++++ apps/web/src/data/sheet/content/module-7.md | 15 + apps/web/src/data/sheet/content/module-8.md | 10 + apps/web/src/data/sheet/content/module-9.md | 134 +++++++ apps/web/src/data/sheet/index.ts | 4 +- apps/web/src/data/sheet/module-0.ts | 113 ------ apps/web/src/data/sheet/module-1.ts | 157 -------- apps/web/src/data/sheet/module-10.ts | 12 - apps/web/src/data/sheet/module-11.ts | 12 - apps/web/src/data/sheet/module-12.ts | 12 - apps/web/src/data/sheet/module-13.ts | 12 - apps/web/src/data/sheet/module-14.ts | 12 - apps/web/src/data/sheet/module-15.ts | 12 - apps/web/src/data/sheet/module-16.ts | 12 - apps/web/src/data/sheet/module-17.ts | 12 - apps/web/src/data/sheet/module-18.ts | 12 - apps/web/src/data/sheet/module-19.ts | 12 - apps/web/src/data/sheet/module-2.ts | 189 --------- apps/web/src/data/sheet/module-20.ts | 12 - apps/web/src/data/sheet/module-21.ts | 12 - apps/web/src/data/sheet/module-22.ts | 12 - apps/web/src/data/sheet/module-23.ts | 12 - apps/web/src/data/sheet/module-24.ts | 12 - apps/web/src/data/sheet/module-25.ts | 12 - apps/web/src/data/sheet/module-26.ts | 12 - apps/web/src/data/sheet/module-27.ts | 12 - apps/web/src/data/sheet/module-28.ts | 12 - apps/web/src/data/sheet/module-29.ts | 12 - apps/web/src/data/sheet/module-3.ts | 154 -------- apps/web/src/data/sheet/module-30.ts | 12 - apps/web/src/data/sheet/module-31.ts | 12 - apps/web/src/data/sheet/module-4.ts | 18 - apps/web/src/data/sheet/module-5.ts | 203 ---------- apps/web/src/data/sheet/module-6.ts | 194 --------- apps/web/src/data/sheet/module-7.ts | 24 -- apps/web/src/data/sheet/module-8.ts | 12 - apps/web/src/data/sheet/module-9.ts | 187 --------- apps/web/src/data/sheet/sheet.ts | 133 ++++--- apps/web/src/data/sheet/types.ts | 2 +- 72 files changed, 1946 insertions(+), 1828 deletions(-) create mode 100644 apps/web/src/app/api/sheet/modules/route.ts create mode 100644 apps/web/src/components/sheet/SheetModuleHeader.tsx create mode 100644 apps/web/src/components/sheet/SheetSkeleton.tsx create mode 100644 apps/web/src/data/sheet/content/module-0.md create mode 100644 apps/web/src/data/sheet/content/module-1.md create mode 100644 apps/web/src/data/sheet/content/module-10.md create mode 100644 apps/web/src/data/sheet/content/module-11.md create mode 100644 apps/web/src/data/sheet/content/module-12.md create mode 100644 apps/web/src/data/sheet/content/module-13.md create mode 100644 apps/web/src/data/sheet/content/module-14.md create mode 100644 apps/web/src/data/sheet/content/module-15.md create mode 100644 apps/web/src/data/sheet/content/module-16.md create mode 100644 apps/web/src/data/sheet/content/module-17.md create mode 100644 apps/web/src/data/sheet/content/module-18.md create mode 100644 apps/web/src/data/sheet/content/module-19.md create mode 100644 apps/web/src/data/sheet/content/module-2.md create mode 100644 apps/web/src/data/sheet/content/module-20.md create mode 100644 apps/web/src/data/sheet/content/module-21.md create mode 100644 apps/web/src/data/sheet/content/module-22.md create mode 100644 apps/web/src/data/sheet/content/module-23.md create mode 100644 apps/web/src/data/sheet/content/module-24.md create mode 100644 apps/web/src/data/sheet/content/module-25.md create mode 100644 apps/web/src/data/sheet/content/module-26.md create mode 100644 apps/web/src/data/sheet/content/module-27.md create mode 100644 apps/web/src/data/sheet/content/module-28.md create mode 100644 apps/web/src/data/sheet/content/module-29.md create mode 100644 apps/web/src/data/sheet/content/module-3.md create mode 100644 apps/web/src/data/sheet/content/module-30.md create mode 100644 apps/web/src/data/sheet/content/module-31.md create mode 100644 apps/web/src/data/sheet/content/module-4.md create mode 100644 apps/web/src/data/sheet/content/module-5.md create mode 100644 apps/web/src/data/sheet/content/module-6.md create mode 100644 apps/web/src/data/sheet/content/module-7.md create mode 100644 apps/web/src/data/sheet/content/module-8.md create mode 100644 apps/web/src/data/sheet/content/module-9.md delete mode 100644 apps/web/src/data/sheet/module-0.ts delete mode 100644 apps/web/src/data/sheet/module-1.ts delete mode 100644 apps/web/src/data/sheet/module-10.ts delete mode 100644 apps/web/src/data/sheet/module-11.ts delete mode 100644 apps/web/src/data/sheet/module-12.ts delete mode 100644 apps/web/src/data/sheet/module-13.ts delete mode 100644 apps/web/src/data/sheet/module-14.ts delete mode 100644 apps/web/src/data/sheet/module-15.ts delete mode 100644 apps/web/src/data/sheet/module-16.ts delete mode 100644 apps/web/src/data/sheet/module-17.ts delete mode 100644 apps/web/src/data/sheet/module-18.ts delete mode 100644 apps/web/src/data/sheet/module-19.ts delete mode 100644 apps/web/src/data/sheet/module-2.ts delete mode 100644 apps/web/src/data/sheet/module-20.ts delete mode 100644 apps/web/src/data/sheet/module-21.ts delete mode 100644 apps/web/src/data/sheet/module-22.ts delete mode 100644 apps/web/src/data/sheet/module-23.ts delete mode 100644 apps/web/src/data/sheet/module-24.ts delete mode 100644 apps/web/src/data/sheet/module-25.ts delete mode 100644 apps/web/src/data/sheet/module-26.ts delete mode 100644 apps/web/src/data/sheet/module-27.ts delete mode 100644 apps/web/src/data/sheet/module-28.ts delete mode 100644 apps/web/src/data/sheet/module-29.ts delete mode 100644 apps/web/src/data/sheet/module-3.ts delete mode 100644 apps/web/src/data/sheet/module-30.ts delete mode 100644 apps/web/src/data/sheet/module-31.ts delete mode 100644 apps/web/src/data/sheet/module-4.ts delete mode 100644 apps/web/src/data/sheet/module-5.ts delete mode 100644 apps/web/src/data/sheet/module-6.ts delete mode 100644 apps/web/src/data/sheet/module-7.ts delete mode 100644 apps/web/src/data/sheet/module-8.ts delete mode 100644 apps/web/src/data/sheet/module-9.ts diff --git a/apps/web/src/app/(main)/dashboard/sheet/page.tsx b/apps/web/src/app/(main)/dashboard/sheet/page.tsx index df6cde01..eb5df48d 100644 --- a/apps/web/src/app/(main)/dashboard/sheet/page.tsx +++ b/apps/web/src/app/(main)/dashboard/sheet/page.tsx @@ -3,7 +3,6 @@ import { useState, useEffect, useMemo, useCallback, memo } from "react"; import { useSession } from "next-auth/react"; import { trpc } from "@/lib/trpc"; -import { sheetModules } from "@/data/sheet"; import type { SheetModule } from "@/data/sheet"; import { Table, @@ -22,6 +21,7 @@ import { OpensoxProBadge } from "@/components/sheet/OpensoxProBadge"; import { ProgressBar } from "@/components/sheet/ProgressBar"; import { ActiveTag } from "@/components/ui/ActiveTag"; import { useSubscription } from "@/hooks/useSubscription"; +import { SheetSkeleton } from "@/components/sheet/SheetSkeleton"; const tableColumns = [ "S.No", @@ -39,7 +39,7 @@ const SheetTableRow = memo(function SheetTableRow({ onCheckboxChange, isPaidUser, }: { - module: SheetModule; + module: Omit; index: number; isCompleted: boolean; onCheckboxChange: (moduleId: string, checked: boolean) => void; @@ -129,14 +129,35 @@ const SheetTableRow = memo(function SheetTableRow({ ); }); - export default function SheetPage() { const { data: session, status } = useSession(); const { isPaidUser } = useSubscription(); const [completedSteps, setCompletedSteps] = useState([]); const [copied, setCopied] = useState(false); + const [sheetModules, setSheetModules] = useState< + Omit[] + >([]); + const [isLoadingModules, setIsLoadingModules] = useState(true); const utils = trpc.useUtils(); + // fetch modules metadata from api + useEffect(() => { + async function fetchModules() { + try { + const response = await fetch("/api/sheet/modules"); + if (response.ok) { + const modules = await response.json(); + setSheetModules(modules); + } + } catch (error) { + console.error("failed to fetch modules:", error); + } finally { + setIsLoadingModules(false); + } + } + fetchModules(); + }, []); + // TypeScript has difficulty narrowing TRPC procedure union types. // These procedures are correctly typed at runtime (query vs mutation). const getCompletedStepsProcedure = trpc.user @@ -215,7 +236,7 @@ export default function SheetPage() { ); // Memoize computed values - const totalModules = useMemo(() => sheetModules.length, []); + const totalModules = useMemo(() => sheetModules.length, [sheetModules]); const completedCount = useMemo(() => completedSteps.length, [completedSteps]); // Memoize download handler @@ -299,7 +320,7 @@ export default function SheetPage() { setTimeout(() => { printWindow.print(); }, 250); - }, [completedCount, totalModules, completedSteps]); + }, [completedCount, totalModules, completedSteps, sheetModules]); // Memoize share handler const handleShare = useCallback(async () => { @@ -313,16 +334,11 @@ export default function SheetPage() { } }, []); - // Show loading only if we're actually loading session OR steps - const isLoading = - (status === "loading" || isLoadingSteps) && !completedSteps.length; + // Show loading only if we're actually loading session OR steps OR modules + const isLoading = status === "loading" || isLoadingSteps || isLoadingModules; if (isLoading) { - return ( -
-

Loading...

-
- ); + return ; } return ( diff --git a/apps/web/src/app/(main)/sheet/[moduleId]/page.tsx b/apps/web/src/app/(main)/sheet/[moduleId]/page.tsx index 74289235..da2a457c 100644 --- a/apps/web/src/app/(main)/sheet/[moduleId]/page.tsx +++ b/apps/web/src/app/(main)/sheet/[moduleId]/page.tsx @@ -1,243 +1,153 @@ -"use client"; +import { notFound } from "next/navigation"; +import { getSheetModules } from "@/data/sheet"; +import { SheetModuleHeader } from "@/components/sheet/SheetModuleHeader"; -import { notFound, useParams } from "next/navigation"; -import { sheetModules } from "@/data/sheet"; -import Link from "next/link"; -import { ArrowLeft, Download, Share2, Check } from "lucide-react"; -import { Badge } from "@/components/ui/badge"; -import { useState, useMemo, useEffect } from "react"; - -// Cache DOMPurify instance once loaded -let DOMPurifyInstance: typeof import("dompurify").default | null = null; -let DOMPurifyPromise: Promise | null = null; - -// Helper function to get DOMPurify instance - loads asynchronously on first call -const getDOMPurify = async (): Promise< - typeof import("dompurify").default | null -> => { - if (typeof window === "undefined") { - return null; - } - - if (DOMPurifyInstance) { - return DOMPurifyInstance; - } - - if (DOMPurifyPromise) { - return DOMPurifyPromise; - } - - DOMPurifyPromise = import("dompurify").then((mod) => { - DOMPurifyInstance = mod.default; - return DOMPurifyInstance; - }); - - return DOMPurifyPromise; -}; - -// Synchronous sanitize function - returns unsanitized if DOMPurify not loaded yet -const sanitizeHTMLSync = ( - html: string, - options?: { ALLOWED_TAGS: string[] } -): string => { - if (typeof window === "undefined") { - return html; - } - - if (!DOMPurifyInstance) { - // Trigger async load but return unsanitized for now - getDOMPurify(); - return html; - } - - if (options) { - return DOMPurifyInstance.sanitize(html, options); - } - return DOMPurifyInstance.sanitize(html); -}; - -export default function ModuleDocPage() { - const params = useParams(); - const moduleId = params?.moduleId as string; - const [copied, setCopied] = useState(false); - const [isDOMPurifyLoaded, setIsDOMPurifyLoaded] = useState(false); - - const currentModule = sheetModules.find((m) => m.id === moduleId); - - // Load DOMPurify on mount - useEffect(() => { - if (typeof window !== "undefined") { - getDOMPurify().then(() => { - setIsDOMPurifyLoaded(true); - }); - } - }, []); - - const sanitizedDocContent = useMemo(() => { - if (!currentModule?.docContent) return ""; - return sanitizeHTMLSync(currentModule.docContent); - }, [currentModule?.docContent, isDOMPurifyLoaded]); - - const handleDownloadPDF = () => { - if (!currentModule) return; - - const printWindow = window.open("", "_blank"); - if (!printWindow) return; - - const sanitizedModuleName = sanitizeHTMLSync(currentModule.name, { - ALLOWED_TAGS: [], - }); - - const htmlContent = ` - - - - ${sanitizedModuleName} - 30 days of Open Source sheet - - - -

${sanitizedModuleName}

-
- ${sanitizedDocContent} -
- - - `; - - printWindow.document.write(htmlContent); - printWindow.document.close(); - printWindow.focus(); - setTimeout(() => { - printWindow.print(); - }, 250); - }; +interface PageProps { + params: Promise<{ moduleId: string }>; +} - const handleShare = async () => { - const url = window.location.href; - try { - await navigator.clipboard.writeText(url); - setCopied(true); - setTimeout(() => setCopied(false), 2000); - } catch (clipboardErr) { - console.error("Failed to copy:", clipboardErr); - } - }; +export default async function SheetModulePage({ params }: PageProps) { + const { moduleId } = await params; + const sheetModules = getSheetModules(); + const sheetModule = sheetModules.find((m) => m.id === moduleId); - if (!currentModule) { + if (!sheetModule) { notFound(); } - if (currentModule.comingSoon) { - return ( -
-
-
- - - Back to Sheet - -

- {currentModule.name} -

-
- -
- - Soon - -

- This module is coming very soon. Stay tuned! -

-
-
-
- ); - } - return ( -
-
- {/* Header with back button and actions */} -
-
- - - Back to Sheet - -
- {copied && ( - - - Copied - + <> + + + +

${moduleName}

+
+ ${docContent} +
+
+

Generated from Open Source Sheet • opensox.ai

+
+ + + `; + + printWindow.document.write(htmlContent); + printWindow.document.close(); + printWindow.focus(); + setTimeout(() => { + printWindow.print(); + }, 250); + }; + + return ( +
+ + + Back to Sheet + + +
+ {copied && ( + + + Copied + + )} + + +
+
+ ); +} diff --git a/apps/web/src/components/sheet/SheetSkeleton.tsx b/apps/web/src/components/sheet/SheetSkeleton.tsx new file mode 100644 index 00000000..66dd4e7a --- /dev/null +++ b/apps/web/src/components/sheet/SheetSkeleton.tsx @@ -0,0 +1,94 @@ +import { Skeleton } from "@/components/ui/skeleton"; +import { + Table, + TableBody, + TableCell, + TableHead, + TableHeader, + TableRow, +} from "@/components/ui/table"; + +export function SheetSkeleton() { + return ( +
+
+
+ + +
+
+ + +
+
+
+ {/* Progress Bar Skeleton */} +
+
+ + +
+ +
+ + {/* Quote Skeleton */} +
+ +
+ + {/* Table Skeleton */} +
+ + + + {[1, 2, 3, 4, 5, 6].map((i) => ( + + + + ))} + + + + {Array.from({ length: 10 }).map((_, i) => ( + + + + + + + + + + + + + + + + + + + + + ))} + +
+
+
+
+ ); +} diff --git a/apps/web/src/data/sheet/content/module-0.md b/apps/web/src/data/sheet/content/module-0.md new file mode 100644 index 00000000..8994e40d --- /dev/null +++ b/apps/web/src/data/sheet/content/module-0.md @@ -0,0 +1,102 @@ +--- +id: "module-0" +name: "Introduction & Announcement" +videoUrl: "https://youtu.be/ctXaTeeUdRE" +comingSoon: false +--- + +in this module ive yapped two things: some of my context and announcement of OPEN SOURCE series. + +### some of my context: + +so my name is Ajeet and these are some of my achievements so far: + +![Ajeet's work screenshot](/images/module-1.webp) + +im telling you this not to show off but to make a point that what we can achieve through OPEN SOURCE in 3 years. + +especially in my case, [the background](https://x.com/ajeetunc/status/1989355142081065468?s=20) i come from and the college i come from achieving all of this in 3 years was i mean at least for me was next to impossible because i had never thought that i will ever be able to do all of that. + +if i be honest with you then my initial plan was to get around 4 to 5 LPA job at any company because at that time i was very desperate to get into tech and i was thinking that okay i will just get into tech and then i will go for something bigger. + +so that was my plan. but fortunately the 4 LPA thing i was able to get it in my second year itself as a stipend of my first internship and all of this was possible through OPEN SOURCE. + +that was the best thing that happened to me. i was able to contribute to OPEN SOURCE and i was able to connect with some really cool people who introduced me to some organizations and to some really cool open-source projects that led me to some really great opportunities including an interview at lovable. + +so i will tell you more about this lovable thing later in this module. + +these are only the direct results that i got from OPEN SOURCE but there are also some indirect results that i got and in those indirect results one is like connections and recognition. + +so when i started contributing to open-source people started recognizing me, i mean people started kind of making a connection and i was able to make connection with maintainers and CTOs and even CEOs of couple of companies even VC backed companies. + +so those connections really help me whenever i either want to get an interview or want something else. then pinging those people who i already know makes it a lot easier to get something. + +and the second thing i got from OPEN SOURCE and that is a strong profile. so i still know that there was a time when whenever i used to apply for an opening then there used to be 100% chances of rejection because at one point i was getting rejected from almost any opening. + +then i shifted my focus from applying to started contributing to OPEN SOURCE and for around one and a half year i just contributed to OPEN SOURCE and all the experience that i got from OPEN SOURCE i mentioned in my resume and my portfolio and as a result of that i started noticing really great results from the openings like most of the times my profile started getting selected. + +and also once i send my profile to the founder of lovable and it was selected and i was able to land an interview at lovable. + +![Ajeet's work screenshot](/images/lv-1.webp) + +so the strong portfolio and strong profile is the second indirect benefit of OPEN SOURCE. + +and the third indirect benefit of OPEN SOURCE is that whenever you see an opening job opening these days 99.99% of the times you will see a line there that "if you have done OPEN SOURCE and if you have contributed to OPEN SOURCE then it's a plus point" and most of the time i get that plus point because it really makes your profile unique when you have already contributed to some OPEN SOURCE companies especially the competitors of the company that you are applying for. + +so once i had applied for a payment company and fortunately i had already made contributions to a similar payment company that was based in Europe. so my resume was shortlisted and i was able to get interview really fast just because of those OPEN SOURCE contributions that i had made to that payment company. + +![Ajeet's work screenshot](/images/ptm.webp) + +overall i mean my whole point is that the ROI that you get from OPEN SOURCE is not limited. so you won't even believe where OPEN SOURCE can take you in the next one or two years. + +but all of this journey, all of this open-source journey so far was not easy to be honest because especially in my case when i had no senior or not someone to whom i can go and ask something there was always a problem of doubts. there was always a problem of not having a human feedback. + +so everything and anything ive learned so far was a is a result of observing things and observing people like how do they do it and how they are making contributions and how are they tackling issues. + +so when we contribute to OPEN SOURCE there is not only one problem that we face there are a lot of problems that we have to go through and couple of those problems are like not able to find the project. + +so that is the first and the one of the most complex problem when we contribute to OPEN SOURCE. so because let's say as a new contributor we don't even know like which project we have to contribute to. + +so but to be honest initially it doesn't matter much like you can contribute to any OPEN SOURCE project depending on your tech stack or on your preferences but again it's still a hustle kind of thing because we are not able to land on a good project. + +so that is why i had created [opensox.ai](https://www.opensox.ai/) and i'm still working on that. but that was the first problem and there was a second problem as well. + +when we are very new and when we contribute to repositories that are pretty famous and very complex code bases then we face a lot of competition or a lot of saturation because there are a lot of people who are making contributions parallelly and there we have to make contributions as a beginner. + +so it creates a lot of problems for us because we are not even able to fix smaller issues because for each issue there are a lot of people already competing there. so that is the second problem. + +there is also a third problem and that is getting overwhelmed. + +so basically when we are new and when we have no experience to OPEN SOURCE we easily get overwhelmed by all of these things because there are a lot of tools a lot of practices that we have to follow and also there are a lot of things that we have to know be it technology or be it patterns that that particular organization follow and also each organization or each OPEN SOURCE projects has its own technologies has its own paradigms of contributing the code to it. + +so it makes it really hard for a new contributor to start contributing. it takes a lot of months for them to get started with OPEN SOURCE. + +there is one more very painful problem that we face while contributing to OPEN SOURCE and that is not getting attention of the maintainers. so imagine you work on something for weeks and when you raise a PR then there is no one to look to that look at that PR or to review that PR. + +so that's really painful and in most of the cases it's not the mistake of maintainers it's the mistake of contributors. so either they have chosen a wrong issue or something that's not important or a thousand reasons by which it can happen you may not get the attention that you need. + +so it is really demotivating and disappointing when you work on something for so long and no one look at it. so these are the these are kind of problems that most of the people face when they are new to OPEN SOURCE. + +so to document everything what ive learned through open-source i'm going to create an open-source series of around 30 to 40 modules and in this series i'm going to explain everything in details from finding projects to finding opportunities in OPEN SOURCE companies or organizations. + +there are two reasons why this series contains 30 plus modules. number one, it this series is for absolute beginners or the people who face problems while contributing to OPEN SOURCE. + +and the second reason is there are a lot of smaller details that matters a lot but most of the times it is either ignored by people who already teach on YouTube or it is mostly unheard it is not documented. + +so that is why this series is going to be long enough to contain everything that is important for a beginner or the person who is facing problems while contributing to OPEN SOURCE. + +this is what this series will contain: + +![Ajeet's work screenshot](/images/sheet-1.webp) + +![Ajeet's work screenshot](/images/sheet-2.webp) + +also there are going to be couple of bonus modules or couple of ad hoc modules. so if i for forget something in this list then i will cover all of that in these bonus modules + +### todos: + +- [ ] make a firm decision to do OPEN SOURCE +- [ ] share this series with others :) +- [ ] rest todos in the next module + +finally, that's all in this module. i'll yap more in the next module. take care. diff --git a/apps/web/src/data/sheet/content/module-1.md b/apps/web/src/data/sheet/content/module-1.md new file mode 100644 index 00000000..42eb71ad --- /dev/null +++ b/apps/web/src/data/sheet/content/module-1.md @@ -0,0 +1,149 @@ +--- +id: "module-1" +name: "Things to know before jumping to Open Source" +videoUrl: "https://youtu.be/PHKy2izX2Hs?si=loy2Wy_iGwYMKPk7" +comingSoon: false +--- + +hey, im back. in this module we're gonna talk about what you should know before contributing to open source. + +### quick disclaimer + +everything i say here is from my personal experience. it's not some rulebook or law. i might be wrong in a few places, and you might have a better take on things. so feel free to pick whatever works best for you. + +### first things first — know your goals from open source + +everyone joins with different reasons. some wanna learn, some want a job or internship, some are in it for gsoc or bounties, and some just do it for fun. but behind all that, the real goal is to make _impactful contributions_. + +whether it's learning, landing a gig, or just enjoying the process — everything eventually comes down to one thing: making meaningful, high-impact contributions. that's what truly moves the needle. + +### mindset while contributing to open source + +when it comes to open source, remember — it's not always about code. + +people usually think contributors only write code, but that's not true. a good contributor isn't just someone pushing commits; they're someone who _understands the product_, keeps the docs clean, helps others, reviews prs, and improves the overall project vibe. + +so yeah, code matters — but contribution goes way beyond that. even if you're mainly into coding, try helping out in other areas too. things like improving docs, giving feedback on prs, or helping someone debug can be super valuable. + +### quality > quantity + start small + ego + tracking + +**quality always beats quantity** — that's one of my favorite philosophies. + +you can raise two prs instead of ten, but if they're high-quality and impactful, that's what really counts. don't chase numbers, chase impact. that's what helps you hit your goals — whether it's learning, landing gigs, or just building credibility. + +in the beginning, it's totally fine to just focus on getting started and getting your first pr merged. once you're comfortable, start paying attention to quality — learn what makes an issue truly valuable or impactful. + +also, **start small**. most beginners try to take on massive issues and then get stuck or burned out. pick small, easy tasks first, build confidence, and then slowly move to the bigger stuff. + +and please — **leave your ego at the door**. sometimes your pr won't get merged, or someone else might propose a better solution. that's okay. open source isn't about proving you're the best; it's about learning, improving, and growing together. + +finally, **track everything**. open source has a lot of moving parts — issues, prs, reviews, updates. if you don't track them properly, you'll get overwhelmed. below is a simple doc i use to keep things organized, the main idea is: stay structured so you can move fast without burning out. + +![Ajeet's work screenshot](/images/doc.webp) + +### hard things have less competition + confidence + compounding + +here's a cool mindset shift — **hard things have less competition**. + +you'll notice this once you start contributing: easy issues always have a crowd. everyone's like "assign this to me!" meanwhile, the complex ones just sit there untouched. that's your time to shine. when you pick those tougher tasks, you stand out fast. + +and don't fall into the comparison trap. it's easy to feel small when you see people with years of experience contributing. but remember — everyone starts somewhere. even the best maintainers were beginners once. so don't let someone's fancy green github chart hypnotize you. focus on your lane. + +**open source compounds over time**. the more you contribute, the faster you get. your first few prs might take weeks, but later you'll do the same kind of work in days. every hard issue you solve today makes you 10x faster tomorrow. that's why staying consistent matters — because open source has crazy long-term roi if you just stick with it. + +### don't chase perfection + blind confidence + pr/issue closures + +**don't chase perfection — just ship it**. + +a lot of people waste time endlessly tweaking their prs or adding "one more improvement." instead, once your code works, passes tests, and meets the requirements, just raise the pr. let the maintainer review it. done is better than perfect. + +also, **blind confidence helps** — especially when you're starting out. when i first got into open source, i took on a backend issue written in python even though i only knew typescript back then. i just said "yeah i'll fix it," learned on the go, and somehow pulled it off. sometimes you need that slightly overconfident push to grow. + +and if your pr or issue gets closed, chill. it happens to everyone. maybe the maintainer had a fight with his wife, or your idea didn't fit the project. no big deal. open source is full of different opinions — just respect that and move on. what matters is you tried and learned. + +### aura boosters — being proactive, attention, and smart communication + +to level up your aura in open source, be _hyper proactive_ — but not annoying. + +there are two types of people: the ones who _talk_ about doing things, and the ones who _just do it_. always be the doer. instead of telling the maintainer, "i'll do this, i'll do that," just try it. make a quick proof-of-concept, raise a draft pr, show results, and then ask for feedback. that's how you earn respect fast. + +remember — **maintainer attention is limited**. big projects have tons of contributors and issues, so use their time wisely. before asking anything, see if google, chatgpt, or docs can solve it. 90% of answers already exist somewhere. only ping the maintainer when you've tried everything and still can't figure it out. + +and when you do ask, **ask smart**. frame your question clearly, short, and to the point. show that you've already done your homework. people are way more likely to reply if your message is crisp and easy to understand. this rule also works great for cold dms and emails — clarity gets attention. + +here's a dm i did to one of a guy i appreciate most and got his reply: + +![Ajeet's work screenshot](/images/dm.webp) + +### homework before asking + using the project + helping others + +**before you ask for help, always do your homework**. + +read the issue carefully, understand its context, and explore the repo a bit. in open source, no one's gonna spoon-feed you — you've gotta figure things out yourself first. + +one of the best hacks to understand a project deeply is to _use it yourself_. if it's a docs tool, use it to write your docs. if it's a web app, play around with it. when you see it from a user's perspective, you spot bugs, missing features, and potential improvements easily. that's how you start thinking like a product contributor, not just a coder. + +and **help others**. that's literally the spirit of open source — you help someone today, someone else helps you tomorrow. plus, teaching someone (even through text) forces you to understand things better yourself. people also notice contributors who help others — it naturally builds your reputation. + +### code of conduct + knowing basics + patience + tracker doc + +**read the code of conduct — seriously**. + +almost every open source project has one, but barely anyone reads it. it usually explains how to contribute, whether you need permission to start on an issue, and what coding practices the project follows. it also covers simple but crucial stuff like being respectful, not spamming, or posting rude comments. + +taking 10–20 minutes to read it already puts you ahead of 80% of contributors. most skip it because it looks boring, but it actually gives you the rules of the game. + +next — **know the basics**. + +open source isn't for "absolute" beginners. you don't need to be a pro, but you should at least know how to fork and clone a repo, use branches, handle merge conflicts, push code, and keep things in sync. also, learn basic git terms like _origin_, _upstream_, _fetch_, and _rebase_. it won't take more than a day. + +and yeah — **have patience**. + +maintainers are busy. sometimes your pr might take days or even weeks to get reviewed. that's normal. while waiting, don't just sit idle — use that time to learn new stuff or pick another issue. + +to stay organized, maintain a simple tracker doc. i use one with four sections — + +1. **to raise** (issues you plan to raise) +2. **to work on** (issues you've picked) +3. **in progress** (what you're currently coding) +4. **to review / get merged** (prs waiting for review) + +### low / no aura things to avoid — the don'ts + +alright, let's talk about what _not_ to do — the stuff that kills your aura fast. + +**first — don't overping maintainers**. their time is super limited, so avoid bothering them for small or googleable stuff. i've seen people spam maintainers like "can you assign me this issue?" again and again. sometimes, they even ping on a pull request instead of an issue 💀. don't be that person. + +**second — no personal dms**. messaging maintainers privately without permission is a big no. keep everything public unless they _explicitly_ ask you to dm. open source thrives on transparency. + +**third — don't pull others down**. if someone's already working on an issue, don't try to snatch it or comment things like "can i take this?" unless they say they're leaving it. just move to another issue. + +**fourth — don't move slow**. once you take up an issue, stay active. being slow makes you forget context and gives the impression you're not serious. use your waiting time to learn or find new bugs — stay in motion. + +**fifth — always follow the code of conduct**. it's not optional. i once saw someone threaten a gsoc maintainer because they got rejected — total red flag. don't ever do that. same goes for stealing someone's work — you can learn from others' code, but don't copy-paste their prs or proposals. that'll destroy your credibility instantly. + +**lastly — keep your promises**. if you say you'll fix an issue, actually do it. missing deadlines again and again makes maintainers lose trust. start small, prove reliability first, and then go for bigger features once you're confident. + +### beginner's dilemma + closing thoughts + +when you're new to open source, you'll face what i call the _beginner's dilemma_. + +you'll ask yourself things like — + +- what tools or tech do i need to know? +- how do i find good issues to work on? +- how do i pick the right project? +- why is setting it up locally so damn hard? +- why does everything feel so complex? + +and trust me — everyone goes through this. it's normal to feel stuck, lost, or even dumb sometimes. i've been there too. but that's exactly how you grow. every small win — cloning your first repo, fixing your first bug, getting your first pr merged — adds up fast. + +we'll dive deeper into all these beginner problems in upcoming modules — how to find beginner-friendly issues, how to pick projects that match your tech stack, how to set things up quickly, and how to stay consistent without burning out. + +### todos: + +- [ ] keep everything ive explained earlier in mind + +so yeah, that's all for this one. this module was more of a mindset and theory piece, but honestly, these are the things most people skip — and end up making mistakes that cost them their aura. + +if you vibed with it, share it with other (coz i dont have a marketing budget), and this is ajeetunc. see you in the next module diff --git a/apps/web/src/data/sheet/content/module-10.md b/apps/web/src/data/sheet/content/module-10.md new file mode 100644 index 00000000..4df3357b --- /dev/null +++ b/apps/web/src/data/sheet/content/module-10.md @@ -0,0 +1,15 @@ +--- +id: "module-10" +name: "Live fix/implement the issue - 2" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 2 + +Live fix/implement the issue - 2 + +Second live session on fixing and implementing an issue in an OPEN SOURCE project. + +Second live session on fixing and implementing an issue in an OPEN SOURCE project. + diff --git a/apps/web/src/data/sheet/content/module-11.md b/apps/web/src/data/sheet/content/module-11.md new file mode 100644 index 00000000..51bba398 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-11.md @@ -0,0 +1,15 @@ +--- +id: "module-11" +name: "Live fix/implement the issue - 3" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 3 + +Live fix/implement the issue - 3 + +Third live session on fixing and implementing an issue in an OPEN SOURCE project. + +Third live session on fixing and implementing an issue in an OPEN SOURCE project. + diff --git a/apps/web/src/data/sheet/content/module-12.md b/apps/web/src/data/sheet/content/module-12.md new file mode 100644 index 00000000..df721058 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-12.md @@ -0,0 +1,15 @@ +--- +id: "module-12" +name: "Live fix/implement the issue - 4" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 4 + +Live fix/implement the issue - 4 + +Fourth live session on fixing and implementing an issue in an OPEN SOURCE project. + +Fourth live session on fixing and implementing an issue in an OPEN SOURCE project. + diff --git a/apps/web/src/data/sheet/content/module-13.md b/apps/web/src/data/sheet/content/module-13.md new file mode 100644 index 00000000..5b06711c --- /dev/null +++ b/apps/web/src/data/sheet/content/module-13.md @@ -0,0 +1,15 @@ +--- +id: "module-13" +name: "Raise PRs and fix the reviews" +videoUrl: "" +comingSoon: true +--- + +Raise PRs and fix the reviews + +Raise PRs and fix the reviews + +Learn how to create pull requests and effectively address review comments from maintainers. + +Learn how to create pull requests and effectively address review comments from maintainers. + diff --git a/apps/web/src/data/sheet/content/module-14.md b/apps/web/src/data/sheet/content/module-14.md new file mode 100644 index 00000000..b75f36d6 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-14.md @@ -0,0 +1,15 @@ +--- +id: "module-14" +name: "How to tackle competition in saturated orgs?" +videoUrl: "" +comingSoon: true +--- + +How to tackle competition in saturated orgs? + +How to tackle competition in saturated orgs? + +Strategies for standing out and getting your contributions noticed in highly competitive OPEN SOURCE organizations. + +Strategies for standing out and getting your contributions noticed in highly competitive OPEN SOURCE organizations. + diff --git a/apps/web/src/data/sheet/content/module-15.md b/apps/web/src/data/sheet/content/module-15.md new file mode 100644 index 00000000..8c211499 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-15.md @@ -0,0 +1,15 @@ +--- +id: "module-15" +name: "Get/pick your second issue assigned (medium)" +videoUrl: "" +comingSoon: true +--- + +Get/pick your second issue assigned (medium) + +Get/pick your second issue assigned (medium) + +Learn how to get your second issue assigned, focusing on medium difficulty issues. + +Learn how to get your second issue assigned, focusing on medium difficulty issues. + diff --git a/apps/web/src/data/sheet/content/module-16.md b/apps/web/src/data/sheet/content/module-16.md new file mode 100644 index 00000000..09dc0020 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-16.md @@ -0,0 +1,15 @@ +--- +id: "module-16" +name: "How to plan/discuss with maintainers?" +videoUrl: "" +comingSoon: true +--- + +How to plan/discuss with maintainers? + +How to plan/discuss with maintainers? + +Best practices for communicating and planning with project maintainers before starting work on issues. + +Best practices for communicating and planning with project maintainers before starting work on issues. + diff --git a/apps/web/src/data/sheet/content/module-17.md b/apps/web/src/data/sheet/content/module-17.md new file mode 100644 index 00000000..af03d91b --- /dev/null +++ b/apps/web/src/data/sheet/content/module-17.md @@ -0,0 +1,15 @@ +--- +id: "module-17" +name: "Live fix/implement the issue - 1" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 1 + +Live fix/implement the issue - 1 + +First live session on fixing and implementing a medium difficulty issue. + +First live session on fixing and implementing a medium difficulty issue. + diff --git a/apps/web/src/data/sheet/content/module-18.md b/apps/web/src/data/sheet/content/module-18.md new file mode 100644 index 00000000..97d954fe --- /dev/null +++ b/apps/web/src/data/sheet/content/module-18.md @@ -0,0 +1,15 @@ +--- +id: "module-18" +name: "Live fix/implement the issue - 2" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 2 + +Live fix/implement the issue - 2 + +Second live session on fixing and implementing a medium difficulty issue. + +Second live session on fixing and implementing a medium difficulty issue. + diff --git a/apps/web/src/data/sheet/content/module-19.md b/apps/web/src/data/sheet/content/module-19.md new file mode 100644 index 00000000..61a001da --- /dev/null +++ b/apps/web/src/data/sheet/content/module-19.md @@ -0,0 +1,15 @@ +--- +id: "module-19" +name: "Live fix/implement the issue - 3" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 3 + +Live fix/implement the issue - 3 + +Third live session on fixing and implementing a medium difficulty issue. + +Third live session on fixing and implementing a medium difficulty issue. + diff --git a/apps/web/src/data/sheet/content/module-2.md b/apps/web/src/data/sheet/content/module-2.md new file mode 100644 index 00000000..72fd2e56 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-2.md @@ -0,0 +1,187 @@ +--- +id: "module-2" +name: "Get the basics done - prerequisites, tools and tips" +videoUrl: "https://youtu.be/f-l7zO_J4HU?si=5Cc6IB6TAi3wjZ71" +comingSoon: false +--- + +hey everyone, in this module we're gonna talk about the basics you need to know before contributing to open source — the tools, concepts, and a few practical tips to get started right. + +**quick request though** — please don't spam any open source repo i mention here. i'm using them just to explain stuff. making random prs just for numbers actually hurts projects, so be cool. + +### what to learn before contributing + +**first things first — learn git and github. they're not optional.** + +and no, you don't need to master every command under the sun. you just need to understand the full workflow of open source contributions — how to fork, clone, branch, rebase, push, and make prs. + +### forking & cloning + +so let's say you find a cool open source project. + +**step one — fork it**. when you fork, github creates a copy of that repo in your own account. this copy is yours to mess with — any changes you make affect your fork, not the main project. + +**step two — clone it to your local machine**. + +just grab the repo's url, open your terminal, and run: + +```bash +git clone +``` + +that downloads the project to your computer so you can actually make code changes. + +### setting up locally + +now comes the "fun" part — setting it up. + +almost every project has a section called local development in its readme. it'll list tools you need — like nodejs, postgresql, or docker. + +honestly, i recommend learning docker. it saves tons of setup time and works almost everywhere. but you can do manual setup too if you prefer. + +and just know — setup errors are normal. everyone faces them. first, try fixing things using google or chatgpt. if you're truly stuck for a day or two, then ask in the community or tag a maintainer. + +### branches & syncing + +you'll often create your own branch for each feature or fix. + +run: + +```bash +git checkout -b fix-xyz +``` + +this makes a new branch and switches you there. + +but since multiple contributors are working at once, your local copy can fall behind the main project. that's where syncing comes in. + +you can use either git merge or git rebase. + +**merge** combines changes but adds extra "merge commits" — can get messy. + +**rebase** keeps history clean and linear — i usually prefer this. + +if conflicts appear, open the files, decide which version to keep, delete the unwanted lines, then run: + +```bash +git add . +git rebase --continue +``` + +boom, conflict fixed and you're good to go. + +### cherry-picking commits + +sometimes your branch gets too messy — too many commits, too much noise. + +if you just want a few clean commits from another branch, use `git cherry-pick `. it copies only that specific commit into your branch. huge time saver when cleaning things up. + +### fetch vs pull (and how everything connects) + +here's a quick mental model: + +- **upstream** = the original repo you forked from +- **origin** = your fork on github +- **local** = your copy on your laptop + +`git fetch` gets updates from upstream without changing your local branch. + +`git pull` gets updates and merges them into your current branch. + +that's the basic flow: + +local → origin → upstream (via PRs), and upstream → origin → local (via pulls). + +### pushing your branch & raising a PR + +once your changes are ready: + +```bash +git add . +git commit -m "fix: something" +git push origin fix-xyz +``` + +that pushes your branch to your github fork. you'll see a "compare & pull request" button — click it, write a short, clear description, and raise a pr. + +**pro tip: raise draft prs early**. + +don't wait until everything's perfect — just raise a draft once the core part is working. it helps maintainers see your progress, prevents duplication, and gets you feedback early. just don't spam with one-line drafts. + +### stashing changes + +sometimes you're mid-work but don't wanna commit yet. + +you can stash your changes temporarily: + +```bash +git stash save "my changes" +``` + +to get them back later: + +```bash +git stash apply +``` + +this keeps your workspace clean while switching branches or testing something else. + +### quick git tricks + +check commit history: `git log --oneline` + +create short aliases (like git ac for add + commit) in your shell config — saves time. + +there are plenty of short youtube guides for that. + +### learn the basics of your stack + +besides git, know the basics of your programming stack. + +you should understand simple logic, loops, and core syntax. if you're into frontend, know your react/vue basics; if backend, know your frameworks; if infra or ai, know basic concepts like neural nets or containerization. + +you don't need to be an expert — just enough to make sense of what's happening in the code. + +### finding projects by niche + +right now, there's no perfect tool to find open source projects by niche. + +but i'm building [opensox.ai](https://www.opensox.ai/), which will let you filter projects by category — ai, infra, frontend, backend, etc. can't wait to ship that one. + +### extra skills that help + +anything else you know — dsa, previous internship experience, math, or theory — is a bonus. for example, if you know dsa, it helps you contribute to low-level libraries faster. every bit of prior knowledge compounds. + +### the "am i ready enough?" dilemma + +this is the most common question i get: am i ready to contribute? + +honestly — you'll never feel ready. even devs with years of experience hesitate at first. + +the best way to find out? just start. fork a repo, clone it, pick an issue, and go for it. you'll get stuck — that's where the learning happens. + +each time you hit a wall, ask yourself: what do i need to learn to fix this? + +need redis? learn it. need trpc? google it. learn just enough to solve the problem, fix it, move on, repeat. + +this "learn → apply → move" cycle will skyrocket your skills way faster than spending months watching tutorials or building yet another to-do app. + +of course, don't just stay on the surface — later, revisit the core concepts and learn them deeply. but for now, action > preparation. + +### todos: + +- [ ] practice these git commands once or twice +- [ ] get the basics of your tech stack (full stack, ai, web3, etc) done in one or two weeks +- [ ] learn naming conventions for [branches](https://medium.com/@abhay.pixolo/naming-conventions-for-git-branches-a-cheatsheet-8549feca2534), [commits](https://www.conventionalcommits.org/en/v1.0.0/) + +### closing thoughts + +so yeah — that's everything you need before diving into open source. + +git, github, a basic tech stack, and the courage to start even when you don't feel ready. + +don't wait for "perfect timing" — just fork, clone, and begin. + +you'll figure things out as you go, and that's where the real growth happens. + +this is ajeetunc. see you in the next module diff --git a/apps/web/src/data/sheet/content/module-20.md b/apps/web/src/data/sheet/content/module-20.md new file mode 100644 index 00000000..dcf84500 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-20.md @@ -0,0 +1,15 @@ +--- +id: "module-20" +name: "Live fix/implement the issue - 4" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 4 + +Live fix/implement the issue - 4 + +Fourth live session on fixing and implementing a medium difficulty issue. + +Fourth live session on fixing and implementing a medium difficulty issue. + diff --git a/apps/web/src/data/sheet/content/module-21.md b/apps/web/src/data/sheet/content/module-21.md new file mode 100644 index 00000000..d4b82441 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-21.md @@ -0,0 +1,15 @@ +--- +id: "module-21" +name: "Live fix/implement the issue - 5" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 5 + +Live fix/implement the issue - 5 + +Fifth live session on fixing and implementing a medium difficulty issue. + +Fifth live session on fixing and implementing a medium difficulty issue. + diff --git a/apps/web/src/data/sheet/content/module-22.md b/apps/web/src/data/sheet/content/module-22.md new file mode 100644 index 00000000..97e762cf --- /dev/null +++ b/apps/web/src/data/sheet/content/module-22.md @@ -0,0 +1,15 @@ +--- +id: "module-22" +name: "Raise the PR and get it merged" +videoUrl: "" +comingSoon: true +--- + +Raise the PR and get it merged + +Raise the PR and get it merged + +Learn the complete process of raising a pull request and getting it successfully merged into the project. + +Learn the complete process of raising a pull request and getting it successfully merged into the project. + diff --git a/apps/web/src/data/sheet/content/module-23.md b/apps/web/src/data/sheet/content/module-23.md new file mode 100644 index 00000000..47009a7a --- /dev/null +++ b/apps/web/src/data/sheet/content/module-23.md @@ -0,0 +1,15 @@ +--- +id: "module-23" +name: "How to make impressive contributions part-1?" +videoUrl: "" +comingSoon: true +--- + +How to make impressive contributions part-1? + +How to make impressive contributions part-1? + +First part of a guide on making standout contributions that get noticed in OPEN SOURCE projects. + +First part of a guide on making standout contributions that get noticed in OPEN SOURCE projects. + diff --git a/apps/web/src/data/sheet/content/module-24.md b/apps/web/src/data/sheet/content/module-24.md new file mode 100644 index 00000000..23f5f2f3 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-24.md @@ -0,0 +1,15 @@ +--- +id: "module-24" +name: "How to make impressive contributions part-2?" +videoUrl: "" +comingSoon: true +--- + +How to make impressive contributions part-2? + +How to make impressive contributions part-2? + +Second part of a guide on making standout contributions that get noticed in OPEN SOURCE projects. + +Second part of a guide on making standout contributions that get noticed in OPEN SOURCE projects. + diff --git a/apps/web/src/data/sheet/content/module-25.md b/apps/web/src/data/sheet/content/module-25.md new file mode 100644 index 00000000..f524b580 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-25.md @@ -0,0 +1,15 @@ +--- +id: "module-25" +name: "Get/pick your third issue assigned (medium-hard)" +videoUrl: "" +comingSoon: true +--- + +Get/pick your third issue assigned (medium-hard) + +Get/pick your third issue assigned (medium-hard) + +Learn how to get your third issue assigned, focusing on medium to hard difficulty issues. + +Learn how to get your third issue assigned, focusing on medium to hard difficulty issues. + diff --git a/apps/web/src/data/sheet/content/module-26.md b/apps/web/src/data/sheet/content/module-26.md new file mode 100644 index 00000000..4a707353 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-26.md @@ -0,0 +1,15 @@ +--- +id: "module-26" +name: "Live fix/implement the issue - 1" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 1 + +Live fix/implement the issue - 1 + +First live session on fixing and implementing a medium-hard difficulty issue. + +First live session on fixing and implementing a medium-hard difficulty issue. + diff --git a/apps/web/src/data/sheet/content/module-27.md b/apps/web/src/data/sheet/content/module-27.md new file mode 100644 index 00000000..c2c9eabc --- /dev/null +++ b/apps/web/src/data/sheet/content/module-27.md @@ -0,0 +1,15 @@ +--- +id: "module-27" +name: "Live fix/implement the issue - 2" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 2 + +Live fix/implement the issue - 2 + +Second live session on fixing and implementing a medium-hard difficulty issue. + +Second live session on fixing and implementing a medium-hard difficulty issue. + diff --git a/apps/web/src/data/sheet/content/module-28.md b/apps/web/src/data/sheet/content/module-28.md new file mode 100644 index 00000000..9680213b --- /dev/null +++ b/apps/web/src/data/sheet/content/module-28.md @@ -0,0 +1,15 @@ +--- +id: "module-28" +name: "Live fix/implement the issue - 3" +videoUrl: "" +comingSoon: true +--- + +Live fix/implement the issue - 3 + +Live fix/implement the issue - 3 + +Third live session on fixing and implementing a medium-hard difficulty issue. + +Third live session on fixing and implementing a medium-hard difficulty issue. + diff --git a/apps/web/src/data/sheet/content/module-29.md b/apps/web/src/data/sheet/content/module-29.md new file mode 100644 index 00000000..bbda4fbb --- /dev/null +++ b/apps/web/src/data/sheet/content/module-29.md @@ -0,0 +1,10 @@ +--- +id: "module-29" +name: "Live fix/implement the issue - 4" +videoUrl: "" +comingSoon: true +--- + +### Live fix/implement the issue - 4 + +Fourth live session on fixing and implementing a medium-hard difficulty issue. \ No newline at end of file diff --git a/apps/web/src/data/sheet/content/module-3.md b/apps/web/src/data/sheet/content/module-3.md new file mode 100644 index 00000000..d0620147 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-3.md @@ -0,0 +1,138 @@ +--- +id: "module-3" +name: "Explore and Select projects to contribute" +videoUrl: "https://youtu.be/bviwfDq-CTo?si=EwH1AFUpDM7p_FFy" +comingSoon: false +--- + +hey, welcome back. in the last module, we talked about what you need to know before contributing to open source. if you haven't watched that yet, go check out module 2 first — the modules are mostly independent, but watching them in order helps things click better. + +in this module, we're diving into something super practical — how to find open source projects and how to explore them properly. because honestly, finding good projects isn't as easy as it sounds. there are tons of repos out there — some great, some meh — and your job is to pick the ones worth your time. + +so let's get into it — i'll show you 10+ ways to discover awesome open source projects: + +### way 1 — opensox.ai + +this one's built exactly for this purpose. + +head over to [opensox.ai](https://www.opensox.ai/), click get started → find projects, choose your tech stack — say typescript — then adjust filters like popularity or competition level. hit search, and boom — you'll get a curated list of projects you can explore. + +ignore random personal projects and focus on official or company-backed ones. opensox gives you a good mix, but it's still improving, so you might see a few irrelevant ones here and there. + +### way 2 — algora.io + +next up, [algora.io](https://algora.io/). + +this site lists a ton of open source projects, especially those offering bounties. perfect if you're aiming for paid contributions. + +they also have a projects section, though you'll have to explore manually since there aren't filters. still, it's solid for discovering new repos like ts circuit, rasp, activepieces, and more. + +btw, you'll find this whole list in the discord community doc if you're part of it. + +### way 3 — yc startup directory + +yc (y combinator) has a directory of startups, including many open source ones. + +just search "yc open source projects 2025" — click the first link — and you'll find companies like gitlab, docker, airbyte, skyvern, tip tap, and tons more. + +personally, i suggest exploring newer yc-backed projects. they're usually more open to new contributors and provide better mentorship and community engagement. older, massive ones like gitlab are great too but tend to have slower response times. + +### way 4 — gsoc project list + +yeah, gsoc. the og of open source. + +search "gsoc project list" and open the organizations page. use the filters — for example, type "rust" and you'll get all rust-based orgs. + +each org page links to their website or repo, where you can join their community or explore issues. just a reminder — don't spam readme updates. contribute meaningfully. + +### way 5 — github trending + +this one's simple but underrated. + +go to [github.com/trending](https://github.com/trending). you'll see projects blowing up right now — many are new and buzzing. + +you'll find established names like appsmith, meshery, zod, and a bunch of new ones. trending repos are gold because they show what's hot in the dev world. + +### way 6 — open source communities (discord / slack) + +joining open source communities is a cheat code. + +when you join one, you naturally get exposed to many others because maintainers and founders share each other's announcements. + +so start with a few like appsmith, docs, or meshery. you'll usually find their discord or slack links on their landing page — scroll to the footer or "community" section. + +one community always leads to another — and soon you'll be looped into everything happening in the open source world. + +### way 7 — twitter (x) + +twitter (okay, x) is another goldmine. + +most new open source launches, updates, and funding news drop there first. + +just follow people who are active in the open source ecosystem — contributors, founders, maintainers, or tech builders. i followed around 40–50 when i started, and that alone kept me updated daily. + +### way 8 — funding news & newsletters + +follow sites like techcrunch, product hunt, hacker news, and mashable. they often cover open source startups that recently launched, got funded, or announced something big. + +you can also subscribe to newsletters like indie hackers, starter story, or mark lowe's newsletter. they aren't open source–only, but you'll still discover cool projects and communities through them. + +btw, i'm also launching an opensox newsletter soon that'll include curated open source updates every week. + +### way 9 — follow active open source contributors + +this one's a secret gem. + +when you follow active contributors on github or twitter, you automatically get access to the projects they work on, the issues they solve, and the new repos they star or contribute to. + +but do this respectfully. don't dm random contributors asking for hand-holding. just quietly observe and learn — it's the easiest way to find high-quality projects and understand how top devs contribute. + +### way 10 — oss friends + +this is one of my personal favorite tricks. + +many open source companies mention their "oss friends" — basically other open source projects they use or partner with. + +scroll to the footer of their site, look for "oss friends", "open source friends", or just "friends". click it, and you'll find a list of related projects — all open source too. it's like a mini-network of connected ecosystems. + +you can repeat this recursively — click one project, see its oss friends, and so on. total goldmine. + +### how to explore and shortlist projects + +now that you've got a long list, the next step is exploring and shortlisting. + +you obviously can't contribute to all 100 — so pick around 10–15 projects that look interesting. + +make a simple doc (obsidian, notion, or even notepad) and list them. for each project, check: + +1. is the repo active? (recent commits, frequent prs, community chatter) +2. does it match your tech stack? no point joining a rust project if you only know typescript. +3. is the community active? check their discord — if no one replies for weeks, maybe skip it. +4. do they label issues clearly for contributors? good projects usually tag issues with good first issue, help wanted, or bounty. + +every time you find one that fits, add it to your list. aim for 10, not 100 — focus is key. + +### trimming your list + +once you've explored enough, narrow your 10–15 projects down to maybe 5 or 6 based on these filters: + +- high activity +- solid maintainer/community support +- tech stack you understand +- meaningful issues you can actually work on + +this helps you focus your energy where it matters instead of spreading too thin. + +### todos: + +- [ ] using the above methods, explore and find 7-8 open source projects +- [ ] explore the selected open source projects deeply and trim down to 2-3 +- [ ] join the communities (slack, matrix, discord) of those 2-3 projects + +### final thoughts + +remember — these aren't hard rules. these are just proven ways to discover great projects. you might find your own methods too, and that's completely fine. + +the key is simple: don't overthink. explore, shortlist, start contributing. you'll figure things out as you go. + +so yeah, that's all for this module. hope it helps you discover your next favorite open source project. this is ajeetunc. see you in the next module diff --git a/apps/web/src/data/sheet/content/module-30.md b/apps/web/src/data/sheet/content/module-30.md new file mode 100644 index 00000000..80c30f8e --- /dev/null +++ b/apps/web/src/data/sheet/content/module-30.md @@ -0,0 +1,10 @@ +--- +id: "module-30" +name: "Raise the PR and get it merged" +videoUrl: "" +comingSoon: true +--- + +### Raise the PR and get it merged + +Learn the complete process of raising a pull request for a medium-hard issue and getting it successfully merged. \ No newline at end of file diff --git a/apps/web/src/data/sheet/content/module-31.md b/apps/web/src/data/sheet/content/module-31.md new file mode 100644 index 00000000..1df98d54 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-31.md @@ -0,0 +1,10 @@ +--- +id: "module-31" +name: "How to get jobs/internships through OPEN SOURCE?" +videoUrl: "" +comingSoon: true +--- + +### How to get jobs/internships through OPEN SOURCE? + +Learn how to leverage your OPEN SOURCE contributions to land jobs and internships in the tech industry. \ No newline at end of file diff --git a/apps/web/src/data/sheet/content/module-4.md b/apps/web/src/data/sheet/content/module-4.md new file mode 100644 index 00000000..32844b65 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-4.md @@ -0,0 +1,12 @@ +--- +id: "module-4" +name: "Adhoc: How to setup projects locally" +videoUrl: "https://youtu.be/qAlz8279M5A?si=PJ3ZKCZBx8RqvgOk" +comingSoon: false +--- + +you don't need to read my yap in this module. just follow along with [this video](https://youtu.be/qAlz8279M5A?si=PJ3ZKCZBx8RqvgOk) and set up any open source project locally. + +### todos: + +- [ ] just set up the projects locally that you selected in module 3 (if you didn't, wake up and do it now) diff --git a/apps/web/src/data/sheet/content/module-5.md b/apps/web/src/data/sheet/content/module-5.md new file mode 100644 index 00000000..7e6cc489 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-5.md @@ -0,0 +1,176 @@ +--- +id: "module-5" +name: "Introduce yourself and familiarize" +videoUrl: "https://youtu.be/wvl_SkMwbrU?si=HlFe4Kj9Tz2J_d6B" +comingSoon: false +--- + +hey everyone, welcome to module 5! + +in module 3 and 4, we talked about how to find good open source projects and how to choose which ones to contribute to. + +now, it's time to actually dive in — to learn how to understand a project's codebase, introduce yourself to the community, and start feeling at home inside a repo. + +### quick reality check + +**you don't need to know everything about a project to contribute**. + +just yesterday, i met a guy who wasn't contributing because he thought he had to learn every single part of the tech stack before touching code. that's completely wrong. + +open source doesn't work like that. you learn while contributing — not before it. + +### step 1 — joining the project + +for this example, i'll take [browser use](https://github.com/browser-use/browser-use), a YC-funded open source project that builds ai-powered browser agents. super cool stuff. + +first, clone the repo locally and open it in cursor (or any ai-assisted editor). + +if you don't use cursor yet, please start — not for writing code, but for understanding it. it saves hours of manual digging. + +### step 2 — read the code of conduct + contribution guide + +every open source project has these — sometimes hidden in the repo root. + +you don't need to memorize them, just skim to understand their style, policies, and dos/don'ts. + +avoid giving "linkedin vibes" when you join. don't drop a whole autobiography like: + +"hi i'm from xyz college, participated in 10 hackathons, worked on abc…" + +none of that matters. just say something like: + +"hey everyone, i'm new here. excited to help with ." + +and please — don't join saying "i want a job/internship." you earn that through consistent contributions, not by asking for it. + +### step 3 — join their community + +most active projects have a discord or slack. join it. that's where maintainers discuss bugs, new ideas, and upcoming features. + +if you skip it, you'll keep asking basic questions that were already answered there — which can annoy maintainers. + +also, join their showcase channel if they have one — projects that highlight contributors' work usually have a great culture. + +### step 4 — understand the tech stack + +head to the repo and check what language dominates the code. + +in browser use, it's ~98% python. + +use cursor or any ai tool to ask: + +"summarize the libraries and frameworks used in this project." + +you'll get a clear breakdown. for example, browser use uses: + +- chromium CDP (chrome devtools protocol) for browser automation +- pydantic for data models +- httpx, aiohttp, requests for api calls +- openai, anthropic, google genai for llm support +- rich, click, dotenv, pillow, numpy, etc. + +now here's the important part — you don't need to know them all. + +you just need a rough idea of what each one does. + +later, when you see an issue mentioning "pydantic" or "rich", you'll remember, "oh yeah, that's probably related to data validation or ui formatting." + +that tiny context saves hours later. + +### step 5 — understand architecture + +now, use cursor again and ask it to: + +"map out the architecture and organization of this codebase." + +it'll usually show: + +- **core layers** — agent, tools, browser, dom, llm +- **architecture style** — event-driven, async-first, modular +- **patterns** — dependency injection, registry pattern, lazy imports + +don't panic if you don't know these terms yet. + +just note them down. later, when you actually contribute, you'll revisit and everything will start to click. + +remember: this step isn't about mastering the architecture — it's about familiarity. + +### quick detour — what's CDP? + +CDP stands for chrome devtools protocol — basically a bridge between your code and the browser's brain. + +before CDP, you could open devtools manually (press F12), but there was no way to automate that programmatically. + +CDP fixed that. + +it lets your code send commands to the browser — like "click this button", "fill this form", "screenshot this page". + +it's literally how browser use automates actions — you tell the agent "fill this form for me", and under the hood, CDP executes those actions on chrome. + +so now you kinda get the magic behind it. + +### step 6 — understanding the flow + +architecture tells you how the system is built. + +the flow tells you how data moves when you perform an action. + +for example, in browser use, there's a feature: + +"fill in this job application with my resume." + +to understand the flow, ask cursor: + +"explain the code flow for this feature step by step." + +and it'll map it like this: + +1. user triggers the command +2. agent gets created +3. agent collects data (DOM, browser state, tools, etc.) +4. LLM decides what to do next (click, type, upload, etc.) +5. those actions get executed via CDP +6. browser updates the DOM and returns results + +this is how you build intuition. you don't need to understand every function — just how things connect. + +### step 7 — read a few core files + +cursor will also tell you which files are key (like agent/service.py, apply_to_jobs.py, browser/session.py, etc.). + +open them, skim through, and note down what each roughly does. + +you'll start to notice patterns like "okay, this file handles browser actions" or "this one manages LLM communication." + +that's all you need at this stage. + +### step 8 — don't get stuck in the learning loop + +this whole process — joining, reading, exploring, mapping flow — should take less than a day. + +don't spend weeks "understanding everything." + +if you wait until you know every tool, every function, every file, you'll never start. + +the goal is to gain enough familiarity to confidently pick small issues and learn as you go. + +### what's next + +in the next module, we'll cover how to pick the right issues — because not every issue is beginner-friendly. we'll talk about which ones to start with, which ones to avoid, and how to build momentum without burning out. + +so yeah, that's it for this one. + +remember: you don't need to know everything — just start. + +learn, contribute, repeat. + +### todos: + +- [ ] whichever project you chose in the previous module, fork and clone it locally +- [ ] find CODE OF CONDUCT and CONTRIBUTING.md files and read them +- [ ] join their community - on slack, discord, etc +- [ ] understand the tech stack (you can follow the way ive mentioned here [08:10](https://www.youtube.com/watch?v=wvl_SkMwbrU&t=490s)) +- [ ] understand the architecture like this [16:07](https://www.youtube.com/watch?v=wvl_SkMwbrU&t=967s) +- [ ] go through the code flow [33:34](https://www.youtube.com/watch?v=wvl_SkMwbrU&t=2014s) + +this is ajeetunc. see you in the next module diff --git a/apps/web/src/data/sheet/content/module-6.md b/apps/web/src/data/sheet/content/module-6.md new file mode 100644 index 00000000..2300eca4 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-6.md @@ -0,0 +1,174 @@ +--- +id: "module-6" +name: "Find the issues to work on" +videoUrl: "https://youtu.be/0U_v8WK48fo?si=1-oj2Rz7pxX8r_z6" +comingSoon: false +--- + +hey, welcome back + +in this module, we're gonna talk about how to pick the right issue to work on — especially if you're just starting out. + +finding issues isn't the hard part. there are tons of them. + +the tricky part is choosing one that's actually right for you — something small, doable, and meaningful, without wasting hours or getting stuck for days. + +let's break that down: + +### step 1 — start small (but meaningful) + +when you're new to an open source project, never start with a complex issue. + +your first goal isn't to "prove your genius" — it's to understand how contributions actually work in that project. + +so pick something small but useful — like fixing a minor bug, improving logs, or tweaking small functions. + +just avoid low-value stuff like "update readme" or "add full stops". + +### step 2 — understanding issue types + +when you open the issues tab, you'll usually see a mix of two kinds: + +1. **maintainer-created issues** – made by the project's core team. +2. **contributor-created issues** – made by community members like you. + +if it's a bug created by maintainers, you can usually start right away. + +but if it's a feature request by another contributor, always confirm with maintainers first — ask if they actually want that change before you spend time on it. + +### step 3 — analyze one issue example (browseruse repo) + +let's look at a real one. + +there's a bug: + +"action field consistently missing in the response of llm." + +sounds simple, but let's read it. + +the user says that when using the deepseek LLM model, the action field isn't returned in the response. the logs show schema mismatches. + +that instantly tells us — this issue might need setting up the deepseek API or model locally. so we have to decide: + +is this a "first-issue" level problem or something that'll eat my whole weekend? + +if it looks like a multi-hour setup, skip it for now. you'll get there later. + +### step 4 — using ai tools (like cursor) smartly + +to really understand what's going wrong, copy the issue text into cursor and ask: + +"where in the codebase is this issue occurring, and why?" + +cursor will instantly scan the repo and point to relevant files or functions (like chat.py or views.py) — giving you a clear idea of what's breaking. + +but don't jump straight to "fix this." + +instead, first ask why the issue exists — learn the cause before trying to patch it. + +### step 5 — understanding the root cause + +in this deepseek issue, cursor explains that the schema defines action as a required field, + +but the deepseek model doesn't return that field in its response. + +so the problem isn't your code — it's a schema mismatch between your definition and deepseek's actual output. + +basically: + +the repo expects { action: ... } in every response, + +but the model is like "nah, not gonna send that." + +this kind of issue is super common in llm-based projects — when the model's schema handling differs from others like openai or anthropic. + +### step 6 — check how hard it is to fix + +before deciding, ask cursor: + +"will fixing this require a deepseek api or local setup? and how long might it take?" + +cursor says: + +- you can test schema logic without an api +- but you can't test full responses unless you have one +- time estimate: around 30–60 minutes if you just handle schema validation + +so that's a green light — it's small, scoped, and fixable. perfect for a first issue. + +### step 7 — plan the fix before writing code + +when cursor gives you possible fixes, don't just accept the first one. + +read them all, question them. + +ask things like: + +- "why is option one better than option two?" +- "what could break if i try this approach?" + +your goal is to understand the logic, not just copy-paste ai suggestions. + +in this case, the recommended fix was to: + +1. add validation handling in chat.py around line 169–180 +2. catch missing action errors and retry with a clearer prompt +3. update the schema description so it clearly marks action as required + +once you understand that, then start implementing. + +### step 8 — setting up environment + branch + +create a test api key for deepseek (openrouter gives free keys btw). + +add it to your env file. + +then create a clean branch like: + +```bash +fix/action-field-missing +``` + +short, clear, self-explanatory. + +never code directly on main. + +### step 9 — be patient with yourself + +look, you won't nail every fix perfectly. and that's fine. + +the goal is to figure things out, not to look like a pro. + +i'm not some flawless coder — i mess up, get stuck, debug badly, and still somehow figure it out eventually. that's the real process. + +so if you get stuck — don't panic. + +use cursor, ask maintainers polite questions, and keep learning through each issue. + +### step 10 — summary + +so here's the mindset recap: + +- start small but meaningful +- confirm maintainer approval if needed +- read the issue carefully +- use ai tools to understand the root cause +- estimate difficulty before committing +- plan the fix, don't rush it +- make a clean branch and start simple + +once you fix it, test locally → push → raise a pr. + +### todos: + +- [ ] watch [this video](https://youtu.be/0U_v8WK48fo?si=1-oj2Rz7pxX8r_z6) to make sense of this yap +- [ ] following the steps mentioned, pick and understand an issue to work on further +- [ ] create a branch to work on that issue + +and that's it for this module + +in the next one, we'll actually implement the fix, test it, and raise our first pull request together. + +until then — keep exploring, keep breaking things, and keep building your open source story + +this is ajeetunc. see you in the next module diff --git a/apps/web/src/data/sheet/content/module-7.md b/apps/web/src/data/sheet/content/module-7.md new file mode 100644 index 00000000..4be67947 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-7.md @@ -0,0 +1,15 @@ +--- +id: "module-7" +name: "Get/pick your first issue assigned (easy-med)" +videoUrl: "https://youtu.be/H-zCtw5c3uQ?si=wkPNFubBaVCwMS3f" +comingSoon: false +--- + +this module is just the implementation of an issue we picked in the previous module. + +### todos: + +- [ ] just watch the [video](https://youtu.be/H-zCtw5c3uQ?si=wkPNFubBaVCwMS3f) +- [ ] and follow along with your own issue. + +this is ajeetunc. see you in the next module diff --git a/apps/web/src/data/sheet/content/module-8.md b/apps/web/src/data/sheet/content/module-8.md new file mode 100644 index 00000000..d5315066 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-8.md @@ -0,0 +1,10 @@ +--- +id: "module-8" +name: "Adhoc: How to learn anything fast?" +videoUrl: "" +comingSoon: true +--- + +# Adhoc: How to learn anything fast while contributing? + +Strategies and techniques for learning quickly while actively contributing to OPEN SOURCE projects. diff --git a/apps/web/src/data/sheet/content/module-9.md b/apps/web/src/data/sheet/content/module-9.md new file mode 100644 index 00000000..47e9e404 --- /dev/null +++ b/apps/web/src/data/sheet/content/module-9.md @@ -0,0 +1,134 @@ +--- +id: "module-9" +name: "Live fix of the issue - Part-1" +videoUrl: "https://youtu.be/hRMtIB-pkeE" +comingSoon: false +--- + +# module 9: extending the browser-use contribution + +**note:** as this module is implementation focused, try watching the [video](https://youtu.be/hRMtIB-pkeE) so that you can have better understanding. + +in this module we're continuing the contribution we started in module 8. in module 8 we began working on an issue in the browser-use repo, and here we'll extend that work. + +**note:** if you haven't watched module 7 and module 8, you should do that first — otherwise nothing in this module will make sense. + +### checking the issue status + +so let's open the issue we were working on. it's already closed. + +four days ago, in module 8, we commented that we weren't able to reproduce the exact error described in the issue. + +now, someone else replied saying that when the error triggers, the whole system crashes and floods the terminal with a huge amount of errors, which makes it impossible to see the real root cause. + +he didn't attach screenshots, so we still didn't have full clarity. + +after that, the original issue creator replied and tagged me. he shared screenshots and explained the real behavior. + +### understanding what the issue creator meant + +the contributor said: + +_when the deepseek model returns a response without the action field, the error is added to the agent history, but the LLM doesn't react to that error._ + +so even if the agent says "hey deepseek, action field is missing", deepseek still keeps responding without the action field. + +**this creates a repeating loop of failures.** + +the contributor also fixed a local FILE-URL security issue for himself, but clarified that the core bug has nothing to do with files — it's purely about deepseek not returning the required field. + +he then shared screenshots showing: + +- the schema has required fields: thinking, evaluation, previous_goal, memory, next_goal, action +- deepseek returns everything except action +- pydantic throws a validation error +- agent retries, sends that error back +- deepseek still doesn't fix itself +- that means the failure multiplies + +this exactly matches what another commenter said earlier: **multiple errors spam the terminal.** + +so now we finally understand the real root cause. + +### reproducing the issue properly + +since the real bug isn't tied to FILE-URL access or html parsing, we don't need to recreate the whole file scenario from module 8. + +the bug appears in any task as long as deepseek returns a response missing "action". + +we just need to run a task with deepseek, catch the output, and check agent history. + +the maintainer also pointed out where the missing check might live: + +`browser_use.agent.service.Agent.get_model_output_with_retry()` + +### why the issue was closed without a PR + +now the important part: **why did the maintainer close the issue with no PR?** + +here's the maintainer's final comment: + +_some models are unfortunately bad at obeying the structured output schema._ + +_we recommend using system_prompt_extension to explicitly describe the output format to the model._ + +**in short:** + +- deepseek simply doesn't follow the schema +- so this isn't a browser-use bug, it's a model behavior problem + +the library already provides a built-in solution: + +**extend_system_message** — a system-prompt extension that lets you explicitly tell the model how to format its output. + +so rather than patch browser-use for a model-specific issue, the correct fix is: + +use the system prompt extension to force deepseek to follow the required schema. + +**that's why the maintainers didn't want a PR for this.** + +### lessons from the PR attempt by someone else + +another contributor opened a PR to "fix" this issue. the PR wasn't merged, and here are the mistakes worth learning from: + +- ❌ **didn't get maintainer approval first** — always ask maintainers before fixing unclear issues +- ❌ **didn't fully understand the root cause** — he attempted to fix a model-side issue at the agent level +- ❌ **didn't use proper PR formatting** — he didn't use "fixes #" or "addresses #", so Github couldn't auto-close anything +- ❌ **no tests, no screenshots** — always attach before/after results or output logs +- ❌ **poor commit messages** — commit messages should follow good conventions like "fix: missing action field validation" instead of random unclear messages +- ❌ **didn't sign the CLA** — most OPEN SOURCE projects require this before merging + +**learning these early will save months of frustration.** + +### what "system prompt extension" actually means + +`extend_system_message` lets you ADD extra instructions to the LLM without replacing the default system prompt. + +**example:** + +tell the model explicitly — "always include an action field in your response." + +this is like the "additional note" option in food-delivery apps: the system already knows your order, but you add a custom instruction like "please bring cutlery" or "don't ring the bell". + +same vibe here. + +so instead of hacking the agent code, you use the built-in system message extension to guide the model. + +**problem solved.** + +### the wrap-up + +even though the issue got closed before we could raise a PR, we still learned a lot: + +- ✓ how to reproduce bugs +- ✓ how to interpret contributor comments +- ✓ how agent history works +- ✓ how retry loops create cascading failures +- ✓ how to ask clarifying questions +- ✓ how maintainers think about issues +- ✓ how to avoid bad PR habits +- ✓ how the model vs agent boundary works + +in the next module, we'll pick another issue — ideally one we can actually fix and raise a PR for. + +this is ajeetunc. see you in the next module. diff --git a/apps/web/src/data/sheet/index.ts b/apps/web/src/data/sheet/index.ts index d2d19d01..7fa3bc40 100644 --- a/apps/web/src/data/sheet/index.ts +++ b/apps/web/src/data/sheet/index.ts @@ -1,2 +1,2 @@ -export type { SheetModule } from "./sheet"; -export { sheetModules } from "./sheet"; +export type { SheetModule } from "./types"; +export { getSheetModules } from "./sheet"; diff --git a/apps/web/src/data/sheet/module-0.ts b/apps/web/src/data/sheet/module-0.ts deleted file mode 100644 index 86cb6fb4..00000000 --- a/apps/web/src/data/sheet/module-0.ts +++ /dev/null @@ -1,113 +0,0 @@ -import { SheetModule } from "./types"; - -export const module0: SheetModule = { - id: "module-0", - name: "Introduction & Announcement", - docContent: ` -

in this module ive yapped two things: some of my context and announcement of OPEN SOURCE series.

- -

some of my context:

-

so my name is Ajeet and these are some of my achievements so far:

- Ajeet's work screenshot - -

im telling you this not to show off but to make a point that what we can achieve through OPEN SOURCE in 3 years.

- -

especially in my case, the background i come from and the college i come from achieving all of this in 3 years was i mean at least for me was next to impossible because i had never thought that i will ever be able to do all of that.

- -

if i be honest with you then my initial plan was to get around 4 to 5 LPA job at any company because at that time i was very desperate to get into tech and i was thinking that okay i will just get into tech and then i will go for something bigger.

- -

so that was my plan. but fortunately the 4 LPA thing i was able to get it in my second year itself as a stipend of my first internship and all of this was possible through OPEN SOURCE.

- -

that was the best thing that happened to me. i was able to contribute to OPEN SOURCE and i was able to connect with some really cool people who introduced me to some organizations and to some really cool open-source projects that led me to some really great opportunities including an interview at lovable.

- -

so i will tell you more about this lovable thing later in this module.

- -

these are only the direct results that i got from OPEN SOURCE but there are also some indirect results that i got and in those indirect results one is like connections and recognition.

- -

so when i started contributing to open-source people started recognizing me, i mean people started kind of making a connection and i was able to make connection with maintainers and CTOs and even CEOs of couple of companies even VC backed companies.

- -

so those connections really help me whenever i either want to get an interview or want something else. then pinging those people who i already know makes it a lot easier to get something.

- -

and the second thing i got from OPEN SOURCE and that is a strong profile. so i still know that there was a time when whenever i used to apply for an opening then there used to be 100% chances of rejection because at one point i was getting rejected from almost any opening.

- -

then i shifted my focus from applying to started contributing to OPEN SOURCE and for around one and a half year i just contributed to OPEN SOURCE and all the experience that i got from OPEN SOURCE i mentioned in my resume and my portfolio and as a result of that i started noticing really great results from the openings like most of the times my profile started getting selected.

- -

and also once i send my profile to the founder of lovable and it was selected and i was able to land an interview at lovable.

- - Ajeet's work screenshot - -

so the strong portfolio and strong profile is the second indirect benefit of OPEN SOURCE.

- -

and the third indirect benefit of OPEN SOURCE is that whenever you see an opening job opening these days 99.99% of the times you will see a line there that "if you have done OPEN SOURCE and if you have contributed to OPEN SOURCE then it's a plus point" and most of the time i get that plus point because it really makes your profile unique when you have already contributed to some OPEN SOURCE companies especially the competitors of the company that you are applying for.

- -

so once i had applied for a payment company and fortunately i had already made contributions to a similar payment company that was based in Europe. so my resume was shortlisted and i was able to get interview really fast just because of those OPEN SOURCE contributions that i had made to that payment company.

- - Ajeet's work screenshot - -

overall i mean my whole point is that the ROI that you get from OPEN SOURCE is not limited. so you won't even believe where OPEN SOURCE can take you in the next one or two years.

- -

but all of this journey, all of this open-source journey so far was not easy to be honest because especially in my case when i had no senior or not someone to whom i can go and ask something there was always a problem of doubts. there was always a problem of not having a human feedback.

- -

so everything and anything ive learned so far was a is a result of observing things and observing people like how do they do it and how they are making contributions and how are they tackling issues.

- -

so when we contribute to OPEN SOURCE there is not only one problem that we face there are a lot of problems that we have to go through and couple of those problems are like not able to find the project.

- -

so that is the first and the one of the most complex problem when we contribute to OPEN SOURCE. so because let's say as a new contributor we don't even know like which project we have to contribute to.

- -

so but to be honest initially it doesn't matter much like you can contribute to any OPEN SOURCE project depending on your tech stack or on your preferences but again it's still a hustle kind of thing because we are not able to land on a good project.

- -

so that is why i had created opensox.ai and i'm still working on that. but that was the first problem and there was a second problem as well.

- -

when we are very new and when we contribute to repositories that are pretty famous and very complex code bases then we face a lot of competition or a lot of saturation because there are a lot of people who are making contributions parallelly and there we have to make contributions as a beginner.

- -

so it creates a lot of problems for us because we are not even able to fix smaller issues because for each issue there are a lot of people already competing there. so that is the second problem.

- -

there is also a third problem and that is getting overwhelmed.

- -

so basically when we are new and when we have no experience to OPEN SOURCE we easily get overwhelmed by all of these things because there are a lot of tools a lot of practices that we have to follow and also there are a lot of things that we have to know be it technology or be it patterns that that particular organization follow and also each organization or each OPEN SOURCE projects has its own technologies has its own paradigms of contributing the code to it.

- -

so it makes it really hard for a new contributor to start contributing. it takes a lot of months for them to get started with OPEN SOURCE.

- -

there is one more very painful problem that we face while contributing to OPEN SOURCE and that is not getting attention of the maintainers. so imagine you work on something for weeks and when you raise a PR then there is no one to look to that look at that PR or to review that PR.

- -

so that's really painful and in most of the cases it's not the mistake of maintainers it's the mistake of contributors. so either they have chosen a wrong issue or something that's not important or a thousand reasons by which it can happen you may not get the attention that you need.

- -

so it is really demotivating and disappointing when you work on something for so long and no one look at it. so these are the these are kind of problems that most of the people face when they are new to OPEN SOURCE.

- -

so to document everything what ive learned through open-source i'm going to create an open-source series of around 30 to 40 modules and in this series i'm going to explain everything in details from finding projects to finding opportunities in OPEN SOURCE companies or organizations.

- -

there are two reasons why this series contains 30 plus modules. number one, it this series is for absolute beginners or the people who face problems while contributing to OPEN SOURCE.

- -

and the second reason is there are a lot of smaller details that matters a lot but most of the times it is either ignored by people who already teach on YouTube or it is mostly unheard it is not documented.

- -

so that is why this series is going to be long enough to contain everything that is important for a beginner or the person who is facing problems while contributing to OPEN SOURCE.

- -

this is what this series will contain:

- - Ajeet's work screenshot - - Ajeet's work screenshot - -

also there are going to be couple of bonus modules or couple of ad hoc modules. so if i for forget something in this list then i will cover all of that in these bonus modules

- -

todos:

-
    -
  • - ☐ - make a firm decision to do OPEN SOURCE -
    • -
  • - ☐ - share this series with others :) -
    • -
  • - ☐ - rest todos in the next module - -
    • -
- -

finally, that's all in this module. i'll yap more in the next module. take care.

- `, - videoUrl: "https://youtu.be/ctXaTeeUdRE", -}; diff --git a/apps/web/src/data/sheet/module-1.ts b/apps/web/src/data/sheet/module-1.ts deleted file mode 100644 index 3a3c28cf..00000000 --- a/apps/web/src/data/sheet/module-1.ts +++ /dev/null @@ -1,157 +0,0 @@ -import { SheetModule } from "./types"; - -export const module1: SheetModule = { - id: "module-1", - name: "Things to know before jumping to Open Source", - docContent: ` -

hey, im back. in this module we're gonna talk about what you should know before contributing to open source.

- -

quick disclaimer

-

everything i say here is from my personal experience. it's not some rulebook or law. i might be wrong in a few places, and you might have a better take on things. so feel free to pick whatever works best for you.

- -

first things first — know your goals from open source

-

everyone joins with different reasons. some wanna learn, some want a job or internship, some are in it for gsoc or bounties, and some just do it for fun. but behind all that, the real goal is to make impactful contributions.

- -

whether it's learning, landing a gig, or just enjoying the process — everything eventually comes down to one thing: making meaningful, high-impact contributions. that's what truly moves the needle.

- -

mindset while contributing to open source

- -

when it comes to open source, remember — it's not always about code.

- -

people usually think contributors only write code, but that's not true. a good contributor isn't just someone pushing commits; they're someone who understands the product, keeps the docs clean, helps others, reviews prs, and improves the overall project vibe.

- -

so yeah, code matters — but contribution goes way beyond that. even if you're mainly into coding, try helping out in other areas too. things like improving docs, giving feedback on prs, or helping someone debug can be super valuable.

- -

quality > quantity + start small + ego + tracking

- -

quality always beats quantity — that's one of my favorite philosophies.

- -

you can raise two prs instead of ten, but if they're high-quality and impactful, that's what really counts. don't chase numbers, chase impact. that's what helps you hit your goals — whether it's learning, landing gigs, or just building credibility.

- -

in the beginning, it's totally fine to just focus on getting started and getting your first pr merged. once you're comfortable, start paying attention to quality — learn what makes an issue truly valuable or impactful.

- -

also, start small. most beginners try to take on massive issues and then get stuck or burned out. pick small, easy tasks first, build confidence, and then slowly move to the bigger stuff.

- -

and please — leave your ego at the door. sometimes your pr won't get merged, or someone else might propose a better solution. that's okay. open source isn't about proving you're the best; it's about learning, improving, and growing together.

- -

finally, track everything. open source has a lot of moving parts — issues, prs, reviews, updates. if you don't track them properly, you'll get overwhelmed. below is a simple doc i use to keep things organized, the main idea is: stay structured so you can move fast without burning out.

- - Ajeet's work screenshot - -

hard things have less competition + confidence + compounding

- -

here's a cool mindset shift — hard things have less competition.

- -

you'll notice this once you start contributing: easy issues always have a crowd. everyone's like "assign this to me!" meanwhile, the complex ones just sit there untouched. that's your time to shine. when you pick those tougher tasks, you stand out fast.

- -

and don't fall into the comparison trap. it's easy to feel small when you see people with years of experience contributing. but remember — everyone starts somewhere. even the best maintainers were beginners once. so don't let someone's fancy green github chart hypnotize you. focus on your lane.

- -

open source compounds over time. the more you contribute, the faster you get. your first few prs might take weeks, but later you'll do the same kind of work in days. every hard issue you solve today makes you 10x faster tomorrow. that's why staying consistent matters — because open source has crazy long-term roi if you just stick with it.

- -

don't chase perfection + blind confidence + pr/issue closures

- -

don't chase perfection — just ship it.

- -

a lot of people waste time endlessly tweaking their prs or adding "one more improvement." instead, once your code works, passes tests, and meets the requirements, just raise the pr. let the maintainer review it. done is better than perfect.

- -

also, blind confidence helps — especially when you're starting out. when i first got into open source, i took on a backend issue written in python even though i only knew typescript back then. i just said "yeah i'll fix it," learned on the go, and somehow pulled it off. sometimes you need that slightly overconfident push to grow.

- -

and if your pr or issue gets closed, chill. it happens to everyone. maybe the maintainer had a fight with his wife, or your idea didn't fit the project. no big deal. open source is full of different opinions — just respect that and move on. what matters is you tried and learned.

- -

aura boosters — being proactive, attention, and smart communication

- -

to level up your aura in open source, be hyper proactive — but not annoying.

- -

there are two types of people: the ones who talk about doing things, and the ones who just do it. always be the doer. instead of telling the maintainer, "i'll do this, i'll do that," just try it. make a quick proof-of-concept, raise a draft pr, show results, and then ask for feedback. that's how you earn respect fast.

- -

remember — maintainer attention is limited. big projects have tons of contributors and issues, so use their time wisely. before asking anything, see if google, chatgpt, or docs can solve it. 90% of answers already exist somewhere. only ping the maintainer when you've tried everything and still can't figure it out.

- -

and when you do ask, ask smart. frame your question clearly, short, and to the point. show that you've already done your homework. people are way more likely to reply if your message is crisp and easy to understand. this rule also works great for cold dms and emails — clarity gets attention.

- -

here's a dm i did to one of a guy i appreciate most and got his reply:

- - Ajeet's work screenshot - -

homework before asking + using the project + helping others

- -

before you ask for help, always do your homework.

- -

read the issue carefully, understand its context, and explore the repo a bit. in open source, no one's gonna spoon-feed you — you've gotta figure things out yourself first.

- -

one of the best hacks to understand a project deeply is to use it yourself. if it's a docs tool, use it to write your docs. if it's a web app, play around with it. when you see it from a user's perspective, you spot bugs, missing features, and potential improvements easily. that's how you start thinking like a product contributor, not just a coder.

- -

and help others. that's literally the spirit of open source — you help someone today, someone else helps you tomorrow. plus, teaching someone (even through text) forces you to understand things better yourself. people also notice contributors who help others — it naturally builds your reputation.

- -

code of conduct + knowing basics + patience + tracker doc

- -

read the code of conduct — seriously.

- -

almost every open source project has one, but barely anyone reads it. it usually explains how to contribute, whether you need permission to start on an issue, and what coding practices the project follows. it also covers simple but crucial stuff like being respectful, not spamming, or posting rude comments.

- -

taking 10–20 minutes to read it already puts you ahead of 80% of contributors. most skip it because it looks boring, but it actually gives you the rules of the game.

- -

next — know the basics.

- -

open source isn't for "absolute" beginners. you don't need to be a pro, but you should at least know how to fork and clone a repo, use branches, handle merge conflicts, push code, and keep things in sync. also, learn basic git terms like origin, upstream, fetch, and rebase. it won't take more than a day.

- -

and yeah — have patience.

- -

maintainers are busy. sometimes your pr might take days or even weeks to get reviewed. that's normal. while waiting, don't just sit idle — use that time to learn new stuff or pick another issue.

- -

to stay organized, maintain a simple tracker doc. i use one with four sections —

- -
    -
  1. to raise (issues you plan to raise)
    2. -
  2. to work on (issues you've picked)
    3. -
  3. in progress (what you're currently coding)
    4. -
  4. to review / get merged (prs waiting for review)
    5. -
- -

low / no aura things to avoid — the don'ts

- -

alright, let's talk about what not to do — the stuff that kills your aura fast.

- -

first — don't overping maintainers. their time is super limited, so avoid bothering them for small or googleable stuff. i've seen people spam maintainers like "can you assign me this issue?" again and again. sometimes, they even ping on a pull request instead of an issue 💀. don't be that person.

- -

second — no personal dms. messaging maintainers privately without permission is a big no. keep everything public unless they explicitly ask you to dm. open source thrives on transparency.

- -

third — don't pull others down. if someone's already working on an issue, don't try to snatch it or comment things like "can i take this?" unless they say they're leaving it. just move to another issue.

- -

fourth — don't move slow. once you take up an issue, stay active. being slow makes you forget context and gives the impression you're not serious. use your waiting time to learn or find new bugs — stay in motion.

- -

fifth — always follow the code of conduct. it's not optional. i once saw someone threaten a gsoc maintainer because they got rejected — total red flag. don't ever do that. same goes for stealing someone's work — you can learn from others' code, but don't copy-paste their prs or proposals. that'll destroy your credibility instantly.

- -

lastly — keep your promises. if you say you'll fix an issue, actually do it. missing deadlines again and again makes maintainers lose trust. start small, prove reliability first, and then go for bigger features once you're confident.

- -

beginner's dilemma + closing thoughts

- -

when you're new to open source, you'll face what i call the beginner's dilemma.

- -

you'll ask yourself things like —

- -
    -
  • what tools or tech do i need to know?
    • -
  • how do i find good issues to work on?
    • -
  • how do i pick the right project?
    • -
  • why is setting it up locally so damn hard?
    • -
  • why does everything feel so complex?
    • -
- -

and trust me — everyone goes through this. it's normal to feel stuck, lost, or even dumb sometimes. i've been there too. but that's exactly how you grow. every small win — cloning your first repo, fixing your first bug, getting your first pr merged — adds up fast.

- -

we'll dive deeper into all these beginner problems in upcoming modules — how to find beginner-friendly issues, how to pick projects that match your tech stack, how to set things up quickly, and how to stay consistent without burning out.

- -

todos:

-
    -
  • - ☐ - keep everything ive explained earlier in mind -
    • -
- -

so yeah, that's all for this one. this module was more of a mindset and theory piece, but honestly, these are the things most people skip — and end up making mistakes that cost them their aura.

- -

if you vibed with it, share it with other (coz i dont have a marketing budget), and this is ajeetunc. see you in the next module

- `, - videoUrl: "https://youtu.be/PHKy2izX2Hs?si=loy2Wy_iGwYMKPk7", -}; diff --git a/apps/web/src/data/sheet/module-10.ts b/apps/web/src/data/sheet/module-10.ts deleted file mode 100644 index b84ec730..00000000 --- a/apps/web/src/data/sheet/module-10.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module10: SheetModule = { - id: "module-10", - name: "Live fix/implement the issue - 2", - docContent: ` -

Live fix/implement the issue - 2

-

Second live session on fixing and implementing an issue in an OPEN SOURCE project.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-11.ts b/apps/web/src/data/sheet/module-11.ts deleted file mode 100644 index 3af0ae49..00000000 --- a/apps/web/src/data/sheet/module-11.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module11: SheetModule = { - id: "module-11", - name: "Live fix/implement the issue - 3", - docContent: ` -

Live fix/implement the issue - 3

-

Third live session on fixing and implementing an issue in an OPEN SOURCE project.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-12.ts b/apps/web/src/data/sheet/module-12.ts deleted file mode 100644 index 6d1df5a7..00000000 --- a/apps/web/src/data/sheet/module-12.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module12: SheetModule = { - id: "module-12", - name: "Live fix/implement the issue - 4", - docContent: ` -

Live fix/implement the issue - 4

-

Fourth live session on fixing and implementing an issue in an OPEN SOURCE project.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-13.ts b/apps/web/src/data/sheet/module-13.ts deleted file mode 100644 index 8f79fb7e..00000000 --- a/apps/web/src/data/sheet/module-13.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module13: SheetModule = { - id: "module-13", - name: "Raise PRs and fix the reviews", - docContent: ` -

Raise PRs and fix the reviews

-

Learn how to create pull requests and effectively address review comments from maintainers.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-14.ts b/apps/web/src/data/sheet/module-14.ts deleted file mode 100644 index d9ba4de4..00000000 --- a/apps/web/src/data/sheet/module-14.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module14: SheetModule = { - id: "module-14", - name: "How to tackle competition in saturated orgs?", - docContent: ` -

How to tackle competition in saturated orgs?

-

Strategies for standing out and getting your contributions noticed in highly competitive OPEN SOURCE organizations.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-15.ts b/apps/web/src/data/sheet/module-15.ts deleted file mode 100644 index e5fa9eb6..00000000 --- a/apps/web/src/data/sheet/module-15.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module15: SheetModule = { - id: "module-15", - name: "Get/pick your second issue assigned (medium)", - docContent: ` -

Get/pick your second issue assigned (medium)

-

Learn how to get your second issue assigned, focusing on medium difficulty issues.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-16.ts b/apps/web/src/data/sheet/module-16.ts deleted file mode 100644 index ae830f02..00000000 --- a/apps/web/src/data/sheet/module-16.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module16: SheetModule = { - id: "module-16", - name: "How to plan/discuss with maintainers?", - docContent: ` -

How to plan/discuss with maintainers?

-

Best practices for communicating and planning with project maintainers before starting work on issues.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-17.ts b/apps/web/src/data/sheet/module-17.ts deleted file mode 100644 index ae5ef70b..00000000 --- a/apps/web/src/data/sheet/module-17.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module17: SheetModule = { - id: "module-17", - name: "Live fix/implement the issue - 1", - docContent: ` -

Live fix/implement the issue - 1

-

First live session on fixing and implementing a medium difficulty issue.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-18.ts b/apps/web/src/data/sheet/module-18.ts deleted file mode 100644 index b9898620..00000000 --- a/apps/web/src/data/sheet/module-18.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module18: SheetModule = { - id: "module-18", - name: "Live fix/implement the issue - 2", - docContent: ` -

Live fix/implement the issue - 2

-

Second live session on fixing and implementing a medium difficulty issue.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-19.ts b/apps/web/src/data/sheet/module-19.ts deleted file mode 100644 index 2afb06ec..00000000 --- a/apps/web/src/data/sheet/module-19.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module19: SheetModule = { - id: "module-19", - name: "Live fix/implement the issue - 3", - docContent: ` -

Live fix/implement the issue - 3

-

Third live session on fixing and implementing a medium difficulty issue.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-2.ts b/apps/web/src/data/sheet/module-2.ts deleted file mode 100644 index 06fafa17..00000000 --- a/apps/web/src/data/sheet/module-2.ts +++ /dev/null @@ -1,189 +0,0 @@ -import { SheetModule } from "./types"; - -export const module2: SheetModule = { - id: "module-2", - name: "Get the basics done - prerequisites, tools and tips", - docContent: ` -

hey everyone, in this module we're gonna talk about the basics you need to know before contributing to open source — the tools, concepts, and a few practical tips to get started right.

- -

quick request though — please don't spam any open source repo i mention here. i'm using them just to explain stuff. making random prs just for numbers actually hurts projects, so be cool.

- -

what to learn before contributing

- -

first things first — learn git and github. they're not optional.

- -

and no, you don't need to master every command under the sun. you just need to understand the full workflow of open source contributions — how to fork, clone, branch, rebase, push, and make prs.

- -

forking & cloning

- -

so let's say you find a cool open source project.

- -

step one — fork it. when you fork, github creates a copy of that repo in your own account. this copy is yours to mess with — any changes you make affect your fork, not the main project.

- -

step two — clone it to your local machine.

- -

just grab the repo's url, open your terminal, and run:

- - 
git clone <repo-url>
- -

that downloads the project to your computer so you can actually make code changes.

- -

setting up locally

- -

now comes the "fun" part — setting it up.

- -

almost every project has a section called local development in its readme. it'll list tools you need — like nodejs, postgresql, or docker.

- -

honestly, i recommend learning docker. it saves tons of setup time and works almost everywhere. but you can do manual setup too if you prefer.

- -

and just know — setup errors are normal. everyone faces them. first, try fixing things using google or chatgpt. if you're truly stuck for a day or two, then ask in the community or tag a maintainer.

- -

branches & syncing

- -

you'll often create your own branch for each feature or fix.

- -

run:

- - 
git checkout -b fix-xyz
- -

this makes a new branch and switches you there.

- -

but since multiple contributors are working at once, your local copy can fall behind the main project. that's where syncing comes in.

- -

you can use either git merge or git rebase.

- -

merge combines changes but adds extra "merge commits" — can get messy.

- -

rebase keeps history clean and linear — i usually prefer this.

- -

if conflicts appear, open the files, decide which version to keep, delete the unwanted lines, then run:

- - 
git add .
-git rebase --continue
- -

boom, conflict fixed and you're good to go.

- -

cherry-picking commits

- -

sometimes your branch gets too messy — too many commits, too much noise.

- -

if you just want a few clean commits from another branch, use git cherry-pick <commit-hash>. it copies only that specific commit into your branch. huge time saver when cleaning things up.

- -

fetch vs pull (and how everything connects)

- -

here's a quick mental model:

- -
    -
  • upstream = the original repo you forked from
    • -
  • origin = your fork on github
    • -
  • local = your copy on your laptop
    • -
- -

git fetch gets updates from upstream without changing your local branch.

- -

git pull gets updates and merges them into your current branch.

- -

that's the basic flow:

- -

local → origin → upstream (via PRs), and upstream → origin → local (via pulls).

- -

pushing your branch & raising a PR

- -

once your changes are ready:

- - 
git add .
-git commit -m "fix: something"
-git push origin fix-xyz
- -

that pushes your branch to your github fork. you'll see a "compare & pull request" button — click it, write a short, clear description, and raise a pr.

- -

pro tip: raise draft prs early.

- -

don't wait until everything's perfect — just raise a draft once the core part is working. it helps maintainers see your progress, prevents duplication, and gets you feedback early. just don't spam with one-line drafts.

- -

stashing changes

- -

sometimes you're mid-work but don't wanna commit yet.

- -

you can stash your changes temporarily:

- - 
git stash save "my changes"
- -

to get them back later:

- - 
git stash apply
- -

this keeps your workspace clean while switching branches or testing something else.

- -

quick git tricks

- -

check commit history: git log --oneline

- -

create short aliases (like git ac for add + commit) in your shell config — saves time.

- -

there are plenty of short youtube guides for that.

- -

learn the basics of your stack

- -

besides git, know the basics of your programming stack.

- -

you should understand simple logic, loops, and core syntax. if you're into frontend, know your react/vue basics; if backend, know your frameworks; if infra or ai, know basic concepts like neural nets or containerization.

- -

you don't need to be an expert — just enough to make sense of what's happening in the code.

- -

finding projects by niche

- -

right now, there's no perfect tool to find open source projects by niche.

- -

but i'm building opensox.ai, which will let you filter projects by category — ai, infra, frontend, backend, etc. can't wait to ship that one.

- -

extra skills that help

- -

anything else you know — dsa, previous internship experience, math, or theory — is a bonus. for example, if you know dsa, it helps you contribute to low-level libraries faster. every bit of prior knowledge compounds.

- -

the "am i ready enough?" dilemma

- -

this is the most common question i get: am i ready to contribute?

- -

honestly — you'll never feel ready. even devs with years of experience hesitate at first.

- -

the best way to find out? just start. fork a repo, clone it, pick an issue, and go for it. you'll get stuck — that's where the learning happens.

- -

each time you hit a wall, ask yourself: what do i need to learn to fix this?

- -

need redis? learn it. need trpc? google it. learn just enough to solve the problem, fix it, move on, repeat.

- -

this "learn → apply → move" cycle will skyrocket your skills way faster than spending months watching tutorials or building yet another to-do app.

- -

of course, don't just stay on the surface — later, revisit the core concepts and learn them deeply. but for now, action > preparation.

- -

todos:

-
    -
  • - ☐ - practice these git commands once or twice -
    • -
  • - ☐ - get the basics of your tech stack (full stack, ai, web3, etc) done in one or two weeks -
    • -
  • - ☐ - learn naming conventions for branches, commits -
    • -
- -

closing thoughts

- -

so yeah — that's everything you need before diving into open source.

- -

git, github, a basic tech stack, and the courage to start even when you don't feel ready.

- -

don't wait for "perfect timing" — just fork, clone, and begin.

- -

you'll figure things out as you go, and that's where the real growth happens.

- -

this is ajeetunc. see you in the next module

- `, - videoUrl: "https://youtu.be/f-l7zO_J4HU?si=5Cc6IB6TAi3wjZ71", -}; diff --git a/apps/web/src/data/sheet/module-20.ts b/apps/web/src/data/sheet/module-20.ts deleted file mode 100644 index aee796e1..00000000 --- a/apps/web/src/data/sheet/module-20.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module20: SheetModule = { - id: "module-20", - name: "Live fix/implement the issue - 4", - docContent: ` -

Live fix/implement the issue - 4

-

Fourth live session on fixing and implementing a medium difficulty issue.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-21.ts b/apps/web/src/data/sheet/module-21.ts deleted file mode 100644 index b56a1ede..00000000 --- a/apps/web/src/data/sheet/module-21.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module21: SheetModule = { - id: "module-21", - name: "Live fix/implement the issue - 5", - docContent: ` -

Live fix/implement the issue - 5

-

Fifth live session on fixing and implementing a medium difficulty issue.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-22.ts b/apps/web/src/data/sheet/module-22.ts deleted file mode 100644 index 29979a88..00000000 --- a/apps/web/src/data/sheet/module-22.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module22: SheetModule = { - id: "module-22", - name: "Raise the PR and get it merged", - docContent: ` -

Raise the PR and get it merged

-

Learn the complete process of raising a pull request and getting it successfully merged into the project.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-23.ts b/apps/web/src/data/sheet/module-23.ts deleted file mode 100644 index b90be3b1..00000000 --- a/apps/web/src/data/sheet/module-23.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module23: SheetModule = { - id: "module-23", - name: "How to make impressive contributions part-1?", - docContent: ` -

How to make impressive contributions part-1?

-

First part of a guide on making standout contributions that get noticed in OPEN SOURCE projects.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-24.ts b/apps/web/src/data/sheet/module-24.ts deleted file mode 100644 index 7309370c..00000000 --- a/apps/web/src/data/sheet/module-24.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module24: SheetModule = { - id: "module-24", - name: "How to make impressive contributions part-2?", - docContent: ` -

How to make impressive contributions part-2?

-

Second part of a guide on making standout contributions that get noticed in OPEN SOURCE projects.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-25.ts b/apps/web/src/data/sheet/module-25.ts deleted file mode 100644 index b4ec0002..00000000 --- a/apps/web/src/data/sheet/module-25.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module25: SheetModule = { - id: "module-25", - name: "Get/pick your third issue assigned (medium-hard)", - docContent: ` -

Get/pick your third issue assigned (medium-hard)

-

Learn how to get your third issue assigned, focusing on medium to hard difficulty issues.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-26.ts b/apps/web/src/data/sheet/module-26.ts deleted file mode 100644 index 1e26bd1a..00000000 --- a/apps/web/src/data/sheet/module-26.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module26: SheetModule = { - id: "module-26", - name: "Live fix/implement the issue - 1", - docContent: ` -

Live fix/implement the issue - 1

-

First live session on fixing and implementing a medium-hard difficulty issue.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-27.ts b/apps/web/src/data/sheet/module-27.ts deleted file mode 100644 index bbdf8048..00000000 --- a/apps/web/src/data/sheet/module-27.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module27: SheetModule = { - id: "module-27", - name: "Live fix/implement the issue - 2", - docContent: ` -

Live fix/implement the issue - 2

-

Second live session on fixing and implementing a medium-hard difficulty issue.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-28.ts b/apps/web/src/data/sheet/module-28.ts deleted file mode 100644 index ff1c443f..00000000 --- a/apps/web/src/data/sheet/module-28.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module28: SheetModule = { - id: "module-28", - name: "Live fix/implement the issue - 3", - docContent: ` -

Live fix/implement the issue - 3

-

Third live session on fixing and implementing a medium-hard difficulty issue.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-29.ts b/apps/web/src/data/sheet/module-29.ts deleted file mode 100644 index 820135ca..00000000 --- a/apps/web/src/data/sheet/module-29.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module29: SheetModule = { - id: "module-29", - name: "Live fix/implement the issue - 4", - docContent: ` -

Live fix/implement the issue - 4

-

Fourth live session on fixing and implementing a medium-hard difficulty issue.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-3.ts b/apps/web/src/data/sheet/module-3.ts deleted file mode 100644 index 7b66033e..00000000 --- a/apps/web/src/data/sheet/module-3.ts +++ /dev/null @@ -1,154 +0,0 @@ -import { SheetModule } from "./types"; - -export const module3: SheetModule = { - id: "module-3", - name: "Explore and Select projects to contribute", - docContent: ` -

hey, welcome back. in the last module, we talked about what you need to know before contributing to open source. if you haven't watched that yet, go check out module 2 first — the modules are mostly independent, but watching them in order helps things click better.

- -

in this module, we're diving into something super practical — how to find open source projects and how to explore them properly. because honestly, finding good projects isn't as easy as it sounds. there are tons of repos out there — some great, some meh — and your job is to pick the ones worth your time.

- -

so let's get into it — i'll show you 10+ ways to discover awesome open source projects:

- -

way 1 — opensox.ai

- -

this one's built exactly for this purpose.

- -

head over to opensox.ai, click get started → find projects, choose your tech stack — say typescript — then adjust filters like popularity or competition level. hit search, and boom — you'll get a curated list of projects you can explore.

- -

ignore random personal projects and focus on official or company-backed ones. opensox gives you a good mix, but it's still improving, so you might see a few irrelevant ones here and there.

- -

way 2 — algora.io

- -

next up, algora.io.

- -

this site lists a ton of open source projects, especially those offering bounties. perfect if you're aiming for paid contributions.

- -

they also have a projects section, though you'll have to explore manually since there aren't filters. still, it's solid for discovering new repos like ts circuit, rasp, activepieces, and more.

- -

btw, you'll find this whole list in the discord community doc if you're part of it.

- -

way 3 — yc startup directory

- -

yc (y combinator) has a directory of startups, including many open source ones.

- -

just search "yc open source projects 2025" — click the first link — and you'll find companies like gitlab, docker, airbyte, skyvern, tip tap, and tons more.

- -

personally, i suggest exploring newer yc-backed projects. they're usually more open to new contributors and provide better mentorship and community engagement. older, massive ones like gitlab are great too but tend to have slower response times.

- -

way 4 — gsoc project list

- -

yeah, gsoc. the og of open source.

- -

search "gsoc project list" and open the organizations page. use the filters — for example, type "rust" and you'll get all rust-based orgs.

- -

each org page links to their website or repo, where you can join their community or explore issues. just a reminder — don't spam readme updates. contribute meaningfully.

- -

way 5 — github trending

- -

this one's simple but underrated.

- -

go to github.com/trending. you'll see projects blowing up right now — many are new and buzzing.

- -

you'll find established names like appsmith, meshery, zod, and a bunch of new ones. trending repos are gold because they show what's hot in the dev world.

- -

way 6 — open source communities (discord / slack)

- -

joining open source communities is a cheat code.

- -

when you join one, you naturally get exposed to many others because maintainers and founders share each other's announcements.

- -

so start with a few like appsmith, docs, or meshery. you'll usually find their discord or slack links on their landing page — scroll to the footer or "community" section.

- -

one community always leads to another — and soon you'll be looped into everything happening in the open source world.

- -

way 7 — twitter (x)

- -

twitter (okay, x) is another goldmine.

- -

most new open source launches, updates, and funding news drop there first.

- -

just follow people who are active in the open source ecosystem — contributors, founders, maintainers, or tech builders. i followed around 40–50 when i started, and that alone kept me updated daily.

- -

way 8 — funding news & newsletters

- -

follow sites like techcrunch, product hunt, hacker news, and mashable. they often cover open source startups that recently launched, got funded, or announced something big.

- -

you can also subscribe to newsletters like indie hackers, starter story, or mark lowe's newsletter. they aren't open source–only, but you'll still discover cool projects and communities through them.

- -

btw, i'm also launching an opensox newsletter soon that'll include curated open source updates every week.

- -

way 9 — follow active open source contributors

- -

this one's a secret gem.

- -

when you follow active contributors on github or twitter, you automatically get access to the projects they work on, the issues they solve, and the new repos they star or contribute to.

- -

but do this respectfully. don't dm random contributors asking for hand-holding. just quietly observe and learn — it's the easiest way to find high-quality projects and understand how top devs contribute.

- -

way 10 — oss friends

- -

this is one of my personal favorite tricks.

- -

many open source companies mention their "oss friends" — basically other open source projects they use or partner with.

- -

scroll to the footer of their site, look for "oss friends", "open source friends", or just "friends". click it, and you'll find a list of related projects — all open source too. it's like a mini-network of connected ecosystems.

- -

you can repeat this recursively — click one project, see its oss friends, and so on. total goldmine.

- -

how to explore and shortlist projects

- -

now that you've got a long list, the next step is exploring and shortlisting.

- -

you obviously can't contribute to all 100 — so pick around 10–15 projects that look interesting.

- -

make a simple doc (obsidian, notion, or even notepad) and list them. for each project, check:

- -
    -
  1. is the repo active? (recent commits, frequent prs, community chatter)
    2. -
  2. does it match your tech stack? no point joining a rust project if you only know typescript.
    3. -
  3. is the community active? check their discord — if no one replies for weeks, maybe skip it.
    4. -
  4. do they label issues clearly for contributors? good projects usually tag issues with good first issue, help wanted, or bounty.
    5. -
- -

every time you find one that fits, add it to your list. aim for 10, not 100 — focus is key.

- -

trimming your list

- -

once you've explored enough, narrow your 10–15 projects down to maybe 5 or 6 based on these filters:

- -
    -
  • high activity
    • -
  • solid maintainer/community support
    • -
  • tech stack you understand
    • -
  • meaningful issues you can actually work on
    • -
- -

this helps you focus your energy where it matters instead of spreading too thin.

- -

todos:

-
    -
  • - ☐ - using the above methods, explore and find 7-8 open source projects -
    • -
  • - ☐ - explore the selected open source projects deeply and trim down to 2-3 -
    • -
  • - ☐ - join the communities (slack, matrix, discord) of those 2-3 projects -
    • -
- -

final thoughts

- -

remember — these aren't hard rules. these are just proven ways to discover great projects. you might find your own methods too, and that's completely fine.

- -

the key is simple: don't overthink. explore, shortlist, start contributing. you'll figure things out as you go.

- -

so yeah, that's all for this module. hope it helps you discover your next favorite open source project. this is ajeetunc. see you in the next module

- `, - videoUrl: "https://youtu.be/bviwfDq-CTo?si=EwH1AFUpDM7p_FFy", -}; diff --git a/apps/web/src/data/sheet/module-30.ts b/apps/web/src/data/sheet/module-30.ts deleted file mode 100644 index 03050d6a..00000000 --- a/apps/web/src/data/sheet/module-30.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module30: SheetModule = { - id: "module-30", - name: "Raise the PR and get it merged", - docContent: ` -

Raise the PR and get it merged

-

Learn the complete process of raising a pull request for a medium-hard issue and getting it successfully merged.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-31.ts b/apps/web/src/data/sheet/module-31.ts deleted file mode 100644 index 32efb478..00000000 --- a/apps/web/src/data/sheet/module-31.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module31: SheetModule = { - id: "module-31", - name: "How to get jobs/internships through OPEN SOURCE?", - docContent: ` -

How to get jobs/internships through OPEN SOURCE?

-

Learn how to leverage your OPEN SOURCE contributions to land jobs and internships in the tech industry.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-4.ts b/apps/web/src/data/sheet/module-4.ts deleted file mode 100644 index 11a8605b..00000000 --- a/apps/web/src/data/sheet/module-4.ts +++ /dev/null @@ -1,18 +0,0 @@ -import { SheetModule } from "./types"; - -export const module4: SheetModule = { - id: "module-4", - name: "Adhoc: How to setup projects locally", - docContent: ` -

you don't need to read my yap in this module. just follow along with this video and set up any open source project locally.

- -

todos:

-
    -
  • - ☐ - just set up the projects locally that you selected in module 3 (if you didn't, wake up and do it now) -
    • -
- `, - videoUrl: "https://youtu.be/qAlz8279M5A?si=PJ3ZKCZBx8RqvgOk", -}; diff --git a/apps/web/src/data/sheet/module-5.ts b/apps/web/src/data/sheet/module-5.ts deleted file mode 100644 index 31be929a..00000000 --- a/apps/web/src/data/sheet/module-5.ts +++ /dev/null @@ -1,203 +0,0 @@ -import { SheetModule } from "./types"; - -export const module5: SheetModule = { - id: "module-5", - name: "Introduce yourself and familiarize", - docContent: ` -

hey everyone, welcome to module 5!

- -

in module 3 and 4, we talked about how to find good open source projects and how to choose which ones to contribute to.

- -

now, it's time to actually dive in — to learn how to understand a project's codebase, introduce yourself to the community, and start feeling at home inside a repo.

- -

quick reality check

- -

you don't need to know everything about a project to contribute.

- -

just yesterday, i met a guy who wasn't contributing because he thought he had to learn every single part of the tech stack before touching code. that's completely wrong.

- -

open source doesn't work like that. you learn while contributing — not before it.

- -

step 1 — joining the project

- -

for this example, i'll take browser use, a YC-funded open source project that builds ai-powered browser agents. super cool stuff.

- -

first, clone the repo locally and open it in cursor (or any ai-assisted editor).

- -

if you don't use cursor yet, please start — not for writing code, but for understanding it. it saves hours of manual digging.

- -

step 2 — read the code of conduct + contribution guide

- -

every open source project has these — sometimes hidden in the repo root.

- -

you don't need to memorize them, just skim to understand their style, policies, and dos/don'ts.

- -

avoid giving "linkedin vibes" when you join. don't drop a whole autobiography like:

- -

"hi i'm from xyz college, participated in 10 hackathons, worked on abc…"

- -

none of that matters. just say something like:

- -

"hey everyone, i'm new here. excited to help with <area>."

- -

and please — don't join saying "i want a job/internship." you earn that through consistent contributions, not by asking for it.

- -

step 3 — join their community

- -

most active projects have a discord or slack. join it. that's where maintainers discuss bugs, new ideas, and upcoming features.

- -

if you skip it, you'll keep asking basic questions that were already answered there — which can annoy maintainers.

- -

also, join their showcase channel if they have one — projects that highlight contributors' work usually have a great culture.

- -

step 4 — understand the tech stack

- -

head to the repo and check what language dominates the code.

- -

in browser use, it's ~98% python.

- -

use cursor or any ai tool to ask:

- -

"summarize the libraries and frameworks used in this project."

- -

you'll get a clear breakdown. for example, browser use uses:

- -
    -
  • chromium CDP (chrome devtools protocol) for browser automation
    • -
  • pydantic for data models
    • -
  • httpx, aiohttp, requests for api calls
    • -
  • openai, anthropic, google genai for llm support
    • -
  • rich, click, dotenv, pillow, numpy, etc.
    • -
- -

now here's the important part — you don't need to know them all.

- -

you just need a rough idea of what each one does.

- -

later, when you see an issue mentioning "pydantic" or "rich", you'll remember, "oh yeah, that's probably related to data validation or ui formatting."

- -

that tiny context saves hours later.

- -

step 5 — understand architecture

- -

now, use cursor again and ask it to:

- -

"map out the architecture and organization of this codebase."

- -

it'll usually show:

- -
    -
  • core layers — agent, tools, browser, dom, llm
    • -
  • architecture style — event-driven, async-first, modular
    • -
  • patterns — dependency injection, registry pattern, lazy imports
    • -
- -

don't panic if you don't know these terms yet.

- -

just note them down. later, when you actually contribute, you'll revisit and everything will start to click.

- -

remember: this step isn't about mastering the architecture — it's about familiarity.

- -

quick detour — what's CDP?

- -

CDP stands for chrome devtools protocol — basically a bridge between your code and the browser's brain.

- -

before CDP, you could open devtools manually (press F12), but there was no way to automate that programmatically.

- -

CDP fixed that.

- -

it lets your code send commands to the browser — like "click this button", "fill this form", "screenshot this page".

- -

it's literally how browser use automates actions — you tell the agent "fill this form for me", and under the hood, CDP executes those actions on chrome.

- -

so now you kinda get the magic behind it.

- -

step 6 — understanding the flow

- -

architecture tells you how the system is built.

- -

the flow tells you how data moves when you perform an action.

- -

for example, in browser use, there's a feature:

- -

"fill in this job application with my resume."

- -

to understand the flow, ask cursor:

- -

"explain the code flow for this feature step by step."

- -

and it'll map it like this:

- -
    -
  1. user triggers the command
    2. -
  2. agent gets created
    3. -
  3. agent collects data (DOM, browser state, tools, etc.)
    4. -
  4. LLM decides what to do next (click, type, upload, etc.)
    5. -
  5. those actions get executed via CDP
    6. -
  6. browser updates the DOM and returns results
    7. -
- -

this is how you build intuition. you don't need to understand every function — just how things connect.

- -

step 7 — read a few core files

- -

cursor will also tell you which files are key (like agent/service.py, apply_to_jobs.py, browser/session.py, etc.).

- -

open them, skim through, and note down what each roughly does.

- -

you'll start to notice patterns like "okay, this file handles browser actions" or "this one manages LLM communication."

- -

that's all you need at this stage.

- -

step 8 — don't get stuck in the learning loop

- -

this whole process — joining, reading, exploring, mapping flow — should take less than a day.

- -

don't spend weeks "understanding everything."

- -

if you wait until you know every tool, every function, every file, you'll never start.

- -

the goal is to gain enough familiarity to confidently pick small issues and learn as you go.

- -

what's next

- -

in the next module, we'll cover how to pick the right issues — because not every issue is beginner-friendly. we'll talk about which ones to start with, which ones to avoid, and how to build momentum without burning out.

- -

so yeah, that's it for this one.

- -

remember: you don't need to know everything — just start.

- -

learn, contribute, repeat.

- -

todos:

-
    -
  • - ☐ - whichever project you chose in the previous module, fork and clone it locally -
    • -
  • - ☐ - find CODE OF CONDUCT and CONTRIBUTING.md files and read them -
    • -
  • - ☐ - join their community - on slack, discord, etc -
    • -
  • - ☐ - understand the tech stack (you can follow the way ive mentioned here 08:10) -
    • -
  • - ☐ - understand the architecture like this 16:07 -
    • -
  • - ☐ - go through the code flow 33:34 -
    • -
- -

this is ajeetunc. see you in the next module

- `, - videoUrl: "https://youtu.be/wvl_SkMwbrU?si=HlFe4Kj9Tz2J_d6B", -}; diff --git a/apps/web/src/data/sheet/module-6.ts b/apps/web/src/data/sheet/module-6.ts deleted file mode 100644 index ef01ea53..00000000 --- a/apps/web/src/data/sheet/module-6.ts +++ /dev/null @@ -1,194 +0,0 @@ -import { SheetModule } from "./types"; - -export const module6: SheetModule = { - id: "module-6", - name: "Find the issues to work on", - docContent: ` -

hey, welcome back

- -

in this module, we're gonna talk about how to pick the right issue to work on — especially if you're just starting out.

- -

finding issues isn't the hard part. there are tons of them.

- -

the tricky part is choosing one that's actually right for you — something small, doable, and meaningful, without wasting hours or getting stuck for days.

- -

let's break that down:

- -

step 1 — start small (but meaningful)

- -

when you're new to an open source project, never start with a complex issue.

- -

your first goal isn't to "prove your genius" — it's to understand how contributions actually work in that project.

- -

so pick something small but useful — like fixing a minor bug, improving logs, or tweaking small functions.

- -

just avoid low-value stuff like "update readme" or "add full stops".

- -

step 2 — understanding issue types

- -

when you open the issues tab, you'll usually see a mix of two kinds:

- -
    -
  1. maintainer-created issues – made by the project's core team.
    2. -
  2. contributor-created issues – made by community members like you.
    3. -
- -

if it's a bug created by maintainers, you can usually start right away.

- -

but if it's a feature request by another contributor, always confirm with maintainers first — ask if they actually want that change before you spend time on it.

- -

step 3 — analyze one issue example (browseruse repo)

- -

let's look at a real one.

- -

there's a bug:

- -

"action field consistently missing in the response of llm."

- -

sounds simple, but let's read it.

- -

the user says that when using the deepseek LLM model, the action field isn't returned in the response. the logs show schema mismatches.

- -

that instantly tells us — this issue might need setting up the deepseek API or model locally. so we have to decide:

- -

is this a "first-issue" level problem or something that'll eat my whole weekend?

- -

if it looks like a multi-hour setup, skip it for now. you'll get there later.

- -

step 4 — using ai tools (like cursor) smartly

- -

to really understand what's going wrong, copy the issue text into cursor and ask:

- -

"where in the codebase is this issue occurring, and why?"

- -

cursor will instantly scan the repo and point to relevant files or functions (like chat.py or views.py) — giving you a clear idea of what's breaking.

- -

but don't jump straight to "fix this."

- -

instead, first ask why the issue exists — learn the cause before trying to patch it.

- -

step 5 — understanding the root cause

- -

in this deepseek issue, cursor explains that the schema defines action as a required field,

- -

but the deepseek model doesn't return that field in its response.

- -

so the problem isn't your code — it's a schema mismatch between your definition and deepseek's actual output.

- -

basically:

- -

the repo expects { action: ... } in every response,

- -

but the model is like "nah, not gonna send that."

- -

this kind of issue is super common in llm-based projects — when the model's schema handling differs from others like openai or anthropic.

- -

step 6 — check how hard it is to fix

- -

before deciding, ask cursor:

- -

"will fixing this require a deepseek api or local setup? and how long might it take?"

- -

cursor says:

- -
    -
  • you can test schema logic without an api
    • -
  • but you can't test full responses unless you have one
    • -
  • time estimate: around 30–60 minutes if you just handle schema validation
    • -
- -

so that's a green light — it's small, scoped, and fixable. perfect for a first issue.

- -

step 7 — plan the fix before writing code

- -

when cursor gives you possible fixes, don't just accept the first one.

- -

read them all, question them.

- -

ask things like:

- -
    -
  • "why is option one better than option two?"
    • -
  • "what could break if i try this approach?"
    • -
- -

your goal is to understand the logic, not just copy-paste ai suggestions.

- -

in this case, the recommended fix was to:

- -
    -
  1. add validation handling in chat.py around line 169–180
    2. -
  2. catch missing action errors and retry with a clearer prompt
    3. -
  3. update the schema description so it clearly marks action as required
    4. -
- -

once you understand that, then start implementing.

- -

step 8 — setting up environment + branch

- -

create a test api key for deepseek (openrouter gives free keys btw).

- -

add it to your env file.

- -

then create a clean branch like:

- - 
fix/action-field-missing
- -

short, clear, self-explanatory.

- -

never code directly on main.

- -

step 9 — be patient with yourself

- -

look, you won't nail every fix perfectly. and that's fine.

- -

the goal is to figure things out, not to look like a pro.

- -

i'm not some flawless coder — i mess up, get stuck, debug badly, and still somehow figure it out eventually. that's the real process.

- -

so if you get stuck — don't panic.

- -

use cursor, ask maintainers polite questions, and keep learning through each issue.

- -

step 10 — summary

- -

so here's the mindset recap:

- -
    -
  • start small but meaningful
    • -
  • confirm maintainer approval if needed
    • -
  • read the issue carefully
    • -
  • use ai tools to understand the root cause
    • -
  • estimate difficulty before committing
    • -
  • plan the fix, don't rush it
    • -
  • make a clean branch and start simple
    • -
- -

once you fix it, test locally → push → raise a pr.

- -

todos:

-
    -
  • - ☐ - watch this video to make sense of this yap -
    • -
  • - ☐ - following the steps mentioned, pick and understand an issue to work on further -
    • -
  • - ☐ - create a branch to work on that issue -
    • -
- -

and that's it for this module

- -

in the next one, we'll actually implement the fix, test it, and raise our first pull request together.

- -

until then — keep exploring, keep breaking things, and keep building your open source story

- -

this is ajeetunc. see you in the next module

- `, - videoUrl: "https://youtu.be/0U_v8WK48fo?si=1-oj2Rz7pxX8r_z6", -}; diff --git a/apps/web/src/data/sheet/module-7.ts b/apps/web/src/data/sheet/module-7.ts deleted file mode 100644 index abc401d0..00000000 --- a/apps/web/src/data/sheet/module-7.ts +++ /dev/null @@ -1,24 +0,0 @@ -import { SheetModule } from "./types"; - -export const module7: SheetModule = { - id: "module-7", - name: "Get/pick your first issue assigned (easy-med)", - docContent: ` -

this module is just the implementation of an issue we picked in the previous module.

- -

todos:

-
    -
  • - ☐ - just watch the video -
    • -
  • - ☐ - and follow along with your own issue. -
    • -
- -

this is ajeetunc. see you in the next module

- `, - videoUrl: "https://youtu.be/H-zCtw5c3uQ?si=wkPNFubBaVCwMS3f", -}; diff --git a/apps/web/src/data/sheet/module-8.ts b/apps/web/src/data/sheet/module-8.ts deleted file mode 100644 index facd285b..00000000 --- a/apps/web/src/data/sheet/module-8.ts +++ /dev/null @@ -1,12 +0,0 @@ -import { SheetModule } from "./types"; - -export const module8: SheetModule = { - id: "module-8", - name: "Adhoc: How to learn anything fast?", - docContent: ` -

Adhoc: How to learn anything fast while contributing?

-

Strategies and techniques for learning quickly while actively contributing to OPEN SOURCE projects.

- `, - videoUrl: "", - comingSoon: true, -}; diff --git a/apps/web/src/data/sheet/module-9.ts b/apps/web/src/data/sheet/module-9.ts deleted file mode 100644 index af4b8b1c..00000000 --- a/apps/web/src/data/sheet/module-9.ts +++ /dev/null @@ -1,187 +0,0 @@ -import { SheetModule } from "./types"; - -export const module9: SheetModule = { - id: "module-9", - name: "Live fix of the issue - Part-1", - docContent: ` -

module 9: extending the browser-use contribution

- -

note: as this module is implementation focused, try watching the video so that you can have better understanding.

- -

in this module we're continuing the contribution we started in module 8. in module 8 we began working on an issue in the browser-use repo, and here we'll extend that work.

- -

note: if you haven't watched module 7 and module 8, you should do that first — otherwise nothing in this module will make sense.

- -

checking the issue status

- -

so let's open the issue we were working on. it's already closed.

- -

four days ago, in module 8, we commented that we weren't able to reproduce the exact error described in the issue.

- -

now, someone else replied saying that when the error triggers, the whole system crashes and floods the terminal with a huge amount of errors, which makes it impossible to see the real root cause.

- -

he didn't attach screenshots, so we still didn't have full clarity.

- -

after that, the original issue creator replied and tagged me. he shared screenshots and explained the real behavior.

- -

understanding what the issue creator meant

- -

the contributor said:

- -

when the deepseek model returns a response without the action field, the error is added to the agent history, but the LLM doesn't react to that error.

- -

so even if the agent says "hey deepseek, action field is missing", deepseek still keeps responding without the action field.

- -

this creates a repeating loop of failures.

- -

the contributor also fixed a local FILE-URL security issue for himself, but clarified that the core bug has nothing to do with files — it's purely about deepseek not returning the required field.

- -

he then shared screenshots showing:

- -
    -
  • the schema has required fields: thinking, evaluation, previous_goal, memory, next_goal, action
    • -
  • deepseek returns everything except action
    • -
  • pydantic throws a validation error
    • -
  • agent retries, sends that error back
    • -
  • deepseek still doesn't fix itself
    • -
  • that means the failure multiplies
    • -
- -

this exactly matches what another commenter said earlier: multiple errors spam the terminal.

- -

so now we finally understand the real root cause.

- -

reproducing the issue properly

- -

since the real bug isn't tied to FILE-URL access or html parsing, we don't need to recreate the whole file scenario from module 8.

- -

the bug appears in any task as long as deepseek returns a response missing "action".

- -

we just need to run a task with deepseek, catch the output, and check agent history.

- -

the maintainer also pointed out where the missing check might live:

- -

browser_use.agent.service.Agent.get_model_output_with_retry()

- -

why the issue was closed without a PR

- -

now the important part: why did the maintainer close the issue with no PR?

- -

here's the maintainer's final comment:

- -

some models are unfortunately bad at obeying the structured output schema.

- -

we recommend using system_prompt_extension to explicitly describe the output format to the model.

- -

in short:

- -
    -
  • deepseek simply doesn't follow the schema
    • -
  • so this isn't a browser-use bug, it's a model behavior problem
    • -
- -

the library already provides a built-in solution:

- -

extend_system_message — a system-prompt extension that lets you explicitly tell the model how to format its output.

- -

so rather than patch browser-use for a model-specific issue, the correct fix is:

- -

use the system prompt extension to force deepseek to follow the required schema.

- -

that's why the maintainers didn't want a PR for this.

- -

lessons from the PR attempt by someone else

- -

another contributor opened a PR to "fix" this issue. the PR wasn't merged, and here are the mistakes worth learning from:

- -
    -
  • - ❌ - didn't get maintainer approval first — always ask maintainers before fixing unclear issues -
    • -
  • - ❌ - didn't fully understand the root cause — he attempted to fix a model-side issue at the agent level -
    • -
  • - ❌ - didn't use proper PR formatting — he didn't use "fixes #<issue-number>" or "addresses #<issue-number>", so Github couldn't auto-close anything -
    • -
  • - ❌ - no tests, no screenshots — always attach before/after results or output logs -
    • -
  • - ❌ - poor commit messages — commit messages should follow good conventions like "fix: missing action field validation" instead of random unclear messages -
    • -
  • - ❌ - didn't sign the CLA — most OPEN SOURCE projects require this before merging -
    • -
- -

learning these early will save months of frustration.

- -

what "system prompt extension" actually means

- -

extend_system_message lets you ADD extra instructions to the LLM without replacing the default system prompt.

- -

example:

- -

tell the model explicitly — "always include an action field in your response."

- -

this is like the "additional note" option in food-delivery apps: the system already knows your order, but you add a custom instruction like "please bring cutlery" or "don't ring the bell".

- -

same vibe here.

- -

so instead of hacking the agent code, you use the built-in system message extension to guide the model.

- -

problem solved.

- -

the wrap-up

- -

even though the issue got closed before we could raise a PR, we still learned a lot:

- -
    -
  • - ✓ - how to reproduce bugs -
    • -
  • - ✓ - how to interpret contributor comments -
    • -
  • - ✓ - how agent history works -
    • -
  • - ✓ - how retry loops create cascading failures -
    • -
  • - ✓ - how to ask clarifying questions -
    • -
  • - ✓ - how maintainers think about issues -
    • -
  • - ✓ - how to avoid bad PR habits -
    • -
  • - ✓ - how the model vs agent boundary works -
    • -
- -

in the next module, we'll pick another issue — ideally one we can actually fix and raise a PR for.

- -

this is ajeetunc. see you in the next module.

- `, - videoUrl: "https://youtu.be/hRMtIB-pkeE", - comingSoon: false, -}; diff --git a/apps/web/src/data/sheet/sheet.ts b/apps/web/src/data/sheet/sheet.ts index 4bac9177..8f3bf64d 100644 --- a/apps/web/src/data/sheet/sheet.ts +++ b/apps/web/src/data/sheet/sheet.ts @@ -1,70 +1,69 @@ +import fs from "fs"; +import path from "path"; +import matter from "gray-matter"; +import { marked } from "marked"; import type { SheetModule } from "./types"; -import { module0 } from "./module-0"; -import { module1 } from "./module-1"; -import { module2 } from "./module-2"; -import { module3 } from "./module-3"; -import { module4 } from "./module-4"; -import { module5 } from "./module-5"; -import { module6 } from "./module-6"; -import { module7 } from "./module-7"; -import { module8 } from "./module-8"; -import { module9 } from "./module-9"; -import { module10 } from "./module-10"; -import { module11 } from "./module-11"; -import { module12 } from "./module-12"; -import { module13 } from "./module-13"; -import { module14 } from "./module-14"; -import { module15 } from "./module-15"; -import { module16 } from "./module-16"; -import { module17 } from "./module-17"; -import { module18 } from "./module-18"; -import { module19 } from "./module-19"; -import { module20 } from "./module-20"; -import { module21 } from "./module-21"; -import { module22 } from "./module-22"; -import { module23 } from "./module-23"; -import { module24 } from "./module-24"; -import { module25 } from "./module-25"; -import { module26 } from "./module-26"; -import { module27 } from "./module-27"; -import { module28 } from "./module-28"; -import { module29 } from "./module-29"; -import { module30 } from "./module-30"; -import { module31 } from "./module-31"; -export type { SheetModule }; -export const sheetModules: SheetModule[] = [ - module0, - module1, - module2, - module3, - module4, - module5, - module6, - module7, - module8, - module9, - module10, - module11, - module12, - module13, - module14, - module15, - module16, - module17, - module18, - module19, - module20, - module21, - module22, - module23, - module24, - module25, - module26, - module27, - module28, - module29, - module30, - module31, -]; +// configure marked for rich markdown support +marked.setOptions({ + gfm: true, // github flavored markdown: tables, task lists, etc. + breaks: true, // line breaks +}); + +// cache modules in memory +let cachedModules: SheetModule[] | null = null; + +const contentDir = path.join(process.cwd(), "src/data/sheet/content"); + +function loadModules(): SheetModule[] { + if (cachedModules) { + return cachedModules; + } + + try { + if (!fs.existsSync(contentDir)) { + console.warn(`content directory not found: ${contentDir}`); + return []; + } + + const files = fs.readdirSync(contentDir); + const modules: SheetModule[] = files + .filter((file) => file.endsWith(".md")) + .map((file) => { + const filePath = path.join(contentDir, file); + const fileContent = fs.readFileSync(filePath, "utf8"); + const { data, content } = matter(fileContent); + // render markdown to html + const htmlContent = marked.parse(content) as string; + + return { + id: data.id || file.replace(".md", ""), + name: data.name || "Untitled", + videoUrl: data.videoUrl || "", + comingSoon: data.comingSoon ?? false, + docContent: htmlContent, + }; + }) + .sort((a, b) => { + // sort by module number extracted from id + const aNum = parseInt(a.id.replace("module-", "")) || 0; + const bNum = parseInt(b.id.replace("module-", "")) || 0; + return aNum - bNum; + }); + + cachedModules = modules; + return modules; + } catch (error) { + console.error("error loading sheet modules:", error); + return []; + } +} + +// server-side only function - do not export sheetModules directly +// use getSheetModules() instead for server components +export function getSheetModules(): SheetModule[] { + return loadModules(); +} + +export type { SheetModule }; diff --git a/apps/web/src/data/sheet/types.ts b/apps/web/src/data/sheet/types.ts index ea76a77f..cdafbb24 100644 --- a/apps/web/src/data/sheet/types.ts +++ b/apps/web/src/data/sheet/types.ts @@ -1,7 +1,7 @@ export interface SheetModule { id: string; // e.g., "module-0" name: string; // Module name - docContent: string; // HTML content for documentation + docContent: string; // HTML content for documentation (rendered from markdown) videoUrl: string; // YouTube URL comingSoon?: boolean; // If true, module is not yet available } From b51b9297699b9e04f8838cca10c56cf881e1685e Mon Sep 17 00:00:00 2001 From: Aman Raj <113578582+huamanraj@users.noreply.github.com> Date: Fri, 28 Nov 2025 19:47:37 +0530 Subject: [PATCH 02/36] fix: dynamic page for displaying sheet module content with a dedicated renderer and styling. --- .../src/app/(main)/sheet/[moduleId]/page.tsx | 100 +----------------- .../sheet/[moduleId]/sheet-content.module.css | 64 +++++++++++ .../components/sheet/SheetContentRenderer.tsx | 27 +++++ 3 files changed, 96 insertions(+), 95 deletions(-) create mode 100644 apps/web/src/app/(main)/sheet/[moduleId]/sheet-content.module.css create mode 100644 apps/web/src/components/sheet/SheetContentRenderer.tsx diff --git a/apps/web/src/app/(main)/sheet/[moduleId]/page.tsx b/apps/web/src/app/(main)/sheet/[moduleId]/page.tsx index da2a457c..9db0cc64 100644 --- a/apps/web/src/app/(main)/sheet/[moduleId]/page.tsx +++ b/apps/web/src/app/(main)/sheet/[moduleId]/page.tsx @@ -1,6 +1,8 @@ import { notFound } from "next/navigation"; import { getSheetModules } from "@/data/sheet"; import { SheetModuleHeader } from "@/components/sheet/SheetModuleHeader"; +import { SheetContentRenderer } from "@/components/sheet/SheetContentRenderer"; +import styles from "./sheet-content.module.css"; interface PageProps { params: Promise<{ moduleId: string }>; @@ -17,98 +19,6 @@ export default async function SheetModulePage({ params }: PageProps) { return ( <> -