The rally process (email based) doesn’t seem scalable enough for the neutron
case
IMHO, but I agree that a voting system doesn’t differ too much from launchpad
and that it can be gamed.
On 22/4/2015, at 1:21, Assaf Muller amul...@redhat.com wrote:
Just to offer some closure, it seems like
Just to offer some closure, it seems like the voting idea was shot down with
the energy of a trillion stars, yet the general idea of offering an easy way
for users to request features makes sense. Expect to see ideas of how
to implement this soon...
- Original Message -
On Apr 10,
On Apr 10, 2015, at 11:04 AM, Boris Pavlovic bo...@pavlovic.me wrote:
Hi,
I believe that specs are too detailed and too dev oriented for managers,
operators and devops.
They actually don't want/have time to write/read all the stuff in specs and
that's why the communication between
On 04/10/2015 01:04 PM, Boris Pavlovic wrote:
Hi,
I believe that specs are too detailed and too dev oriented for
managers, operators and devops.
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
I like this idea. It leaves specs and implementation details to people
familiar with the code base while providing a good place for users and devs
to discuss feature requests.
On Apr 10, 2015 2:04 PM, John Kasperski jckas...@linux.vnet.ibm.com
wrote:
On 04/10/2015 01:04 PM, Boris Pavlovic
On 9 April 2015 at 17:04, Kyle Mestery mest...@mestery.com wrote:
On Thu, Apr 9, 2015 at 9:52 AM, Assaf Muller amul...@redhat.com wrote:
The Neutron specs process was introduced during the Juno timecycle. At
the time it
was mostly a bureaucratic bottleneck (The ability to say no) to ease the
On Thu, Apr 9, 2015 at 9:52 AM, Assaf Muller amul...@redhat.com wrote:
The Neutron specs process was introduced during the Juno timecycle. At the
time it
was mostly a bureaucratic bottleneck (The ability to say no) to ease the
pain of cores
and manage workloads throughout a cycle. Perhaps
