Due to limited review and maintenance capacity, we are currently only accepting pull requests from long-term contributors who are already familiar with the codebase, development process, and project goals.
As a result, pull requests from new contributors will be closed without review.
We appreciate everyone who takes the time to improve the project and hope to revisit this policy in the future if circumstances change.
Thank you for your understanding and for your interest in the project.
Why close the PRs? Any other way to differentiate? Like via "tags"?
In my experience in open source projects I've had numerous WIP PRs that were useful, but there was no reviewers capacity to finalize and merge them. Cherry picking them into my "custom version" was a no brainer.
But closing PR blends it with everything else, disrupts automations, bot interaction, commenting (?), and most importantly - decreases observability - others who need it might simply not find it.
Is this something that is likely rolled back after GSoC or is it an unrelated/more-indefinite pause?
I've been meaning to implement a small change to the TinyMCE editor that's been bothering me (have Escape close the open 'Reveal or hide additional toolbar items' panel, instead of start other events), and I just got it working locally.
It's hard to tell at the moment as things change fast. It used to be that having someone implement a feature could be a net win to the project - when it takes more time to implement it than it takes for us to review. In some cases, when a skilled engineer would create a PR, it was indeed a huge win, as a short review was all that was needed. And hopefully that was a win-win situation since the contributor also got the feature they needed.
With AI-generated code, this logic has been flipped around - now it takes way more time for us to review than it takes someone to implement a feature. It's also very easy for someone to create a drive-by PR, maybe for their CV or GSoC, it looks good, and it costs them almost nothing - just input the spec in Claude and post whatever comes out (sometimes it doesn't even build but they don't check).
The logical conclusion is that we may as well implement the feature ourselves since it's much easier to work on a feature directly with Claude than to have someone in between, inputting our comments in Claude, and committing whatever comes out with no understanding of our comments or the resulting code. Unfortunately they often answer with AI too, with excuses like their English's not good enough (it's never going to be then, is it), and at a human level it's not great to spend time reviewing things, hand-writting comments, and essentially having a bot answers us.
That's not always true though - someone who actually cares about improving the project won't do this, and also experienced engineers will still produce good code when they use AI. The problem is how to identify them without opening the floodgates again to the low quality PRs. So for now, we simply restrict PRs to the contributors we already know.
I don't like this much, as it's not the spirit of open source, but we also need to be realistic with our own capabilities - how much time we have, as well as our mental health. But again, things change fast at the moment, and our understanding of the situation will most likely evolve over time and hopefully we can find a good compromise.