Open Stack

This is a very good input. Just to clarify on the bug & bp reports. Yes, during the Ops meetups we encourage people to file them and provide as much as possible details on the issue or feature request. In some cases we even file them together to make sure that new operators understand the whole process. I also have to agree with Sean than there are a lot of good information in a unlimited number of ether pads that is impossible to analyze.

So, there you have your startup idea: Have an analytics app that extracts useful details out of a bunch of etherpads.  :-)..

Edgar




On 4/12/16, 7:12 AM, "Clayton O'Neill" <clayton at oneill.net> wrote:

>On Tue, Apr 12, 2016 at 9:09 AM, Sean M. Collins <sean at coreitpro.com> 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.
>
>_______________________________________________
>OpenStack-operators mailing list
>OpenStack-operators at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators