On Feb 9, 2015, at 9:28 PM, Jay Pipes
<[email protected]<mailto:[email protected]>> wrote:
On 02/02/2015 02:51 PM, Stefano Maffulli wrote:
On Fri, 2015-01-30 at 23:05 +0000, Everett Toews wrote:
To converge the OpenStack APIs to a consistent and pragmatic RESTful
design by creating guidelines that the projects should follow. The
intent is not to create backwards incompatible changes in existing
APIs, but to have new APIs and future versions of existing APIs
converge.
It's looking good already. I think it would be good also to mention the
end-recipients of the consistent and pragmatic RESTful design so that
whoever reads the mission is reminded why that's important. Something
like:
To improve developer experience converging the OpenStack API to
a consistent and pragmatic RESTful design. The working group
creates guidelines that all OpenStack projects should follow,
avoids introducing backwards incompatible changes in existing
APIs and promotes convergence of new APIs and future versions of
existing APIs.
After reading all the mails in this thread, I've decided that Stef's suggested
mission statement above is the one I think best represents what we're trying to
do.
That said, I think it should begin "To improve developer experience *by*
converging" ... :)
+1
I think we could be even more explicit about the audience.
To improve developer experience *of API consumers by* converging the OpenStack
API to a consistent and pragmatic RESTful design. The working group creates
guidelines that all OpenStack projects should follow, avoids introducing
backwards incompatible changes in existing APIs, and promotes convergence of
new APIs and future versions of existing APIs.
I’m not crazy about the term "API consumer" and could bike shed a bit on it.
The problem being that alternative terms for "API consumer" have been taken in
OpenStack land. “developer” is used for contributor developers building
OpenStack itself, “user” is used for operators deploying OpenStack, and “end
user” has too many meanings. “API consumer” makes it clear what side of the API
the working group audience falls on.
I also like dtroyer’s idea of a Tweetable mantra but I think we need to distill
that mantra _from_ a longer mission statement. If we constrained the mission
statement to <= 140 chars at the outset, we’d be losing valuable information
that’s vital in communicating our intent. And if we can’t fully communicate our
intent in a mission statement then it doesn’t have as much value.
Thanks,
Everett
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
