e18e ecosystem issues: a shared tracker for cleaning up the JavaScript ecosystem

Why a central tracker at all

It is worth being explicit about the problem this arrangement solves, because the obvious objection is that GitHub already has issue trackers and the obvious answer is that they are per repository and this is not.

The work this community does is not scoped to one repository. Cleaning up a dependency usually means touching several, and the party who knows that package A is unmaintained and that package B already replaced it is rarely a maintainer of either. That knowledge is spread across the community, and the community needs a place to put it.

A shared tracker turns scattered observations into a queue. Someone notices that a particular small package has had no commits in three years and has two open issues asking for a maintainer. They file an entry here with a label describing what state the upstream project is in. Now there is one list, and anyone looking for a well-scoped contribution can filter it.

The labels are the filter, and that is why the readme spends most of its length on them rather than on projects. A tracker of a hundred entries across fifty projects is useless without triage, and the triage here is the small closed vocabulary of states: nobody has asked, an issue exists, pull requests are welcome, a pull request is open, it merged.

The other thing the central arrangement buys is legitimacy. The readme says the repository has been officially adopted into the e18e organisation as the primary issue tracker, which means it is endorsed rather than a personal to-do list. When you go to an upstream maintainer and explain that a community organisation has catalogued the problem, that is a different conversation from one person asking for a favour.

And it scales the work. The e18e community is many people, and a shared tracker lets the work be distributed among them according to who happens to have capacity, rather than concentrated on whoever noticed the problem first.

A tracker, not a codebase

The e18e ecosystem issues repository is a place to keep track of ongoing efforts to improve performance in the JavaScript ecosystem, and it is part of the e18e initiative and community.

The top level of the repository makes the shape obvious: a .gitignore, a README.md and a docs/ directory. There is no source code, no build configuration, no package manifest. The primary language is not even recorded, because there is nothing to record a language for.

What the repository actually contains is a tracker. The readme says it is a place to track issues and contributions to projects across the ecosystem, and that these may involve any number of the areas e18e focuses on, with cleanup given as the most common example and speedup named as another.

That last point is worth unpacking, because it explains why this is a single tracker rather than a directory of separate ones. A cleanup contribution is a proposal to remove an abandoned dependency, replace a dead library, drop a redundant polyfill or tidy a build. A speedup contribution is a proposal to make something run faster. They are different kinds of work, they need different skills, and they have different risk profiles, but they share a purpose: reducing the friction of working in the ecosystem.

So the repository is best understood as a coordination layer. The work happens in other people's repositories, and this one exists to make that work findable and to route it to people who can do it.

The readme notes that the repository started life as the ecosystem-cleanup project and has since outgrown that as the community went beyond only cleanup contributions, and that it has been officially adopted into the e18e organisation as the primary issue tracker. The name in the repository path is the newer one, and the history is why it also covers more than its original name suggests.

The labels are the triage

All issues on the tracker are labeled, and the readme's next claim is that a lot of them contain actionable items you can start to work on right away. The labels are what make that true, because they describe the state of the conversation with the upstream maintainer rather than the technical difficulty.

The needs first contact label means the maintainer of the repository was not contacted yet. The instruction is to create an issue and ask, following the repository's contributing guidelines. So the first task is not code, it is a message, and the guidance is to keep it polite.

The readme also explains what to do when an issue was filed more than a couple of months ago and has received no activity: you can reach out to the maintainer through other channels listed on the repository, but you must make sure that contributions are welcome. The stated goal is to get the maintainers on board and to convince them that this is important enough to spend time on. That is a deliberate constraint. The tracker is not a place to pressure maintainers into accepting work, it is a place to first establish that the work is wanted.

The accepts prs label means the maintainer is welcoming pull requests, and the advice is to feel free to create PRs for all the issues you find, while making sure to follow the contribution guidelines.

The needs alternative label is the most demanding and the most interesting. The package in question needs a replacement that the community can bring forward. You are invited to create one, but with a warning attached: its maintenance burden is on you. The readme adds that before replacing the package you should ensure you have explored existing alternatives, prioritising contributing to or improving those alternatives before deciding to create a new package. It also asks you to test the new package thoroughly, to promote it within the community to gain visibility and trust, and to avoid migrating any repositories to your new package without first double-checking with the community.

That is a well-reasoned escalation ladder. Fix the existing thing first, replace it only when there is no viable existing thing, and do not ask people to move until the replacement has earned trust.

A state machine for contributions

The readme describes a place to start and then, with the caveat that it is not required but often followed, sets out a process with a sequence of labels:

needs first contact, then has issue, then accepts prs, then has pr, and then merged.

Each arrow is a state change, and each state change is something the contributor does rather than something the tracker does. Making contact produces an issue on the upstream repository, which is recorded here as has issue. The upstream maintainer agreeing to pull requests moves it to accepts prs. The pull request existing moves it to has pr. And merged closes the loop.

The instruction for the umbrella issue label is the piece that keeps this coherent across projects. If you create an issue or a pull request for an umbrella issue, you should update the umbrella issue as well. An umbrella issue is a broad entry point in the tracker that groups related work, and without the instruction to post the link back, the umbrella entry would go stale while the real work happened elsewhere.

The where do I start section gives the same mechanics as a list of concrete actions. If you want to reach out, look for issues with the needs first contact label and create an issue there, or use some other communication channel, and paste the issue you created as the answer to the tagged issue here. If you want to create pull requests, look for the accepts prs label and paste the pull request link in the tagged issue. If you create an issue or a pull request for an umbrella issue, update the umbrella issue as well.

The interesting mechanic is the paste-back requirement. The tracker is not the place where the work is recorded, it is the place where the work is indexed. The tracker entry exists so that somebody else can find the state of every contribution without visiting each upstream repository. The cost of that design is that contributors have to maintain the link manually, and the readme asks for it explicitly rather than automating it.

Real examples of what the entries look like

The readme ends with two example issues, and they are worth looking at because they show what a tagged tracker entry actually points to.

The first is dom-testing-library, pointing at issue 1340 in the testing-library repository. The second is webpack-dev-server, pointing at issue 5368 in the webpack-dev-server repository.

Both are well known, widely used projects, and both are the kind of project where a dependency problem is not obvious from the outside. A testing library that has become unmaintained, or a development server with a transitive dependency that has been deprecated, are the sort of thing that every user of the ecosystem experiences and no single user can fix.

The choice of examples also illustrates the span of the work. dom-testing-library is a testing utility, and webpack-dev-server is a build tool that sits in the path of every frontend developer. Neither is a small side project; both are infrastructure in the sense that a lot of people depend on them without choosing them.

That is why a shared tracker is worth having at all. The dependency cleanup work is spread across hundreds of maintainers, each with a small amount of it, and it needs coordination. Without a central index, the same abandoned package gets noticed and filed by three people in three places, and the person with the actual context to fix it never hears about any of them.

The repository publishes no GitHub releases, and the last push was on 2026-04-04. The absence of releases is expected for a repository whose content is issues, since there is nothing to release, but the push date is the thing to keep an eye on for a tracker, because a tracker that stops being updated stops being findable.

Editorial conclusion

Adopt the e18e ecosystem issues tracker if you want to find a maintained, well-scoped contribution to make in the JavaScript ecosystem, because the labels do the triage for you and each tagged issue names an actionable step. Do not adopt it as a dependency or a library, because there is no code here, and be clear with yourself about which label you can service, since the needs alternative label in particular implies an ongoing maintenance burden rather than a one-off contribution. Before you start, read the contributing guidelines of the project you intend to help, because the tracker asks for that explicitly, and check whether the maintainer has already agreed to your approach.

Frequently asked questions

Official sources

1. e18e/ecosystem-issues on GitHub
2. Issues
3. Project website
4. README