Yes! Recently I’ve been helping form the API Working Group [1] in the OpenStack community. This is exactly our goal. Taking feedback on APIs and creating guidelines for all OpenStack projects to follow. Filing a bug is good but it’s a one off fix. Creating a guideline for all projects to follow so the bug never occurs or propagates to other projects is better.
I’m helping lead sessions [2] [3] [4] for the working group this week. I know that there are a handful of jclouds people at the summit so please feel free to come out and contribute to those sessions. For everyone else, you can get involved by going to [1]. It specifies the deliverables and how to contribute to the group. If you have any questions, please let me know. Thanks, Everett [1] https://wiki.openstack.org/wiki/API_Working_Group [2] http://kilodesignsummit.sched.org/event/13fc460f359646dcd41d6a2d7ad0bec0 [3] http://kilodesignsummit.sched.org/event/6dda98fe267192ed9f24aba4b7c68252 [4] http://kilodesignsummit.sched.org/event/3f0a5f22f2d641ef69965373f3e23983 On Nov 2, 2014, at 8:25 PM, Adrian Cole <adrian.f.c...@gmail.com> wrote: > Hi, team (primarily Everett, Jeremy, Zach) > > jclouds has the blessing and burden of being a warehouse for OpenStack > apis. Some of these are highly reused, others, less so. One thing I've > watched over years is us slavishly implementing some really bad designs. It > is one thing for a enterprise cloud.. we kindof expect those to suck, and > the engagement model doesn't lead towards things getting better. But, > OpenStack?! > > Is there any avenue folks can think of where we can help OpenStack not > design terrible apis? Or things that make jclouds live with custom code > forever? What if we were a datapoint that fed back into their design? What > if instead of slavishly implementing things that make us cringe, we opened > an issue with the corresponding project saying.. I think I can help! > > For example, back in the day, I found a snafu on an api design in swift. I > opened a bug > > https://bugs.launchpad.net/swift/+bug/1232787 > > They fixed it. > > We have a unique opportunity to help improve the quality of OpenStack vs > propagate poor quality. Can folks with influence start pushing back with > suggestions? It not only helps us have less edge-case code or senseless > boilerplate, but it will also help improve the reputation of OpenStack. > > -A