<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>+1 – Requiring specs for every blueprint is going to make the development process very cumbersome, and will take us back to waterfall days.</div>
<div>
<div>I like how the Marconi team operates now, with design decisions being made in IRC/ team meetings.</div>
<div>So Spec might become more of an overhead than add value, given how our team functions.</div>
</div>
<div><br>
</div>
<div><u>'If'</u> we agree to use Specs, we should use that only for the blue prints that make sense.</div>
<div>For example, the unit test decoupling that we are working on now – this one will be a good candidate to use specs, since there is a lot of back and forth going on how to do this. </div>
<div>On the other hand something like Tempest Integration for Marconi will not warrant a spec, since it is pretty straightforward what needs to be done.</div>
<div>In the past we have had discussions around where to document certain design decisions (e.g. Which endpoint/verb is the best fit for pop operation?)</div>
<div>Maybe spec is the place for these?</div>
<div><br>
</div>
<div>We should leave it to the implementor to decide, if the bp warrants a spec or not & what should be in the spec.</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Kurt Griffiths <<a href="mailto:kurt.griffiths@rackspace.com">kurt.griffiths@rackspace.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Monday, June 2, 2014 1:33 PM<br>
<span style="font-weight:bold">To: </span>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] [Marconi] Adopt Spec<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>I’ve been in roles where enormous amounts of time were spent on writing specs, and in roles where specs where non-existent. Like most things, I’ve become convinced that success lies in moderation between the two extremes.</div>
<div><br>
</div>
<div>I think it would make sense for big specs, but I want to be careful we use it judiciously so that we don’t simply apply more process for the sake of more process. It is tempting to spend too much time recording every little detail in a spec, when that
time could be better spent in regular communication between team members and with customers, and on iterating the code (<i>short</i> iterations between demo/testing, so you ensure you are on staying on track and can address design problems early, often). </div>
<div><br>
</div>
<div>IMO, specs are best used more as summaries, containing useful big-picture ideas, diagrams, and specific “memory pegs” to help us remember what was discussed and decided, and calling out specific “promises” for future conversations where certain design
points are TBD.</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Malini Kamalambal <<a href="mailto:malini.kamalambal@RACKSPACE.COM">malini.kamalambal@RACKSPACE.COM</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack Dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Monday, June 2, 2014 at 9:51 AM<br>
<span style="font-weight:bold">To: </span>OpenStack Dev <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>[openstack-dev] [Marconi] Adopt Spec<br>
</div>
<div><br>
</div>
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div>Hello all,</div>
<div><br>
</div>
<div>We are seeing more & more design questions in #openstack-marconi.</div>
<div>It will be a good idea to formalize our design process a bit more & start using spec.</div>
<div>We are kind of late to the party –so we already have a lot of precedent ahead of us.</div>
<div><br>
</div>
<div>Thoughts?</div>
<div><br>
</div>
<div>Malini</div>
<div><br>
</div>
</div>
</div>
</span></div>
</div>
</span>
</body>
</html>