Saying “patch” doesn’t mean it should go straight to Trac. The fact that there are 1100 tickets with a patch on them but no action (and that’s just the ones that are labeled, there are a bunch more that are missing the has-patch tag) makes this plain. I wish I could put a smiley-face, but that number is so depressing.
When I said ‘buttons don’t match’ that probably wasn’t the best example. In truth, something like that is best just asked (forum, dev chat, twitter, etc) to find out if it’s intentional or not. If it’s not intentional, a ticket should be made. If it is intentional, a ticket might still be a good idea, but 80% of the time it’s not. When someone reports something they think is not good in the UI, there are several possibilities:
1. It really does suck, we keep meaning to fix it, and there is already a ticket for it.
2. It really does suck, we keep meaning to fix it but keep forgetting to create a ticket for it. Please create ticket.
3. It’s exactly how we want it to be. The fact that it’s not to someone’s taste doesn’t merit a trac ticket — if they drum up enough community support on a forum thread first to sway our opinion then it might be.
4. It’s not perfect, but it doesn’t suck, and though it doesn’t suit one person’s workflow, it suits the broader number that we have to serve. Ideas for improving it are welcome, but need to take into account all those other use cases, not just the reporter’s. Suggestions best started in Ideas forum, then will be addressed by UI group (we’ll probably start doing scrubs every other week in 2012). When a reasonable suggestion that addresses all the UI needs has been proposed, and it’s generally considered superior to what we have now, it might be time for a trac ticket. But really, it’s time for a plugin.
Making UI suggestions that are just based on opinion will never get the kind of attention that a UI suggestion based on a successful plugin will get. For UI suggestions, plugins are better than patches, because regular users who have no idea what svn is or how to test patches (and don’t want to) can still give the idea a try and provide feedback. As we move forward with core, this is going to be a strong recommendation, that anything that’s for new UI start as a plugin, not a patch, so that it will be super easy to test/revise ideas without being tied to the core dev cycle.
This one falls into #4. Having multiple ways to get to a primary action isn’t an unintentional inconsistency, it’s part of the foundation of the WordPress UI.