Does the Payload team still accepts contributions from community, or only from in-house development?

[MurzNN]

I made a couple of pull requests some time ago, that are short and straightforward, here they are:

• fix: allow required fields with admin.condition in typescriptSchema #16800
• feat(db-mongodb): allow custom id field types #15522

They are kinda critical for my projects, but I tried make these fixes universal to be useful for everyone.

But already many weeks I see no reaction from the Payload team in these pull requests for some reason.

Also, the same situation I see with PRs from other community members, for example, these ones:

• fix(graphql): virtual fields should be nullable in GraphQL schema (#16112) #16193
• fix(ui): prevent slug field error tooltip from hiding lock button #15885

and many more easy and straight-forward PRs that fixes different issues.

Also, in the list of merged PRs here https://github.com/payloadcms/payload/pulls?q=is%3Apr+is%3Aclosed I see only PRs from the Payload team, and almost nothing from the community.

It looks like just nobody from the Payload team view the list of issues and PRs from the community, maybe just because of the filters?

Looking at this situation, currently active community members lose motivation to continue contribute and make new PRs, preferring to solve the issues by local project-scoped fixes and patches, instead of making Payload better for everyone.

So, the question is: does the Payload team still review and accept contributions from community, or only concentrated on the in-house development and work only with internal Payload Team contributions?

Maybe the recent joining of the Payload team to Figma forced the team to change priorities by decreasing work with the community in favor of the internal commercial development for Figma?

Just a simple comment like "Thank you, but we have another vision on fixing the issue", or "Looks good, but introduces breaking changes, so we can't merge it right now, postponed for the next major release", or even "Please add tests that reproduce the issue" will be MUCH better than silence!

So how we, as a large active Payload community and Payload fans, can improve this situation?

[jacobsfletch]

Hey @MurzNN — thank you for raising this directly. First of all, let me say that keeping the community issue/PR queue healthy is something we are still fully committed to. That hasn't changed, and it isn't going away. We highly value community contributions, and will continue to review and accept them, just as we always have. This is what makes OSS so great and we haven't lost sight of that.

What has changed recently is where our bandwidth is going. I know the slow-down has been frustrating, so let me be straight about it.

Right now the team is heads-down on a set of OSS initiatives for 4.0 — the new v4 UI, folder view, the TanStack work, MCP, and a huge batch of other v4-related breaking changes. There are a ton of great new features and fixes being rolled into 4.0 that everyone will find value in. That push is consuming most of our review cycles at the moment, and community PRs like the ones you linked have been caught in the gap.

This isn't a Figma thing — it's normal OSS prioritization during a major release cycle. The acquisition hasn't turned Payload into an internal-only project. The community is a core part of why Payload is what it is, and we're committed to keeping it that way.

But I want to be transparent about the tradeoff behind it, because it's deliberate rather than neglect:

• Before we branched 3.x, we ran a dedicated team-wide pass on community PRs and closed out a very large number of them — upwards of 100+.
• The longer we divert focus from 4.x, the longer we have to maintain multiple branches in parallel — which multiplies our workload for relatively little gain. Shipping 4.0 is the thing that unblocks the backlog, including contributions like yours.

The big picture here is that this is a focused sprint, not a change in OSS stance. We plan to return focus to community PRs as part of the run-up to 4.0. In the meantime, the team has started going through the PRs you linked and will directly address each one.

Appreciate you pushing on this. That kind of signal is exactly what helps us course-correct. Let's keep the dialogue going.

[MurzNN]

Thank you so much for such a detailed response, really appreciate this! Yes, seems the main issue is the limited capacity of the team, especially with the new 4.0 release which requires a lot of attention and efforts.

But, the new major release is also an excellent opportunity to resolve conceptual issues from the 3.x release where we are not able to introduce breaking changes! So, would be great to review the current list of feature requests from the community and take something from there before the release.

For example, issues like this #15525, #15351, #15595, #17332 and some others - were postponed just because of breaking changes, and can land to 4.0 pretty well, I believe.

But, if not in 4.0, we will have to wait for 5.0 to introduce such breaking changes, that is too far...

[MurzNN]

And, about extending the Payload team capacity and involve more development forces into the core development:

I described an idea from the Drupal community: #13495 Create Payload CMS Association as a non-profit organization - so, maybe, try to discuss that idea with Figma in the scope of the topic of this discussion?

Yes, this is not a quick process to reorganize and decentralize the Payload Core team. But this turn will give the opportunity to involve other commercial organizations into the Payload CMS development, not only volunteers like now, that should make development much wider and faster!