Dev.to · 5 min read

What a first-contribution ranking actually weighs

What a first-contribution ranking actually weighs

Ask five developers what makes a good first open-source project and you will hear five different weightings. Porchlamp makes that explicit: it scores every project on five pillars, and what you see depends on how those pillars are weighted. This post reads the list a newcomer actually sees: what the first-timer lens weighs, which projects come out on top, and what the caveats beside each row mean. What the lens weighs The five pillars are Responsiveness, Criticality, Governance, Rigor and Accessibility. A lens, which the site calls a persona, is a weighting of those five. Balanced is the default, and besides it and First-timer there are Career capital, Senior systems and AI-assisted. Pillar First-timer weight Responsiveness 0.35 Accessibility 0.30 Governance 0.15 Criticality 0.10 Rigor 0.10 Responsiveness and Accessibility together outweigh the other three pillars combined. For a newcomer, then, the ranking is mostly two questions: do humans answer outside contributors, and how easy is it to get a first change in? That is a deliberate design choice, which is the point of having a lens. The top nine Snapshot of 14 October 2026, read from the live page on 16 October 2026. Rank Repository Ecosystem Score Coverage Tier Quadrant Delta vs balanced 1 ggml-org/llama.cpp systems 87.17 64% B (capped) Sweet Spot +2 2 meshery/meshery npm 84.88 63% B (capped) Sweet Spot -1 3 nexu-io/open-design npm 84.01 69% B (capped) Sweet Spot +63 4 stdlib-js/stdlib npm 83.73 64% B (capped) Nursery +49 5 ant-design/ant-design npm 83.68 63% B (capped) Sweet Spot +5 6 organicmaps/organicmaps systems 83.63 85% A (capped) Sweet Spot +7 7 apache/maka npm 82.93 69% B (capped) Sweet Spot +45 8 kubernetes-sigs/cluster-api go 82.80 85% A (capped) Sweet Spot +10 9 freeCodeCamp/freeCodeCamp npm 82.50 63% B (capped) Sweet Spot none shown The ecosystem column names the sampling frame a project was drawn from - this snapshot has six of them, crates, go, maven, npm, pypi and systems - so it is not a description of the project itself. I have left the quadrant labels undefined; the site's own explanation is the place to read them. Reading the delta column The last column is labelled delta rank, and in the Configure view its heading is "Rank deltas vs balanced". It is the project's rank under the Balanced lens minus its rank under the lens you have chosen. So open-design sits 63 places higher in the first-timer lens than in the balanced one, stdlib 49 places higher and apache/maka 45. Meshery's -1 means it is one place lower under the first-timer weighting. What it is not: it is not movement over time, not "rose since last week", and not momentum. Nothing about the projects changed between the two rankings; only the weights did. The column appears only when a lens other than Balanced is selected, and freeCodeCamp's row shows no delta on the page. A large positive delta says the project's strengths sit in the pillars this lens weights up. That is my reading, so open the pull requests behind its verdict before concluding anything. Reading coverage and the caps Coverage is how much of a project's evidence was actually measurable. Below 0.60 a project is not ranked at all. Below 0.80 its tier is capped at B, below 0.95 at A, and 0.95 and above is labelled Full. Across the whole sample, 3,833 projects earn a score and 7,167 are listed but not ranked. The site's own gloss on the suffix is: "Capped: this tier can go no higher until more of the project's inputs are measured." A code comment beside it calls it a statement about the data, never a lower grade. So seven of the nine rows saying B (capped) is a note about thin evidence, not a demotion. llama.cpp is first for newcomers with only 64% of its inputs measurable, and organicmaps and cluster-api, at 85%, are the only rows in this list above 80%. What this does not tell you Being at the top of this list is not a promise about your particular pull request. It says how projects are weighted for a newcomer, from public GitHub history; it does not say what a given reviewer will do with your patch in a given week. It covers GitHub only. Projects that review on Gerrit or a mailing list are left undecided instead of being marked as failures, so this list says nothing about how they treat newcomers. Bots, maintainer pull requests, drafts, self-closed pull requests and accounts under 90 days old are excluded. The snapshot stores no star counts, so the lens cannot be controlled for project size. And it is dated, so it goes stale. None of it grades the people who maintain these projects. Using it Open the first-timer lens, pick two or three projects, and read the pull requests behind each verdict yourself. Treat a big delta as a reason to look closer, not a reason to start typing. If a row looks wrong to you, an issue on the repository with the pull requests that show it is the most useful thing you can send; feature requests and patches go in the same place. If you were setting the five weights for a newcomer, which would you move, and why?

This is a summary aggregated from Dev.to. Read the complete article on the original site:

Read full article at Dev.to

More Programming & Dev News