I agree with and understand everything that Gabor said about the process and that Earl said about trust. I don't think anything they said needs to be changed. But the issue boils down to this: RTBC means "ready for committer review", but it doesn't SAY that. From a new contributor's perspective, "ready to be committed" means exactly what it says; the code has been reviewed and is ready to be committed. And that definition leads to a few expectations... * If a patch is properly reviewed, but by a non-trusted developer, and marked RTBC, the issue is not really RTBC because it hasn't gotten a trusted review. And yet the non-trusted developer doesn't know this, sees the RTBC status, and wonders why his/her contribution gets ignored. He/she is expecting some feedback in a timely matter, but this often doesn't happen. * Also, when a non-trusted developer reviews and marks an issue RTBC before code freeze, the expectation is that it will get reviewed and hopefully committed before code freeze. Both of these expectations are wrong, so... Why does a new contributor have these expectation? Simple. The issue status says "READY TO BE COMMITTED" and, since it is also the final status before "fixed", it looks like it's the final step. Re-aligning the non-trusted developer's expectations is definitely the way to go. (See my previous email for my proposed solution.) For example, if I had known I needed an additional, trusted review for the updated Theme Settings API patch (#57676), I would have spent some time trying to solicit one. And if I was unable to get a trusted review, the developers who worked on the patch would have known exactly why it didn't make it into 6.x and wouldn't have been frustrated at the process or at the core committers. Let me repeat myself: if new contributers perceive that their RTBC contributions are ignored, they will stop contributing. Which means this is a problem for the whole developer community, not just for new contributers. And, thus a solution is essential.