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. > 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. 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. > 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
