# fineanmol/Hacktoberfest2026: a beginner's first pull request, without a build step > A static-site practice repository where the contribution itself is adding your name to a JavaScript list. It is a first-PR sandbox, not a library, and the README says so. **fineanmol/Hacktoberfest2026** — Make your first Pull Request on Hacktoberfest 2026. Don't forget to spread love and if you like give us a ⭐️ - Repository: https://github.com/fineanmol/Hacktoberfest2026 - Website: https://fineanmol.github.io/Hacktoberfest2026/ - Stars: 2,640 · Forks: 8,598 - Language: JavaScript - License: GPL-3.0 - Published: 2026-09-28 · Updated: 2026-09-28 · Language: en - Canonical page: https://hysenlabs.com/projects/fineanmol-hacktoberfest2026 ## The problem is the first pull request, not the code Most open source projects assume you already know the mechanics: fork, branch, commit, push, open a pull request, resolve a conflict. The README for fineanmol/Hacktoberfest2026 states plainly that it is "a beginner-friendly project to help you get started with your hacktoberfest". The intended user is someone with a GitHub account who has signed up for Hacktoberfest and has never opened a pull request, or has opened one and watched it go wrong. The repository is a static website plus a JavaScript contributors list. There is no application logic to understand, no test suite to satisfy, and no domain knowledge required. That narrows the audience considerably. If you already contribute to open source, this repository offers you nothing except a name in a list. If you have never done it, the small scope is the point: the only thing that can fail is the Git workflow, which is the thing you are there to practise. ## How the repository is put together The top level holds index.html, css/, contributors/, scripts/, and a set of process files: CONTRIBUTING.md, CONTRIBUTING.template.md, CODE_OF_CONDUCT.md, pull_request_template.md, README.template.md and site-meta.json. There is a .nojekyll file, which is the marker GitHub Pages uses to skip Jekyll processing, and the project is published at fineanmol.github.io/Hacktoberfest2026. The .htmlvalidate.json file and the scripts/ directory are the only hints of automation in the layout. The contribution target is contributors/contributorsList.js. The README instructs contributors to "Add your name to contributors/contributorsList.js", which means the data flow is: a contributor edits one JavaScript file, commits it, pushes a branch, and opens a pull request; a maintainer merges it and the static site picks up the new entry. No package manager, no bundler, no server. The README is explicit about this constraint: "Do NOT add any build steps e.g npm install (we want to keep this a simple static site)". That constraint is also the repository's main design decision. A static site with a hand-edited JavaScript array has no dependency graph to break, which is why a beginner can be trusted with it. It also means there is nothing here to test in the conventional sense, and the README's own rules lean into that: "Styling/code can be pretty, ugly or stupid, big or small as long as it works". ## Fork, clone, branch, and add your name The README gives the sequence directly. Fork the repository with the button on the GitHub page, then clone your fork. The clone command in the README points at the upstream URL, so substitute your own fork's URL if you want to push to it. ```bash git clone https://github.com/fineanmol/Hacktoberfest2026.git cd Hacktoberfest2026 ``` Create a branch for your change. The README uses the name my-new-branch; any descriptive name works. ```bash git checkout -b my-new-branch ``` Now edit contributors/contributorsList.js and add your name to the list. This is the entire substantive change. After saving, stage and commit: ```bash git add . git commit -m "Relevant message" git push origin my-new-branch ``` Then open a pull request from your fork on GitHub. The repository ships a pull_request_template.md, so the form you see will ask for the details the maintainers want. If you want to see the site locally, it is a static page: opening index.html in a browser is the only step the README implies, because it forbids installing anything. ## Conflicts are the real curriculum, and the README says so The README warns that "there are alot of conflicts, we are not merging until all conflicts get resolved" and that contributors should "Try to keep pull requests small to minimize merge conflicts". That is an unusual admission from a project page, and it tells you what the actual experience will be. Many people edit the same single file at the same time, so your branch will frequently fall behind master. The README's remedy is to add the original repository as an upstream remote and merge from it regularly: ```bash git remote add upstream https://github.com/fineanmol/Hacktoberfest2026 git remote -v git merge upstream/master ``` The first command registers the remote, the second verifies it, and the third pulls new commits into your branch, surfacing conflicts while they are still small. Run it between your own commits rather than once at the end. This is the part of the exercise with real transferable value: conflict resolution on a one-line change in a file you fully understand is the easiest version of a problem that is much harder in a production codebase. One caveat worth stating plainly. The README also says "You are allowed to make pull requests that break the rules. We just merge it", which contradicts the rule list above it. Treat the rule list as the real policy and the sentence as a joke, or ask in the pull request before relying on it. ## What this repository is not good for The README points contributors to a second repository, fineanmol/hacktoberfest, saying that "There we are merging all PR" and that in the current repository conflicts block merges. If your goal is a merged pull request rather than practice with the workflow, that statement matters more than anything else on the page. Beyond that, three limitations are structural. First, there is no code review of substance: the change is a name in a list, so you will not learn how maintainers evaluate design, tests or performance. Second, the no-build-step rule means you cannot practise packaging, dependency management or CI configuration here, even though the repository has a scripts/ directory and a .htmlvalidate.json file that suggest some automation exists. Third, the project is tied to an annual event. The README's own FAQ describes Hacktoberfest 2026 as running "from 1st october to 31st october 2026", and the page carries an image at /scripts/Event_Completed_.png. Activity outside that window is likely to be thin, and the maintainers state that "time is limited and the merge conflicts are horrible". The last push to the repository was on 2026-09-15, and the most recent release is v4.1.0 ("v4.1.0: 2026 site refresh & CI automation") from 2026-06-06. That release title is the only evidence of CI work in the repository files; the README documents no pipeline, no test command and no deployment step. ## Alternatives: a real project versus a practice ground The closest alternative is to skip the practice repository and contribute directly to a small project that interests you, using its issue tracker to find a labelled beginner issue. The difference in approach is the review loop. Here, a maintainer merges a name into a list and the feedback you get is about Git. There, a maintainer reads your diff and tells you what is wrong with it, which is the skill you actually need. The cost is a higher chance of a rejected pull request on your first attempt. A second alternative is contributing to the sibling repository the README recommends, fineanmol/hacktoberfest. According to the README, that is where pull requests are being merged while this one is blocked on conflicts, so it is the better target if a merged pull request is your objective rather than the practice itself. A third option is a documentation-only contribution to any project you already use. It keeps the low barrier of this repository, since documentation changes rarely require a build, while placing your work somewhere that reviewers will read it. The trade-off is that you must learn the project's conventions first, which is exactly the friction this repository removes. ## Licence, maintenance and what a contribution costs you The repository is licensed GPL-3.0. For a static site and a contributors list, the practical effect is limited, but it is worth knowing before you copy code out of index.html or css/ into another project: GPL-3.0 is a copyleft licence, and reusing the code carries obligations that permissive licences do not. This is a description of the licence, not legal advice; read the LICENSE file and, if the distinction matters to your employer, ask someone qualified. Upgrade cost is close to zero in the usual sense, because there is nothing to upgrade. You do not install this repository, you do not depend on it, and it has no version you pin. The cost is instead in time: cloning, branching, editing one file, pushing, and then repeatedly merging upstream/master to keep the branch current. The README's own closing note sets expectations, stating that the maintainers "will do our best to merge as much as possible from everyone. However, time is limited". Maintenance signals are mixed. The repository is not archived and the last push was 2026-09-15, which is recent enough to suggest someone is still touching it. But the README simultaneously says merges are paused until conflicts are resolved and points contributors at a different repository for merges. Read both statements before you invest an evening in a branch. ## Conclusion Adopt this repository if you have never opened a pull request and want the mechanics of fork, branch, commit, push and merge conflict under your belt before touching a real codebase. Do not adopt it if you are looking for a maintained library, a dependency, or a place to practise test-driven changes: the README forbids build steps and the project is a static site with a contributors list. Before contributing, check the README's own warning that conflicts in this repository are not being merged until they are resolved, and read CONTRIBUTING.md and pull_request_template.md, which are the files that actually govern what a maintainer will accept. ## FAQ ### What is fineanmol/Hacktoberfest2026 and what does it do? It is a beginner-friendly static website that exists so people can make their first pull request during Hacktoberfest. The contribution is adding your name to contributors/contributorsList.js, and the README states that no build steps such as npm install should be added. ### Who can contribute to fineanmol/Hacktoberfest2026? The README's FAQ says anyone with a GitHub account who is signed up for Hacktoberfest can contribute. It also asks contributors to add their name to contributors/contributorsList.js and to keep pull requests small to minimize merge conflicts. ### What are the benefits of contributing to fineanmol/Hacktoberfest2026? The README frames it as practice: a place to learn how to fork, branch, commit, push and open a pull request on a simple static site. Its FAQ also notes that four merged pull requests were the threshold for a Hacktoberfest T-shirt and stickers as of 2021. ## Sources - [fineanmol/Hacktoberfest2026 on GitHub](https://github.com/fineanmol/Hacktoberfest2026) - [License: GPL-3.0](https://github.com/fineanmol/Hacktoberfest2026/blob/master/LICENSE) - [Project website](https://fineanmol.github.io/Hacktoberfest2026/) - [README](https://github.com/fineanmol/Hacktoberfest2026/blob/master/README.md) - [Releases](https://github.com/fineanmol/Hacktoberfest2026/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fineanmol-hacktoberfest2026