On 12/04/16 22:12, Clayton O'Neill wrote:
On Tue, Apr 12, 2016 at 9:09 AM, Sean M. Collins <[email protected]> wrote:
Joseph Bajin wrote:
Maybe I'm wrong about this, maybe all the entries from the etherpads are
read by projects and fed into their pipelines.
They might, but they also might not. There are more etherpads created
than there is human capacity to process. Same thing with bugs and RFEs.
Just making them isn't sufficient.
My point is: Kris had success, I believe, because they went to the
Neutron midcycle and participated directly in the development process.
Neutron developers were informed of their need, consensus was built, and
the work got done.
This sort of story is exactly why I think we should have the Ops
Mid-Cycle colocated with the new Design Summit replacement. I agree
with you that it’s likely the most of the information that’s gathered
in the ether pads isn’t looked at, or isn’t in actionable form. As an
operator it’s hard for me to justify nearly a month of travel for two
summits a year, two Ops mid-cycles a year *and* the Design Summit
replacements twice a year.
Hi Clayton,
Please allow me to clarify some things, because this opinion might be
based on a misconception regarding the proposed event split :)
The developer-centric event is designed to provide a place where
developers can be neck-deep in python code, working on the technical
"how" of implementation without interruption. Unless you're an active
coder, working on the code base of a particular project, it's not the
place to participate in the development process.
Today, the "what" and "why" discussions of the development process that
the majority of ops can more actively participate in are happening at
the individual project mid-cycles. This is what Kris participated in.
However, due to the proposed event split's release cycle changes these
discussions will move to the summit.
Regards,
Tom
_______________________________________________
OpenStack-operators mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
