Open Stack

Excerpts from Maish Saidel-Keesing's message of 2015-05-05 19:52:24 +0300:
> 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

Most of the contributor teams meet weekly on IRC, and discuss
priorities in the meeting, here on the mailing list, on the bug
reports, on reviews, etc. -- the usual places. On top of that, the
PTLs and release management team work hard to publish information
about the status of blueprints over the course of the cycle. Is the
problem that you don't know where we're publishing the information
already, or is it in a form that's not easy to understand, or is there
something else about the current process that makes what is already
being written unsuitable for your needs?

> > 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?

Well, in the case of this cycle I expect the ops meetup feedback to be
used for liberty. So the feedback was there in a timely way, but it
seems your expectation for when it can be incorporated may not match up
with the folks doing that work. Is that clearer now?

The team of contributors working on each project is responsible for
incorporating feedback. Making sure the feedback is available in a
useful form has so far been left up to the people providing the
feedback. You seem uncomfortable with that sort of distributed approach,
though.

Doug