I think that the peocedure (which I also consider unnecessary) is irrelevant for this discussion. Let's focus on the subject of the thread and elaborate on that.
To add to Ignasi's comment: the process for getting stuff into jclouds can certainly be improved, but unless and until we determine that *the number of PRs* really is the main issue (as opposed to review time, lack of examples/best practice guidance, or one of many other factors), I'd say that this is not the main thing we need to focus on optimizing right now.
To me, the component of this thread that talks about the *content* of what we are likely to accept into core seems to be far more critical. As Ignasi has said, I think focussing on cloud abstraction is both a good way of maintaining coherence for the project overall and giving guidance to potential contributors:
1) Does my proposed API/provider match one of the existing abstractions? If yes, I will need to implement that abstraction before I have a chance of going to core. 2) If not, I will need to start a discussion about what kind of abstraction my API/provider represents (including potentially other examples) before there is a chance of my API/provider making it to core.
As far as *which* kinds of abstraction jclouds should provide in order to remain relevant going forward: *that's* exactly where I think we need to move much more to actively (re-)engaging with our user base and getting their input.
Regards ap
