Contribute to Open Source with GitHub

Add a vetted project listing and submit a review-ready GitHub pull request.

Introduction

30 Second Summary

Finding a welcoming place to help can take longer than making the change itself. A stale instruction or an already claimed idea can stop a promising first contribution before it starts.

In this project, you will add a tested Good First Issues card to the First Contributions catalog. Your duplicate-work checks on GitHub will support a focused pull request for maintainer review.

What You'll Build

You'll show a maintainer-ready pull request whose local preview displays a searchable Good First Issues card with verified project details.

By the end of this project, you'll have:

  • A searchable local catalog that returns the Good First Issues card when you look for it by name.
  • A vetted project listing that shows the verified avatar, current description, and five relevant tags.
  • A focused GitHub pull request whose Files changed tab shows only src/data/projects.js. Its description records your local test evidence.
  • Secret Mission: Audit your pull request like a maintainer by recording link, image, search, tag-filter, production-build, and issue-preview checks.

Are there any prerequisites?

You need basic Git knowledge plus a GitHub account on a Windows computer with GitHub Desktop and Visual Studio Code installed. The guide includes Node.js and pnpm setup when needed.

Before We Start

This quick checkpoint locks in the purpose of your contribution before the hands-on work begins. You are adding Good First Issues to the First Contributions catalog so new contributors can discover approachable work.

Prepare the Repository and Toolchain

A contribution cannot be tested confidently without the exact upstream repository. Reviewers also need evidence from the project's supported local toolchain.

You'll verify Node.js 24.20.0 LTS in PowerShell. You'll install pnpm 11.25.0 as the package manager.

You'll also clone the upstream project with GitHub Desktop. Visual Studio Code will open the current src/data/projects.js file from branch main.

In this step, get ready to:
  • Verify Node.js 24.20.0 LTS in PowerShell.
  • Install pnpm 11.25.0 globally.
  • Prepare the First Contributions repository for editing in Visual Studio Code.
Verify Node.js 24.20.0 LTS

Node.js runs the website's local development tools. Version 24.20.0 LTS gives you the pinned runtime for this project.

  • Press the Windows key to open search.
  • Type PowerShell.
  • Press Enter.
  • Check the installed Node.js version by running this command:
node --version

What does this command do?

The node --version command prints the Node.js release currently available in this PowerShell session. This result tells you whether the required runtime is ready.

✔️ I see the required version

Good. If PowerShell shows v24.20.0, Node.js is ready for the repository.

ⓧ I see an older version

Your current Node.js release is older than the pinned LTS release. The Windows installer may request permission to make changes to your computer.

  • Open the official Node.js release page.
  • Download the Windows installer that matches your computer's x64 or ARM64 architecture.
  • Run the downloaded installer.
  • Keep the default installation options.

Why reopen PowerShell?

A new PowerShell session picks up the runtime installed on Windows. Reopening it prevents the old session from reporting a stale version.

  • Close the current PowerShell window.
  • Press the Windows key to open search.
  • Type PowerShell.
  • Press Enter.
  • Confirm the installed Node.js version by running this command:
node --version

What does this check prove?

The command reads the Node.js version from your new PowerShell session. You should now see v24.20.0.

ⓧ Command not found

PowerShell cannot find a Node.js installation yet. The Windows installer may request permission to make changes to your computer.

  • Open the official Node.js release page.
  • Download the Windows installer that matches your computer's x64 or ARM64 architecture.
  • Run the downloaded installer.
  • Keep the default installation options.

Why reopen PowerShell?

A new PowerShell session loads the command locations registered by the installer. This gives Windows a fresh chance to find Node.js.

  • Close the current PowerShell window.
  • Press the Windows key to open search.
  • Type PowerShell.
  • Press Enter.
  • Confirm the installed Node.js version by running this command:
node --version

What does this check prove?

The command verifies that Windows can now find Node.js. You should see v24.20.0.

Still unable to verify Node.js?

  • Confirm that you downloaded the Windows installer matching your computer's x64 or ARM64 architecture.
  • Close every PowerShell window before repeating the version check in a new session.
  • Run the installer again if it closed before completing.
  • Help me troubleshoot my Node.js installation on Windows.
Install pnpm 11.25.0

The repository uses a committed pnpm-lock.yaml file to reproduce its dependency versions. Installing the pinned pnpm release prepares your computer to use that lockfile in the next step.

  • Install pnpm 11.25.0 globally from the PowerShell window by running this command:
npm install --global pnpm@11.25.0

What does this command do?

  • The npm install command downloads the requested package.
  • The --global option makes the pnpm command available outside one project folder.
  • The pnpm@11.25.0 package specification selects the exact release used in this project.
  • Check the active pnpm version by running this command:
pnpm --version

What does this check prove?

The pnpm --version command prints the pnpm release available in PowerShell. The pinned installation is ready when the output shows 11.25.0.

✔️ I see the pinned version

That package manager is ready. PowerShell now reports pnpm 11.25.0 for the repository.

ⓧ I see an older version

The required pnpm release is not active in the current session. Reinstall the pinned package before reopening PowerShell.

  • Install the pinned pnpm release again by running this command:
npm install --global pnpm@11.25.0

What does this command change?

The global installation targets pnpm release 11.25.0. Reopening PowerShell after it finishes refreshes the command available to your session.

  • Close the current PowerShell window.
  • Press the Windows key to open search.
  • Type PowerShell.
  • Press Enter.
  • Check the active pnpm release by running this command:
pnpm --version

What should the check show?

The new PowerShell session should print 11.25.0. That output confirms the pinned release is active.

ⓧ Command not found

PowerShell cannot find pnpm after the first installation attempt. Reinstall the package before refreshing the PowerShell session.

  • Install the pinned pnpm release again by running this command:
npm install --global pnpm@11.25.0

What does this command change?

The command installs pnpm release 11.25.0 as a global package. A new PowerShell session can then load the installed command.

  • Close the current PowerShell window.
  • Press the Windows key to open search.
  • Type PowerShell.
  • Press Enter.
  • Check whether PowerShell can find pnpm by running this command:
pnpm --version

What should the check show?

PowerShell should now print 11.25.0. This confirms the pnpm command is installed.

Still unable to run pnpm?

  • Run node --version again to confirm Node.js still reports v24.20.0.
  • Repeat the global installation command in a PowerShell window opened after the Node.js installation.
  • Close every PowerShell window before checking the pnpm version again.
  • Help me troubleshoot my pnpm installation on Windows.
Clone the First Contributions repository

A local clone gives you the current files from the upstream project. GitHub Desktop keeps the repository source visible while you work through the contribution workflow.

  • Press the Windows key to open search.
  • Type GitHub Desktop.
  • Press Enter.

GitHub Desktop may already know your GitHub account. If it asks for authorization, the sign-in flow may continue in your browser.

✔️ My GitHub account is shown

Your existing GitHub session is ready. You can continue directly to the clone controls.

ⓧ GitHub Desktop asks me to sign in

  • Complete the GitHub sign-in flow with your existing account.
  • Authorize GitHub Desktop if your browser requests access.
  • Return to GitHub Desktop after the browser confirms authorization.
  • Click File in the GitHub Desktop menu bar.
  • Click Clone Repository.
  • Select the URL tab.
  • Enter https://github.com/firstcontributions/firstcontributions.github.io in the repository URL field.
  • Keep the folder shown in the Local Path field.
  • Click Clone.

GitHub Desktop should show firstcontributions/firstcontributions.github.io as the current repository. The Current Branch control should show main.

  • Click Repository in the GitHub Desktop menu bar.
  • Click Open in Visual Studio Code.
  • Expand src in Visual Studio Code's left sidebar.
  • Expand data.
  • Select projects.js.

Before the final check, which versions do you expect PowerShell to report? Think about which repository branch should be open beside src/data/projects.js.

  • Switch back to the PowerShell window from the toolchain checks.
  • Verify both installed versions by running these commands:
node --version
pnpm --version

What does this final check prove?

  • The node --version command confirms the active Node.js runtime.
  • The pnpm --version command confirms the active package manager release.

You should see v24.20.0 for Node.js. You should see 11.25.0 for pnpm.

  • Switch back to GitHub Desktop.
  • Confirm the current repository is firstcontributions/firstcontributions.github.io.
  • Confirm Current Branch shows main.
  • Switch back to Visual Studio Code.
  • Confirm src/data/projects.js is visible in the editor.

That is the setup locked in. Your supported toolchain now points at a clean copy of the current upstream project.

Your repository is ready for a trustworthy baseline test. Next up, you'll run the unchanged catalog before proposing any contribution.

Run the Existing Project Catalog

Your repository and Windows toolchain are ready. The next goal is to run the unchanged catalog before you edit its data.

The committed lockfile defines the dependency graph for Astro 5.15.9. Reproducing that graph gives you a trustworthy baseline.

A working catalog proves your local setup. It cannot tell you whether a proposed contribution is still available.

In this step, get ready to:
  • Reproduce the repository's dependency graph without changing pnpm-lock.yaml.
  • Start the Astro development server from the repository folder.
  • Search the existing catalog for Python Koans to prove the baseline works.
Prepare a trustworthy dependency baseline

The committed pnpm-lock.yaml records the dependency versions used by the project. A frozen installation protects that file from unexpected updates.

The first installation can take a few minutes while pnpm downloads the dependency graph. A quiet terminal during that download is normal.

  • In Visual Studio Code's top menu, select Terminal.
  • Select New Terminal to open the integrated terminal panel.
  • Choose PowerShell from the terminal profile selector if another shell is active.
  • Confirm the PowerShell prompt path ends with firstcontributions.github.io.
  • Install the dependencies from the repository folder by running this command:
pnpm install --frozen-lockfile

What does this command protect?

  • The pnpm package manager installs the versions recorded in the committed lockfile.
  • The --frozen-lockfile flag prevents pnpm-lock.yaml from being generated or updated.
  • The command stops if the lockfile no longer matches the project manifest. This protects the shared dependency baseline.
  • Wait for the installation to finish and return control to the PowerShell prompt.
  • Switch back to GitHub Desktop from earlier.
  • Review the changed-file list and confirm pnpm-lock.yaml does not appear.

Good progress. Your local dependencies now match the committed graph with Astro 5.15.9 available to the project.

Dependency installation failed?

  • Confirm the terminal path ends with firstcontributions.github.io.
  • Repeat the Node.js and pnpm version checks from the previous step.
  • Copy the final lines of the terminal output before asking for help.
  • Help me diagnose this dependency installation failure.
Prove the catalog works locally

The development server turns the unchanged Astro project into a local website. It keeps the PowerShell terminal occupied while it runs.

  • Return to Visual Studio Code from earlier.

Before you start the site, do you expect the unchanged catalog to load with a working search result?

  • Start the development server from the repository folder by running this command:
pnpm run dev

What does this command do?

  • The pnpm package manager runs the repository's development script.
  • That script starts the local Astro development server.
  • The process stays active so your browser can keep loading the local website.

You should see a Local address printed by Astro. Keep this PowerShell terminal running while you test the catalog.

  • Record the address shown beside Local here: your local Astro address.
  • Press the Windows key to open Windows Search.
  • Search for your preferred web browser by name.
  • Select the browser from the search results.
  • Paste your local Astro address into the browser address bar.
  • Press Enter to load the local website.

You should see the existing project catalog with its search box and project cards.

  • Select the catalog search box.
  • Enter Python Koans into the search box.

You should see the Python Koans project card in the filtered results. That is your baseline working before any catalog data changes.

Can't load the catalog?

  • Keep the development process running in PowerShell while the browser is open.
  • Use the exact address printed beside Local in the terminal.
  • Clear any extra characters from the catalog search box.
  • Enter Python Koans exactly as shown.
  • Help me diagnose why the local Astro catalog is not loading or filtering.

With the baseline proven, you can investigate whether a promising project is already being proposed before you touch the catalog data.

Check for Duplicate Contributions

Your local Astro catalog is running, so the repository is ready for contribution work. The next risk lives outside your editor: another contributor may already be working on the same listing.

Duplicate-work checks compare the current file with active GitHub pull requests before you edit anything. You'll investigate AI Language Partner and let the evidence decide whether it is safe to claim.

In this step, get ready to:
  • Review issue #1 against the current main branch.
  • Search src/data/projects.js for AI Language Partner.
  • Check the candidate against the repository's active pull requests.
Review the contribution issue

Issue triage checks whether a request still matches the repository's current structure. Long-lived instructions can point to files that have moved since the issue was written.

Signing in links this browser to the GitHub account you already use. Your credentials stay inside GitHub's sign-in flow.

  • Open a new tab in the browser from earlier.
  • Sign in to GitHub with your existing account.
  • Visit issue #1.
  • Confirm the issue remains open.
  • Read the issue body to identify the request for more beginner-friendly projects.
  • Locate source/src/components/ProjectList/listOfProjects.js in the issue instructions.
  • Compare that path with the open src/data/projects.js tab in Visual Studio Code.

Good catch. The issue still welcomes project additions, but its original file path no longer matches the live main branch.

Why the current branch wins

Issue #1 defines the contribution goal. The live main branch defines where the current project data belongs.

Search the current project list

The catalog file shows which projects have already merged. A missing name makes AI Language Partner look available from that single viewpoint.

  • Return to Visual Studio Code from earlier.
  • Select the open src/data/projects.js tab.
  • Press Ctrl+F to search the file.
  • Enter AI Language Partner in the search field.
  • Confirm that no matching project object appears.

Your first check is solid. The merged catalog contains no AI Language Partner object, so the candidate appears available from the file alone.

Check the proposed pull request

A proposal can be absent from main while remaining active on another contributor's branch. Checking the pull-request queue closes the gap left by the file search.

Before you search, form a quick prediction about whether a missing catalog entry means AI Language Partner is available.

  • Switch back to the GitHub tab from earlier.
  • Select Pull requests in the repository navigation.
  • Enter AI Language Partner in the pull-request search field.
  • Press Enter to submit the search.
  • Open pull request #721 from the results.
  • Confirm that the pull request is open.

You'll see open pull request #721 titled Add AI Language Partner to project list. The earlier file-only check missed active work that has not merged.

That catch saves both contributors time. You have stopped a duplicate submission before changing any code.

Why this candidate stops here

AI Language Partner has no merged object in src/data/projects.js. Pull request #721 already proposes that exact addition.

A second proposal would split review effort across duplicate work. Leave this candidate unchanged.

Can't find pull request #721?

  • Clear any extra filters from the pull-request search.
  • Search for Add AI Language Partner to project list again.
  • Open pull request #721 directly.
  • Help me find pull request #721.

Your duplicate check stopped a redundant submission before any code changed. Next, you'll apply the same evidence-first process to a candidate that clears both checks.

Add and Test Good First Issues

The duplicate check on GitHub proved that an absent catalog entry can still have an active proposal. Your replacement candidate needs evidence that it fits the catalog and remains available.

Good First Issues gives you a duplicate-safe replacement for AI Language Partner. You will vet the repository before adding its card to the local site.

In this step, get ready to:
  • Vet Good First Issues against the catalog's beginner-friendly purpose.
  • Confirm that no matching listing pull request exists.
  • Add the project object before testing its build and local card.
Vet Good First Issues

A curated entry needs evidence that beginners can find approachable work in the listed repository. The license and contribution guide also show whether people can participate responsibly.

  • Return to the GitHub browser session from earlier.
  • Open the Good First Issues repository to confirm that it helps people discover good-first issues.
  • Open the repository's license file to confirm that it states Apache License Version 2.0, January 2004.
  • Open the contribution guide to confirm that contributors claim work before using a fork and descriptive branch.
  • Open the repository's issue tracker to confirm that it contains active work.
  • Open issue #156 to confirm that it is an open documentation task.

Strong work. You now have concrete evidence that Good First Issues is licensed for collaboration and provides a beginner-focused contribution path.

Check for duplicate pull requests

The catalog file can miss a project while an open pull request already contains it. A repository-wide pull request search closes that gap.

You should see No results matched your search. That result clears the candidate for your contribution at this moment.

Add the catalog object and test it

The Astro catalog reads each project from an object in src/data/projects.js. Your object supplies the card's text, image, destination, and filters.

  • Switch back to src/data/projects.js in Visual Studio Code.
  • Scroll to the closing bracket at the bottom of the project list.
  • Insert the Good First Issues object immediately above the closing bracket by pasting this code:
{
  name: "Good First Issues",
  imageSrc: "https://avatars.githubusercontent.com/u/63800323?v=4",
  projectLink: "https://github.com/drkrillo/good-first-issues",
  description: "Find Good First Issues to start collaborating in Open-Source.",
  tags: ["Python", "HTML", "GitHub Actions", "Open Source", "Good First Issue"],
},

What does this object do?

  • The name value gives the card its searchable title.
  • The imageSrc value uses the project owner's verified GitHub avatar.
  • The projectLink value sends learners to the canonical repository.
  • The description value explains the project's purpose on the card.
  • The tags value makes the project discoverable through five catalog filters.
  • Save src/data/projects.js.
  • Stop the development server in the PowerShell terminal with Ctrl+C.

Before you build, predict whether the new object will compile cleanly.

  • Build the production site from the repository root by running:
pnpm run build

You should see the production build complete without errors.

Good work. The production build now accepts your new catalog object.

Build not completing?

  • Compare every quote and comma in the new object with the reference below.
  • Confirm that the object sits inside the project list before its closing bracket.
  • Remove any extra characters copied above or below the object.
  • Help me debug the Good First Issues object in src/data/projects.js.

✔️ Awesome, I've got everything!

Your saved Good First Issues object passes the production build.

ⓧ I'd like to double check the full code

  • Compare your Good First Issues object in src/data/projects.js with this complete reference:
{
  name: "Good First Issues",
  imageSrc: "https://avatars.githubusercontent.com/u/63800323?v=4",
  projectLink: "https://github.com/drkrillo/good-first-issues",
  description: "Find Good First Issues to start collaborating in Open-Source.",
  tags: ["Python", "HTML", "GitHub Actions", "Open Source", "Good First Issue"],
},

Before you restart the site, predict which details should appear when the new card becomes the only search result.

  • Restart the development server from the repository root by running:
pnpm run dev

The terminal should print a Local address for the running site.

  • Return to the local catalog tab from earlier.
  • Refresh the local catalog page.
  • Enter Good First Issues in the catalog search box.
  • Confirm that the search returns one card named Good First Issues.
  • Confirm that the GitHub avatar loads on the card.
  • Confirm that the description reads Find Good First Issues to start collaborating in Open-Source..
  • Count the five tags named Python, HTML, GitHub Actions, Open Source, and Good First Issue.
  • Select the card's project link.

You should land on the canonical Good First Issues repository at https://github.com/drkrillo/good-first-issues.

Can't find the card?

  • Confirm that src/data/projects.js is saved.
  • Check that the new object remains inside the project list.
  • Confirm that the development server is still running in the PowerShell terminal.
  • Help me find why the Good First Issues card is missing from the local Astro catalog.

Your vetted project card now passes a production build and works in the local catalog. Next, you will isolate the change on a topic branch and offer it to the maintainers for review.

Publish a Review-Ready Pull Request

Your Good First Issues card works in the local catalog. Its production build has also passed.

Maintainers need a focused change they can inspect on GitHub. Publishing through GitHub Desktop turns your tested edit into a pull request that they can review.

In this step, get ready to:
  • Create a topic branch that isolates the catalog change.
  • Publish the branch to your fork for comparison with main.
  • Submit a pull request with local test evidence.
Create a focused topic branch

A topic branch gives one contribution its own history. A focused diff lets reviewers confirm that your pull request changes only the intended catalog file.

Why use a topic branch?

A topic branch keeps the catalog entry separate from main. This makes the contribution easier to review or update without disturbing your local baseline.

  • Switch back to GitHub Desktop from earlier.
  • Click Current Branch in the toolbar.
  • Click New Branch.
  • Enter add-good-first-issues as the branch name.
  • Click Create Branch.
  • Select src/data/projects.js in the changed-file list.
  • Confirm the diff contains one added Good First Issues object.

Do you see another changed file?

  • Pause before committing if the changed-file list includes anything besides src/data/projects.js.
  • Switch back to Visual Studio Code to revert the unrelated change.
  • Return to GitHub Desktop to confirm the extra file has disappeared.
  • Help me isolate the intended one-file change.

The commit button displays your topic branch name in place of BRANCH.

  • Enter Add Good First Issues to project list in the Summary field.
  • Click Commit to BRANCH.

That is the local handoff prepared. GitHub Desktop should now show no remaining file changes on add-good-first-issues.

Publish the branch to your fork

The upstream repository controls what can be merged into the live site. A fork is your own copy on GitHub where you can publish the branch before proposing it upstream.

  • Click Publish branch in GitHub Desktop.

GitHub Desktop asks how you plan to use the fork because your account does not have direct write access to the upstream repository.

  • Choose To contribute to the parent project.
  • Click Continue.

Good work. Your topic branch is now published to your GitHub fork.

Branch publication not completing?

  • Confirm GitHub Desktop still shows your signed-in GitHub account.
  • Check that your computer has an active internet connection.
  • Retry Publish branch after the connection is restored.
  • Help me publish my contribution branch from GitHub Desktop.
  • Click Preview Pull Request.
  • Confirm the base repository is firstcontributions/firstcontributions.github.io.
  • Confirm the base: branch is main.

The preview should compare your published topic branch with the upstream main branch.

Submit the pull request with evidence

A pull request description gives maintainers the context needed to evaluate your proposal. Your local checks show that the new card works without disrupting the project build.

  • Click Create Pull Request in GitHub Desktop.

GitHub opens the pull request form in your signed-in browser.

What should the description prove?

  • The text Addresses #1 connects the proposal to the open project-list issue.
  • The command pnpm install --frozen-lockfile records how you installed the committed dependency graph.
  • The command pnpm run build records the successful production build.
  • The local card checks confirm the search result, avatar, description, five tags, and canonical project link.
  • Enter Add Good First Issues to project list in the pull request title field.
  • Write a concise description containing the issue reference and the verification evidence above.

Submitting makes your proposal visible to the upstream maintainers. The change remains under review until they decide whether to merge it.

  • Click Create Pull Request in the browser.
  • Refresh the new pull request page to confirm its URL loads.

You should see the open pull request page under firstcontributions/firstcontributions.github.io.

Can't load the pull request page?

  • Confirm the browser is signed in to the same GitHub account used by GitHub Desktop.
  • Return to GitHub Desktop to confirm add-good-first-issues finished publishing.
  • Retry the pull request creation after confirming the published branch.
  • Help me find why my new pull request page is not loading.
  • Copy the working pull request URL from the browser address bar.
  • Return to issue #1 in the browser from earlier.
  • Post the pull request URL in the contribution thread to request review.

Before the final audit, which single file do you expect the pull request to show?

  • Return to the pull request tab from earlier.
  • Confirm the base repository is firstcontributions/firstcontributions.github.io.
  • Confirm the base branch is main.
  • Confirm the description contains Addresses #1 plus your local test evidence.
  • Click the Files changed tab.
  • Confirm the tab contains only src/data/projects.js.

You have submitted a focused open-source contribution for maintainer review. The pull request now shows one changed file with the tested Good First Issues catalog entry.

Secret mission

Secret Mission: Audit the Listing Like a Maintainer

Your pull request is open for review. Audit the evidence behind its one-file diff with a maintainer's caution. Document every result in a concise comment.

Clean Up Your Resources

Clean Up Your Resources

Your local clone and GitHub resources are free to keep, so there are no ongoing costs. Choose whether to keep everything available, pause the local server, or remove the clone and fork after review finishes.

Resources you used:

  • The local clone of firstcontributions/firstcontributions.github.io at the path you selected in GitHub Desktop. It contains the installed project dependencies, your updated src/data/projects.js file, and the local add-good-first-issues branch.
  • Your GitHub fork of firstcontributions/firstcontributions.github.io. It contains the published add-good-first-issues branch.
  • The Astro development server process, if the local catalog is still running.

Protect Your Open Pull Request

Your fork holds the published branch behind the pull request. Keep the fork while maintainers are reviewing your work.

Delete the fork only after the pull request is merged or closed.

Keep everything running

No action is needed. Choose this option if you want to respond to review comments or continue improving your contribution.

  • Keep the local clone so you can test any changes requested by maintainers.
  • Keep the GitHub fork so the published topic branch remains available.
  • Keep the add-good-first-issues branch so future commits stay isolated from main.

Pause - I'll come back to this later

Stop the local development server to free up the terminal. Keep the clone, fork, branch, and pull request ready for future review work.

  • Switch back to the PowerShell terminal in Visual Studio Code.
  • Stop the Astro development server by pressing Ctrl+C in the terminal where it is running.
  • Leave the local add-good-first-issues branch in place.
  • Leave the fork and open pull request available for maintainer review.

Your workspace is now quiet. The pull request remains available when you are ready to continue.

Delete - I don't want to use this again

Deleting the local clone and fork is permanent. Wait until the pull request is merged or closed before continuing.

  • Confirm that the pull request is merged or closed.
  • Stop the Astro development server by pressing Ctrl+C in the terminal where it is running.

Your local site is now stopped, so no running process is using the clone.

  • Switch back to GitHub Desktop.
  • Find the current repository's local path in its repository information.
  • Record that path here: your local clone path.
  • Close Visual Studio Code.
  • Close GitHub Desktop.

The clone is now ready to remove from your computer.

  • Press the Windows key to open the search bar.
  • Type File Explorer into the search bar.
  • Press Enter.
  • Navigate to the parent folder of your local clone path.
  • Select the clone folder.
  • Press the Delete key.
  • Approve the Windows confirmation if it appears.
  • Empty the Recycle Bin when you are ready to remove the files permanently.
  • Return to the folder that previously contained the clone.

You should no longer see the clone folder in its former location.

  • Return to GitHub in the signed-in browser from earlier.
  • Open your fork of firstcontributions/firstcontributions.github.io.
  • Open the repository settings.
  • Scroll to the destructive actions section.
  • Select the repository deletion option.

GitHub asks you to confirm the exact repository name. It may also ask you to verify your identity before permanent deletion.

  • Copy the repository name shown in the deletion confirmation.
  • Paste the repository name into the confirmation field.
  • Complete any identity confirmation that GitHub requests.
  • Confirm the repository deletion.
  • Return to your GitHub repositories list.

You should no longer see the fork in your repository list. Your local clone is also gone, so the project resources are cleaned up.

Nice Work!

Nice Work!

You did it! You published a focused open-source GitHub pull request that adds Good First Issues to the First Contributions catalog for maintainer review.

You've learned how to:

  • Run an unfamiliar Astro site locally with its pinned toolchain. Prove the searchable project catalog works before editing it.
  • Prevent duplicate work by checking the current catalog. Search open pull requests before starting a candidate listing. Catch the existing AI Language Partner proposal before opening a competing change.
  • Publish a review-ready pull request with a one-file diff. Link it to issue #1. Include local test evidence for the Good First Issues card.
  • Secret Mission: Complete a maintainer-style audit of your listing. Verify the canonical project link. Confirm the avatar loads. Test the search result plus a tag filter. Rerun the production build. Explain the assignment risk behind omitting loadIssues: true.

Ready to quiz yourself?