Open Stack

On 05/05/15 19:22, Doug Hellmann wrote:
> Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15 +0300:
>> On 05/05/15 16:01, Doug Hellmann wrote:
>>> Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700:
>>>> So Thierry I agree. Developers are required to make it happen. I would say
>>>> however that acknowledging the importance of developer contributions and
>>>> selecting leadership from the development community is really half the
>>>> battle as it's pretty rare to see project teams led and governed by only
>>>> developers. I think addressing the inclusion of architects/operators/admins
>>>> within this committee is a hugely positive development.
>>> The community of contributors is led by members, not all of whom
>>> are "developers" -- some are writers, translators, designers, or
>>> fill other important roles. The characteristic that cuts across all
>>> of those roles is that they are *contributors*.
>>>
>>> If "architects/operators/admins" or anyone else want to become
>>> contributors, there is already a path to accomplish that by interacting
>>> with the existing teams, and their insight and input would be very
>>> welcome. But there is no shortcut to becoming a leader in this
>>> community. Everyone has to earn their stripes.
>>>
>>> I've asked a couple of times in this thread what benefit you see
>>> in having someone from outside of the contributor community on the
>>> TC, but I haven't seen an answer. Is there something specific we
>>> could be addressing beyond the question of representation?
>> Hi Doug.
>>
>> It is not only the representation - it is also action on the feedback.
>>
>> There was an OPS summit not so long ago in Philadelphia [1]. Two full
>> days. I personally did not participate but from what I heard it was a
>> good two days of discussions.
> Unfortunately I wasn't able to attend, either, but I've heard the same
> general sentiments of the results.
>
>> There are at least 10 etherpads (Yay!! The OpenStack way of doing
>> things!) that summarized the thoughts and concerns of the participants.
> +1 for writing things down
>
>> I think it would be fair to ask - how many actionable items came out of
>> the this meeting that were implemented in any of the projects? If anyone
>> has answers - they would be highly appreciated.
>> Did the TC follow up on these items?
>> Did the PTL's? (I know some of the PTL's were present there at the summit)
>>
>> Now you might say - that is not their job, but I do think that it should
>> be. The developer teams are asking for feedback the whole time. Saying
>> that Operators are not sending it back their way. Here they are. What
>> was done with all of this?
>>
>> Were bugs raised?
>> Were blueprints submitted to make changes to accommodate any of these
>> requests? Address any of them?
>> Please don't tell me that you are waiting for the Operations people to
>> submit all of these - because it is not going to happen. Most of them do
>> not know how.
> I don't expect them to file blueprints for new features, because
> the contributor responsible for the implementation needs to document
> their plans.
>
> I absolutely *do* expect Operators to file bugs, though, just as
> they would with any other software package they use.
And I sincerely hope that they continue.
>> So here is a process that breaks down. The info is there, but that
>> information is not being followed through upon.
>>
>> Whose responsibility is this? The TC? The Foundation? The PTL's?
>> Here we have proper feedback from those using the products, fighting
>> with (not against) the products and trying to get it working. If even
>> 10% of the items mentioned in these etherpads were addressed (or have a
>> documented plan to be addressed in the future) then I will be very
>> surprised.
> OK, so we're finally getting to the real issues! :-)
>
> What is your expectation for timing? Having a meetup to collect
> feedback like this mid-cycle is unlikely to affect the current
> release in significant ways. For example, bugs may be prioritized
> differently, and I know some were, but we're not likely to stop
> work on features already in progress to work on something new or start
> any large new initiatives at that point in the cycle.
If that process could be a transparent and published - I am sure that 
will beneficial for everyone
> Is the feedback being taken into account during planning for liberty?
> Has someone correlated the feedback with the proposed specs and
> summit sessions? This is normally something I would expect the PTLs
> to be involved with for individual projects, although it might help
> to have a single document listing desired actionable changes from
> those separate etherpads, and someone involved in the meeting is
> probably better able to do that -- it can be difficult to look at
> meeting logs after the fact and extract a summary if you weren't
> in the room when the meeting occurred. Are there summaries of the
> consensus from the meetings?
>
> Looking through a few of the etherpads:
>
> https://etherpad.openstack.org/p/PHL-ops-burning-issues
>
> The first few items in the "burning issues" session look immediately
> actionable, some of them (such as nova-net/neutron migration and
> ceilometer performance improvements) are already under way as
> long-term changes, but some of them are going to need more time to
> solve.
>
> https://etherpad.openstack.org/p/PHL-ops-rabbit-queue
>
> I know the session on Rabbit was very helpful to the Oslo team, and
> we will have some discussions about what to do with the messaging
> library and alternative drivers.
>
> The Oslo team also prioritized the heartbeat bug in part as a result
> of these discussions.
>
> https://etherpad.openstack.org/p/PHL-ops-tags
>
> I've started seeing some new tags proposed to the governance repo.
> Are those a result of the tagging conversation?
>
>> It comes down to this. OpenStack developers have a way of doing things.
>> Operators also have a way of doing things - which is quite different to
>> the way OpenStack does things.
>>
>> If each of these groups continue down the paths they are currently going
>> - never shall the twain meet. They need to come towards each other. The
>> OpenStack community needs be more receptive to the way Operators need
>> things done. Operators need to be more receptive to the way things are
>> done in OpenStack.
>> Yes we have made progress. Yes we will continue to make progress. But
>> until the Operators/users (and you can interchange users with Operators
>> throughout my whole email - I was lazy) are accepted to be part of the
>> decision process in OpenStack (and I think that you can agree - that if
>> that actually happens today - it is way after the fact - or extremely
>> late in the process) then this disconnect is going to continue.
> Yes, I think we all want operator and user input to be included
> much earlier in the process. It remains to be seen if the TC is the
> right group to address those concerns directly, since we tend to
> deal with issues that affect all projects rather than individual
> projects.  That said, there is certainly still a gap in expectations
> for how feedback should be handled, and there's work to do to collect
> it and make sure the right audience sees it, and helping to develop
> the process to facilitate that communication may be something for
> the TC to take on.
So how do we bridge this gap and get the feedback added earlier in the 
development cycle?
And of course the obvious question - with whom does this responsibility lie?
>
>> There is a feeling (at least that is my perception) that code is
>> developed in a vacuum today. Without actually going into the field and
>> asking what is needed - what is being used - what could be made better -
>> before deciding what to write and fix.
> That's an unfortunate impression, and I know it is not always true.
> Many contributors are employed by companies who distribute OpenStack,
> and their work is informed by the feedback they have from their
> customers. Similarly, many contributors are employed by companies
> where they run OpenStack themselves, so they have first-hand
> experience. I'm not personally aware of any contributor who doesn't
> fall into one of those two categories, but there may well be some.
> Either way, those collective experiences may be different, but I
> think very little is happening in a total vacuum.
>
> Doug
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
Best Regards,
Maish Saidel-Keesing