Maybe it would be helpful setting up a formal gap-analysis (not sure if that's the correct term), comparing Eclipse IDE with its competition? It could help in pinpointing where to focus effort.
To be honest, I don't think anything formal would help.
Here with this presentation or other articles pointed in the past, we have a formal enough resources with a clear enough gap-analysis to act. Our issue isn't in identifying the delta, but more on actively reducing. And it's as usual a resource issue that anything formal fails to address IMO.
Eclipse is the Maven integration, and almost equally often "front end" stuff.
That's what people like to complain about, but not really where the gap is these days. I think the gap has already been much reduced (think about newer Java features, performance, save actions, Maven support...), and what's left is not new and is almost all about the editor.
I realise that this is a big undertaking, but with some collaborative effort I think it can be done.
We already have all the means and all the processes already there to address all that. I'm afraid more processes and more formal stuff will just distract people from doing what actually matters here: write the necessary code.
However, if you can convince me that having something more formal will increase the amount of development/contribution time received by Eclipse IDE, I'm all for it; but at the moment, I have the impression after the few last releases that the less formal we are, and the more time we actually spend developing, the more contributors we attract, and the more value we ship.