<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Jun 29, 2015 at 4:32 AM, Thierry Carrez <span dir="ltr"><<a href="mailto:thierry@openstack.org" target="_blank">thierry@openstack.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">Nikola Đipanov wrote:<br>
> It's not only about education - I think Gerrit is the wrong medium to<br>
> have a design discussion and do design work. Maybe you disagree as you<br>
> seem to imply that it worked well in some cases?<br>
><br>
> I've recently seen on more than a few cases how a spec "review" can<br>
> easily spiral into a collection of random comments that are hard to put<br>
> together in a coherent discussion that you could call design work.<br>
><br>
> If you throw in the expectation of approval into the mix, I think it<br>
> basically causes the opposite of good design collaboration to happen.<br>
<br>
</span>On Gerrit not being the right tool for specs...<br>
<br>
Using code review tools to iterate on specs creates two issues:<br>
<br>
* Minor comments<br>
Line-by-line code review tools are excellent for reviewing the<br>
correctness of lines of code. When switching to specs, you retain some<br>
of that "review correctness of all lines" mindset and tend to spot<br>
mistakes in the details more than mistakes in the general idea. That, in<br>
turn, results in -1 votes that don't really mean the same thing.<br>
<br>
* Extra process<br>
Code review tools are designed to produce final versions of documents.<br>
For specs we use a template to enforce a minimal amount of details, but<br>
those are already too much for most small features. To solve that issue,<br>
we end up having to binary-decide when something is significant enough<br>
to warrant a full spec. As with any line in the sand, the process end up<br>
being too much for things that are just beyond the line, and too little<br>
for things that are just before.<br>
<br>
IMHO the ideal tool would allow you to start with a very basic<br>
description of what feature you want to push. Then a discussion can<br>
start, and the "spec" can be refined to answer new questions or detail<br>
the already-sketched-out answers. Simple features can be approved really<br>
quickly using a one-sentence spec, while more complex features will<br>
develop into a full-fledged detailed document before they get approved.<br>
One size definitely doesn't fit all. And the discussion-based review<br>
(opposed to line-by-line review) discourages nitpicking on style.<br>
<br></blockquote><div><br></div><div>This is exactly what we realized in Neutron, and why we moved to an Request For Enhancement (RFE) process [1]. So far, it's been pretty good. A slimmed down spec (only required if an RFE bug needs a bit more fleshing out), design documents merging in-tree with the code, and no deadlines. I've not heard any complaints so far and we're liking the new model a lot better.<br><br></div><div>Thanks,<br></div><div>Kyle<br></div><div><br>[1] <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-June/066217.html">http://lists.openstack.org/pipermail/openstack-dev/2015-June/066217.html</a><br> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
You *can* do this with Gerrit: discourage detail review + encourage idea<br>
review, and start small and develop the document in future patchsets<br>
as-needed. It's just not really encouraging that behavior for the job,<br>
and the overhead for simple features still means we can't track smallish<br>
features with it. As we introduce new tools we might switch the "feature<br>
approval" process to something else. In the mean time, my suggestion<br>
would be to use smaller templates, start small and go into details only<br>
if needed, and discourage nitpicking -1s.<br>
<span class=""><font color="#888888"><br>
--<br>
Thierry Carrez (ttx)<br>
</font></span><div class=""><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>