All organizations have problems that everyone knows, but nobody has time to fix it. The time never comes to tackle those problems. Every product has other problems that need to be solved, features that need to be implemented, and changes that have to be made. If someone decides to solve that long-lasting problem without prioritization and writes an RFC to collect feedback, the solution is doomed to fail again.
For RFC to serve well, the solution has to be prioritized correctly. If a team cannot get to solve a problem due to other work packages, developing a solution by writing an RFC won’t change the situation. If the team cannot tackle the problem immediately after the RFC is accepted, they will fail. The systems evolve, and decisions made a month or two months ago has to be revised, refined, and adapted to the new changes. The RFC will likely lose its validity by then. Implementation of the RFC should start right after it’s closed for feedback. And that requires clear prioritization of the topic.
