<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-05-02 5:12 GMT+08:00 Everett Toews <span dir="ltr"><<a href="mailto:everett.toews@rackspace.com" target="_blank">everett.toews@rackspace.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class=""><div class="h5">On Apr 30, 2015, at 9:54 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
<br>
> Hi Stackers,<br>
><br>
> OK, so Matthew Gilliard and Alex Xu have volunteered to be the Nova team's liaisons to the API working group. Big thank you to Matthew and Alex for volunteering for this important role.<br>
><br>
> I've created a wiki page [1] that details the responsibilities of these liaisons. If these duties work out for Nova, we'll recommend other projects pick them up.<br>
><br>
> Here are the responsibilities that the Nova/API working group liaisons have:<br>
><br>
> 1. Monitor the active patch queue in nova (and nova-specs) and look out for any patch that adds or changes the REST API<br>
><br>
> 2. For each patch collected in #1, determine if the constructs used in the patch (or proposed spec) match the guidance currently laid out in the API working group repo's guidance documents.<br>
><br>
> 3. If the patch does NOT match the guidance from the API working group, do a code review on the patch pointing to the guidance from the API working group, and ask the author to align with that guidance. Include in your research patches to the API working group that may actually be in review and not merged. (An example of this recently occurred with Sergey Nikitin's re-proposed instance tagging spec: <a href="https://review.openstack.org/#/c/177112/" target="_blank">https://review.openstack.org/#/c/177112/</a>. See Ryan Brown's reference to an in-progress API working group guidance on tagging)<br>
><br>
> 4. If there is NO guidance in the API working group repo for a particular proposed API change or addition, the liaison should **either** create a proposed patch to the API working group with guidance that clarifies the missing functionality that is introduced in the new Nova patch or spec patch, and bring the proposed guidance to the attention of the API working group. **or** the liaison should working with a member of the API working group to draft such a guideline. The liaison should mark the corresponding Nova patch with a -1 Code Review vote with a link to the proposed guideline, noting that the patch should be put on hold (Work In Progress) until the guideline is merged.<br>
><br>
> Best,<br>
> -jay<br>
><br>
> [1] <a href="https://wiki.openstack.org/wiki/Nova/APIWGLiaisons" target="_blank">https://wiki.openstack.org/wiki/Nova/APIWGLiaisons</a><br>
<br>
</div></div>This is great. I’ve added a link to that page from the Cross-Project Liaisons page [2]. I also added Matthew and Alex as liaisons there.<br>
<br>
gilllliard and alex_xu: feel free to join us in #openstack-api on freenode too!<br></blockquote><div><br></div><div>Everett, Thanks! Just joined!<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Everett<br>
<br>
[2] <a href="https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group" target="_blank">https://wiki.openstack.org/wiki/CrossProjectLiaisons#API_Working_Group</a></blockquote></div><br></div></div>