I want to contribute.

[dantetemplar]

Hi, I’d like to help develop the SolidJS technology. First off, are there any tasks that would be good to start with?
Secondly, I often try to contribute to projects, but the author turns out to be an asshole and never merges anything. So, I’m a bit wary of wasting my time. Looking at the contribution stats for Solid—ryansolid is first, the second spot is his Cursor, and the third person has relatively few contributions. Could you put my mind at ease about this?

My experience with solidjs mostly was vibecoding computer vision labeling app (https://github.com/dantetemplar/lee-label), and making several solutions during hackathons.

[dantetemplar]

Also I would glad to triage and manage issues after I will be sure that I know enough in SolidJS.

[atk]

Hi, I’d like to help develop the SolidJS technology.

I am the maintainer of our testing-library package, so I can speak from experience: find a part of Solid or its ecosystem that you feel you could improve and ask on Discord if you can help with that.

Secondly, I often try to contribute to projects, but the author turns out to be an asshole and never merges anything.

I had my first PR to solid closed without a merge, too. But the reason was that I had tried to add an abort option to resources and Ryan - rightfully, as I now know - thought this was dead meat for a lot of applications of resources and better suited as an external primitive, so I added it to solid-primitives instead. He is one of the few library authors I know taking his time to personally answer requests from his users. Yes, your PR might not get merged at all, but unlike with other projects, you'll walk away having learned something from the experience.

Bad experiences in Open Source development stem from one thing in my experience: mismatched expectations. Creators of OSS projects expect that by providing their code for free, they should receive fair criticism, helpful issue reports, workable contributions that go at least approximately in the direction they intended for the end result. Contributors often expect that offering their time should be rewarded with the time of the creator required to review and integrate their contributions, regardless whether these match the requirements of the creators.

The solutions is to communicate. Find common ground between their and your expectations and don't be disappointed if there is none.

[vallabhatech]

Hey @atk and @dantetemplar,

Thanks a lot for sharing this perspective, @atk—that breakdown of mismatched expectations in open source is spot on. It’s really encouraging to hear how intentional and educational Ryan and the core team are when reviewing proposals, even when a PR doesn't end up merging into core directly.

@dantetemplar, as someone who spends a lot of time building with modern web stacks, contributing to open source, and mentoring developers, I completely understand the hesitation around investing time into unmerged PRs. Starting in the ecosystem—like solid-primitives, docs, or community tools—is usually one of the best ways to get familiar with a core architecture while getting early feedback.

@atk, for someone looking to start triaging or taking on good first issues in SolidJS or solid-testing-library, are there specific channels on Discord or label tags in the issues where maintainers actively look for community support?

[atk]

Most development takes place on #next, and a lot of ecosystem packages have their own channels.