# alisolanki/Welcome-to-Open-Source: a practice repo for your first pull request > The repository is a contributor wall, not a codebase. It exists so beginners can open a real pull request against a real GitHub project, and its README points elsewhere for the current list. **alisolanki/Welcome-to-Open-Source** — Make your first PR request! And enter the world of Open Source Contributions 🍉 - Repository: https://github.com/alisolanki/Welcome-to-Open-Source - Website: https://youtube.com/AliSolanki - Stars: 3,938 · Forks: 5,798 - Language: Unknown - License: not declared - Published: 2026-09-23 · Updated: 2026-09-23 · Language: en - Canonical page: https://hysenlabs.com/projects/alisolanki-welcome-to-open-source ## What the repository actually contains The top level of the master branch holds .DS_Store, .github/, .vs/, CONTRIBUTING.md and README.md. There is no application code, no build file and no package manifest. The README describes the project as a "List of actively participating individuals in open source contributions" and renders that list as an HTML table inside an all-contributors marker block. Each row is a table cell with an avatar image, a profile link and a name. The repository's stated purpose is to let a newcomer add their own details to that list and open a pull request. The topics attached to it (beginner-friendly, first-issue, contributions-welcome, no-code) match that purpose. So the audience is not a team looking for a library. It is someone who has never pushed a branch to a shared repository and wants one low-stakes attempt before touching a project where a mistake matters. ## How a contribution flows through the contributor table The mechanism is deliberately thin. A contributor edits README.md, adding a table cell that follows the existing pattern: an anchor to a GitHub profile, an avatar image with a width attribute, and a sub element containing the display name. The table sits between the ALL-CONTRIBUTORS-LIST:START and ALL-CONTRIBUTORS-LIST:END comments, and the README carries prettier-ignore-start and markdownlint-disable comments around that region. Those markers tell automated tooling to leave the block alone, which is why the table can hold inline HTML that a Markdown formatter would otherwise rewrite. The data flow is one-directional: your edit goes into a branch, the branch becomes a pull request, and a maintainer merges it or closes it. Nothing is generated, no CI job is described in the README, and the resulting artefact is a rendered table on the repository page. Because the merge is manual, the turnaround depends on the owner, and the README does not document a review timeline. ## Forking, editing and opening the pull request There is nothing to install and the repository ships no scripts. The README points to CONTRIBUTING.md for the steps to add yourself to the contributors list, and the work happens through the GitHub web interface or a local clone. The only URL the README gives for the repository is its own GitHub page, https://github.com/alisolanki/Welcome-to-Open-Source, and the file you edit is README.md. ```text https://github.com/alisolanki/Welcome-to-Open-Source ``` Open README.md and add a table cell inside the contributors table, copying the shape of an existing row. Keep the anchor, the img tag with its width attribute, and the sub element with your name. Then open the pull request against master from the GitHub interface. ```text README.md CONTRIBUTING.md ``` What you should see on the repository page is your avatar and name rendered in the table once the pull request is merged. If the formatting breaks, the usual cause is an unclosed tag or a cell placed outside the table body. ## The redirect in the README, and why it changes the decision The first block of the README is an announcement: "We've updated the Open Source Contribution List to a new home" and "Please make all your pull requests here (LATEST)", followed by the URL https://github.com/alisolanki/OpenSource-Github-Wall. That single paragraph is the most consequential fact about this repository. A newcomer who reads only the title and the topics will fork this repo, edit the table, and submit a pull request to a list the owner has already declared superseded. The README does not say the old list is frozen or that pull requests here will be rejected outright, and it does not give a date for the move. It simply tells you where the current list lives. Treat the contributor table on this repository as a historical record and send new entries to the other repository unless you have a reason to practise here first. ## Acceptance conditions beyond the diff The README states that a pull request is accepted only if the contributor does two things off GitHub: add a post on LinkedIn with the repository's link and a tag for the owner (Ali Solanki), and add a tweet with the repository's link tagging alisolankii. It also says channel members get priority access, linking to the YouTube membership page. This is the part most tutorials about first contributions never mention, and it is the part that makes this repository a poor fit for some people. The merge condition is not the quality of your edit; it is a promotional action on two other platforms. If you keep personal social accounts separate from your development work, or you are contributing on behalf of an employer with rules about public posting, the requirement is a real obstacle rather than a formality. Nothing in the README suggests an exemption, and no alternative path is documented. ## Where this repository is the wrong tool If you want to learn how a project's tests, CI configuration and review comments work, this repository will not teach you any of it. There is no test suite, no linter configuration beyond the markdownlint-disable comment, and no build. The .github/ directory may hold workflow files, but the README does not describe them and nothing in the repository listing confirms what they do. If you want a contribution that survives as a technical artefact, an HTML table row is not one. And if your goal is a résumé line about open source work, a contributor-wall entry carries little weight compared with a merged change to a project that ships code. The honest framing is that this is a rehearsal space. It is good at exactly one thing: letting you complete the fork, branch, commit, push and pull request loop without breaking anything that anyone depends on. Once you have done that loop once, the marginal value of doing it again here is close to zero. ## Alternatives with a different approach The closest alternative is the successor list named in the README, alisolanki/OpenSource-Github-Wall. Same author, same idea, current destination for pull requests. If your only goal is to appear on the wall, go there directly and skip this repository. A structurally different option is a project that pairs a beginner-sized task with real code, so the pull request you open is reviewed against tests and style rules. The trade-off is sharp: a real codebase teaches you review, CI failures and maintainer expectations, but your first attempt may be rejected on substance, and you need to find an issue that is genuinely scoped for a newcomer. The wall approach removes that risk and removes the learning that comes with it. A third path is documentation work in a project you already use, where you can verify the change against your own experience; that requires more reading than copying a table row, and it produces a change a maintainer can actually evaluate. ## Maintenance, licence and what to check before forking The repository is not archived and the last push was on 2026-03-04, which is more than six months before today, so treat it as quiet rather than actively developed. No releases are listed, which is consistent with a repository that has no software to release. The licence is not stated in the repository listing, and the top level holds no LICENSE file, so the terms under which the contents may be reused are unclear; if you intend to copy the table markup or the README structure into your own project, resolve that first rather than assuming a permissive default. There is no dependency to upgrade and no version to track, so the maintenance cost to a contributor is one edit and one pull request. The maintenance cost sits with the owner: a manual merge per entry, plus whatever the all-contributors markers imply for tooling. Verify two things before you spend time here: whether CONTRIBUTING.md still describes the same process as the README, and whether the successor repository is the one accepting entries. ## Conclusion Use this repository only if your goal is to rehearse the mechanics of forking, editing the contributors table, and opening a pull request where a rejection costs nothing. Do not use it if you want your name on the current wall, because the README states the list has moved to alisolanki/OpenSource-Github-Wall, and do not use it as a sample of application code, since the top level holds no source files. Before you start, open CONTRIBUTING.md and read the acceptance conditions in the README, which require a LinkedIn post and a tweet tagging the owner; decide whether you accept that trade before you fork. ## FAQ ### What is alisolanki/Welcome-to-Open-Source for? It is a repository whose README describes a list of people participating in open source contributions, rendered as a table of avatars and names. Contributors add their own details to that table and open a pull request, which the topics describe as beginner-friendly and no-code. ### Where should I send a new pull request for the contributor list? The README carries an announcement that the list has moved and asks contributors to make pull requests at https://github.com/alisolanki/OpenSource-Github-Wall instead. ### What are the conditions for getting a pull request accepted? The README states that you must add a LinkedIn post with the repository's link tagging Ali Solanki, and a tweet with the repository's link tagging alisolankii. It also says channel members get priority access. ### Is there anything to install to contribute? No. The change is an edit to README.md inside the contributors table, so the work is a fork, a branch, a commit and a pull request rather than a build or a package install. The README points to CONTRIBUTING.md for the steps. ### Is the repository still being updated? It is not archived, but the last push was on 2026-03-04 and no releases are listed. The README's own announcement redirects new contributions to another repository. ## Sources - [alisolanki/Welcome-to-Open-Source on GitHub](https://github.com/alisolanki/Welcome-to-Open-Source) - [Issues](https://github.com/alisolanki/Welcome-to-Open-Source/issues) - [Project website](https://youtube.com/AliSolanki) - [README](https://github.com/alisolanki/Welcome-to-Open-Source/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/alisolanki-welcome-to-open-source