<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 04/10/2015 01:04 PM, Boris Pavlovic wrote:<br>
    <blockquote
cite="mid:CAD85om3FdheQYct+E_gqqOCwAUZ6wKNdnZXRkc-MLi9AxTtg-Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hi, 
        <div><br>
        </div>
        <div>I believe that specs are too detailed and too dev oriented
          for managers, operators and devops. </div>
        <div>They actually don't want/have time to write/read all the
          stuff in specs and that's why the communication between dev
          & operators community is a broken. <br>
        </div>
      </div>
    </blockquote>
    <br>
    +1<br>
    <br>
    <blockquote
cite="mid:CAD85om3FdheQYct+E_gqqOCwAUZ6wKNdnZXRkc-MLi9AxTtg-Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>I would recommend to think about simpler approaches like
          making mechanism for proposing features/changes in projects. </div>
        <div>Like we have in Rally:  <a moz-do-not-send="true"
            href="https://rally.readthedocs.org/en/latest/feature_requests.html">https://rally.readthedocs.org/en/latest/feature_requests.html</a></div>
      </div>
    </blockquote>
    <br>
    Are any other OpenStack projects handling feature requests like
    this?    I think a "feature request" process like this would be
    useful across more components than just Neutron.   I'm sure there
    are some requests that would also require changes across multiple
    components. <br>
    <br>
    <blockquote
cite="mid:CAD85om3FdheQYct+E_gqqOCwAUZ6wKNdnZXRkc-MLi9AxTtg-Q@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>This is similar to specs but more concentrate on WHAT
          rather than HOW. </div>
        <div>
          <div><br>
          </div>
          <div><br>
          </div>
          <div>Best regards,</div>
          <div>Boris Pavlovic </div>
        </div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Fri, Apr 10, 2015 at 7:34 PM, Kevin
          Benton <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:blak111@gmail.com" target="_blank">blak111@gmail.com</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr"><span class="">><span
                  style="font-size:12.8000001907349px">The Neutron
                  drivers team, on the other hand, </span><span
                  style="font-size:12.8000001907349px">don't have a
                  clear incentive (Or I suspect the will) to spend
                  enormous amounts of time doing 'product management', </span><span
                  style="font-size:12.8000001907349px">as being a driver
                  is essentially your third or fourth job by this point,
                  and are the same people </span><span
                  style="font-size:12.8000001907349px">solving gate
                  issues, merging code, triaging bugs and so on.</span>
                <div><span style="font-size:12.8000001907349px"><br>
                  </span></div>
              </span>
              <div><span style="font-size:12.8000001907349px">Are you
                  hinting here that there should be a separate team of
                  people from the developers who are deciding what
                  should and should not be worked on in Neutron? Have
                  there been examples of that working in other open
                  source projects where the majority of the development
                  isn't driven by one employer? I ask that because I
                  don't see much of an incentive for a developer to
                  follow requirements generated by people not familiar
                  with the Neutron code base. </span></div>
              <div><span style="font-size:12.8000001907349px"><br>
                </span></div>
              <div><span style="font-size:12.8000001907349px">One of the
                  roles of the driver team is to determine what is
                  feasible in the release cycle. How would that be
                  possible without actively contributing or (at a
                  minimum) being involved in code reviews?</span></div>
            </div>
            <div class="gmail_extra"><br>
              <div class="gmail_quote"><span class="">On Thu, Apr 9,
                  2015 at 7:52 AM, Assaf Muller <span dir="ltr"><<a
                      moz-do-not-send="true"
                      href="mailto:amuller@redhat.com" target="_blank">amuller@redhat.com</a>></span>
                  wrote:<br>
                </span>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div>
                    <div class="h5">The Neutron specs process was
                      introduced during the Juno timecycle. At the time
                      it<br>
                      was mostly a bureaucratic bottleneck (The ability
                      to say no) to ease the pain of cores<br>
                      and manage workloads throughout a cycle. Perhaps
                      this is a somewhat naive outlook,<br>
                      but I see other positives, such as more upfront
                      design (Some is better than none),<br>
                      less high level talk during the implementation
                      review process and more focus on the details,<br>
                      and 'free' documentation for every major change to
                      the project (Some would say this<br>
                      is kind of a big deal; What better way to write
                      documentation than to force the developers<br>
                      to do it in order for their features to get
                      merged).<br>
                      <br>
                      That being said, you can only get a feature merged
                      if you propose a spec, and the only<br>
                      people largely proposing specs are developers.
                      This ingrains the open source culture of<br>
                      developer focused evolution, that, while
                      empowering and great for developers, is bad<br>
                      for product managers, users (That are sometimes
                      under-presented, as is the case I'm trying<br>
                      to make) and generally causes a lack of a cohesive
                      vision. Like it or not, the specs process<br>
                      and the driver's team approval process form a sort
                      of product management, deciding what<br>
                      features will ultimately go in to Neutron and in
                      what time frame.<br>
                      <br>
                      We shouldn't ignore the fact that we clearly have
                      people and product managers pulling the strings<br>
                      in the background, often deciding where developers
                      will spend their time and what specs to propose,<br>
                      for the purpose of this discussion. I argue that
                      managers often don't have the tools to understand<br>
                      what is important to the project, only to their
                      own customers. The Neutron drivers team, on the
                      other hand,<br>
                      don't have a clear incentive (Or I suspect the
                      will) to spend enormous amounts of time doing
                      'product management',<br>
                      as being a driver is essentially your third or
                      fourth job by this point, and are the same people<br>
                      solving gate issues, merging code, triaging bugs
                      and so on. I'd like to avoid to go in to a
                      discussion of what's<br>
                      wrong with the current specs process as I'm sure
                      people have heard me complain about this in<br>
                      #openstack-neutron plenty of times before.
                      Instead, I'd like to suggest a system that would
                      perhaps<br>
                      get us to implement specs that are currently not
                      being proposed, and give an additional form of<br>
                      input that would make sure that the development
                      community is spending it's time in the right
                      places.<br>
                      <br>
                      While 'super users' have been given more exposure,
                      and operators summits give operators<br>
                      an additional tool to provide feedback, from a
                      developer's point of view, the input is<br>
                      non-empiric and scattered. I also have a hunch
                      that operators still feel their voice is not being
                      heard.<br>
                      <br>
                      I propose an upvote/downvote system (Think
                      Reddit), where everyone (Operators especially)
                      would upload<br>
                      paragraph long explanations of what they think is
                      missing in Neutron. The proposals have to be
                      actionable<br>
                      (So 'Neutron sucks', while of great humorous
                      value, isn't something I can do anything about),<br>
                      and I suspect the downvote system will help
                      self-regulate that anyway. The proposals are not
                      specs, but are<br>
                      like product RFEs, so for example there would not
                      be a 'testing' section, as these proposals will
                      not<br>
                      replace the specs process anyway but augment it as
                      an additional form of input. Proposals can range<br>
                      from new features (Role based access control for
                      Neutron resources, dynamic routing,<br>
                      Neutron availability zones, QoS, ...) to quality
                      of life improvements (Missing logs, too many<br>
                      DEBUG level logs, poor trouble shooting areas with
                      an explanation of what could be improved, ...)<br>
                      to long standing bugs, Nova network parity issues,
                      and whatever else may be irking the operators
                      community.<br>
                      The proposals would have to be moderated (Closing
                      duplicates, low quality submissions and
                      implemented proposals<br>
                      for example) and if that is a concern then I
                      volunteer to do so.<br>
                      <br>
                      This system will also give drivers a 'way out':
                      The last cycle we spent time refactoring this and
                      that,<br>
                      and developers love doing that so it's easy to get
                      behind. I think that as in the next cycles we move
                      back to features,<br>
                      friction will rise and the process will reveal its
                      flaws.<br>
                      <br>
                      Something to consider: Maybe the top proposal
                      takes a day to implement. Maybe some low priority
                      bug is actually<br>
                      the second highest proposal. Maybe all of the
                      currently marked 'critical' bugs don't even appear
                      on the list.<br>
                      Maybe we aren't spending our time where we should
                      be.<br>
                      <br>
                      And now a word from our legal team: In order for
                      this to be viable, the system would have to be a<br>
                      *non binding*, *additional* form of input. The top
                      proposal *could* be declined for the same reasons<br>
                      that specs are currently being declined. It would
                      not replace any of our current systems or
                      processes.<br>
                      <br>
                      <br>
                      Assaf Muller, Cloud Networking Engineer<br>
                      Red Hat<br>
                      <br>
                    </div>
                  </div>
                  <span class="">
                    _______________________________________________<br>
                    OpenStack-operators mailing list<br>
                    <a moz-do-not-send="true"
                      href="mailto:OpenStack-operators@lists.openstack.org"
                      target="_blank">OpenStack-operators@lists.openstack.org</a><br>
                    <a moz-do-not-send="true"
href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators"
                      target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators</a><br>
                  </span></blockquote>
              </div>
              <span class="HOEnZb"><font color="#888888"><br>
                  <br clear="all">
                  <div><br>
                  </div>
                  -- <br>
                  <div>
                    <div>Kevin Benton</div>
                  </div>
                </font></span></div>
            <br>
__________________________________________________________________________<br>
            OpenStack Development Mailing List (not for usage questions)<br>
            Unsubscribe: <a moz-do-not-send="true"
href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe"
              target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
            <a moz-do-not-send="true"
              href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"
              target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
            <br>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <pre class="moz-signature" cols="72">-- 
John Kasperski</pre>
  </body>
</html>