Good question, and impossible to answer, but here's my suggestion:
1) Pick out what you really want to improve
Since you're not in control of the project yourself, this boils down to your ability to convince the right people.
Also, since you're not implementing the issues yourself, you need to find a way to get other people to do something that you wants to get done.
The first thing you need to do, is to pick issues you really want to improve.
Go for the tangible issues. These are more likely to find the way to the right people.
Pick your battles!
2) Documentation of you findings
Since you are need to convince people, you need an effective documentation of your findings/suggestions. Note that I don't say "thorough", "deep" or "massive" documentation - but effective.
The only really effective argumentation tool I know is video documentation.
You can point at guidelines, research and test result statistics - but these are easy to ignore. A video replay on the other hand is such a powerful tool, that it is very hard to ignore. Everyone hates to see users that struggle with their product.
(Which in turn gives you a huge responsibility to use this wisely, and not abuse this to get what you want. But thats another story.)
Pick your battles and wrap them up nicely.
3) Easy to implement
As I said in my first point, you need to pick the most important issues - in addition you must show some suggestion on how they can solve the problem. (I know that you have done so in your situation, but I'm trying to answer a bit more broadly :-)
Just pointing out problems wouldn't get them fixed.
If the solution is served on a silver plate, it's a lot easier to apply the improvements.
Pick your battles, wrap them up nicely and serve them on a silver plate.
4) Presentation of the message
And how should the suggestions be presented to the project lead? I believe that the ordinary official channels are not enough. Yet another e-mail might be flagged, but eventually it will drown in the crowd. The same applies to bug-reports and feature request. Other issues will very easy defeat these "eye candy" and "nice to have" kinds of issues (especially those with low substance).
Therefore, write about your suggestions in a blog. Get some discussion and coverage, and get some other people on your side. See if the project has an account at uservoice.com, if not - create one yourself.
[battle, wrap and you know the drill...] and get some supporters!
Then you can point out your suggestions to the project lead.
5) Get feedback
Finally. Respect that other people have other interests, and that your suggestion is one out of many other issues on the road map.
We prioritize UX very high (with good reasons, of course!). But we know that some people enjoy money more (even though we keep telling them that UX = money!), and that some people just don't get the point (especially when we keep telling them that good UX leads to things that the users don't notice.)
But sometimes, the lack of engagement is just an illusion. They might have reviewed your suggestion properly, but still concluded that other issues are more important. Remember that something that may seem like an easy fix, like rearranging a menu or use a different wording, might in fact have ripple effects that makes it hard to apply.
Therefore:
Get feedback from the community and the project lead. Find out if the suggestion was to hard to implement or if it's just not prioritized. Every FOSS project lives it's own life and has a unique community. Some are very open and some are repellent. Get involved with the project and try to figure out the best way to contribute.
