Re: [openstack-dev] [all] Question for the TC candidates
Stefano Maffulli wrote: I've long come to the conclusion that it is what it is: at the size we're at, we can't expect every voter to be fully informed about all the issues. Better titles and a sort of TL;DR first paragraph in blog posts are very helpful. But in order to write those, the author needs to have more training as a communicator and more time. It's just a hard problem. Devil is in the details. We moved from an in-meeting voting system to an async in-Gerrit voting system, so most of the time the decision is actually made between meetings, when critical mass of voters is reached. Meeting summaries may or may not represent accurately the opinion of all members. Do we need to go through the extra pain of approving meeting minutes at the next meeting ? For the Juno/Kilo cycles we just had periodic reports when something significant was achieved, posted as authored blogposts on the OpenStack blog by a rotation of authors. I understand how that may not be regular enough, and I think the next membership will have to revisit how we communicate the work of the TC out. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 29 April 2015 at 20:48, Thierry Carrez thie...@openstack.org wrote: Stefano Maffulli wrote: I've long come to the conclusion that it is what it is: at the size we're at, we can't expect every voter to be fully informed about all the issues. Better titles and a sort of TL;DR first paragraph in blog posts are very helpful. But in order to write those, the author needs to have more training as a communicator and more time. It's just a hard problem. Devil is in the details. We moved from an in-meeting voting system to an async in-Gerrit voting system, so most of the time the decision is actually made between meetings, when critical mass of voters is reached. Meeting summaries may or may not represent accurately the opinion of all members. Do we need to go through the extra pain of approving meeting minutes at the next meeting ? For the Juno/Kilo cycles we just had periodic reports when something significant was achieved, posted as authored blogposts on the OpenStack blog by a rotation of authors. I understand how that may not be regular enough, and I think the next membership will have to revisit how we communicate the work of the TC out. Most organisations of this size have a secretary whose job is to communicate with various folk, both in and out of the org. Perhaps the TC should elect / ask for a volunteer on of its members to be the TC secretary and be responsible for providing some push (vs pull) insight into the current state of things. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 04/29/15 17:28, Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-04-29 12:59:35 +0300: Again my apologies for the incorrect format - since I am still not receiving the messages from this thread. Please see my comments with the abstracts within (unfortunately not necessarily in the correct order) I think that the point here was that Doug mentioned that there was communication / I believe all of the posts were on the main OpenStack foundation blog // under the technical committee tag [1], and they also went to // planet.openstack.org for folks who subscribe to the entire community // feed. // / Doug - evidently this is not working as it should. As Chris said as well - the posts are not tagged and are not regular. The lack of tags is an oversight, and should be easy to correct. Regarding this /For outgoing communication, during Kilo (and possibly Juno) we tried //blogging meeting summaries. Did folks notice? Were the posts useful?/ They were not noticed - because they didn't really happen. I don't think that's a fair characterization of the effort put into writing the posts. If you didn't see them because they didn't go to the right channel, that's one thing. If you didn't see them because there weren't enough of them, then I think we have different goals. I'm not sure it's as useful to publish on a schedule as it is to publish at meaningful milestones. Perhaps I came across too strong, that was not my intention. The posts were there, maybe not as publicized as well as they could have been, and not as frequent as they could have been, which is why I think it is great that Chris brought this up. If we take this week's meeting [1] as an example, we made some clarifications to existing rules for teams that want to join as official OpenStack projects [2]; we tweaked the description of the Congress project [3] to try to convey what it is for; we approved 5 repos as part of existing projects [4][5][6][7][8]; we updated the PTLs for projects [9]; and then we discussed the cross-project track at the summit. It's not clear those things warrant blog posts. Maybe they do, but aside from the summit planning, and possibly the meeting rule clarification, the others seem trivial enough that they would be noise in a channel we should preserve for communicating more important changes. I honestly don't know. If I was going to write a blog post about that meeting, which topics would you want me to have included? [1] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-04-28-20.02.log.html [2] https://review.openstack.org/175427 [3] https://review.openstack.org/169480 [4] https://review.openstack.org/175620 [5] https://review.openstack.org/172802 [6] https://review.openstack.org/175610 [7] https://review.openstack.org/177070 [8] https://review.openstack.org/176338 [9] https://review.openstack.org/175007 I do not know either, that is something that should be agreed upon. Excerpts from Chris Dent's message of 2015-04-27 17:32:12 +0100: / The only way I've been able to get any sense of what the TC might be // up to is by watching the governance project on gerrit and that tends // to be too soon and insufficiently summarized and thus a fair bit of // work to separate the details from the destinations./ If the audience that you are planning on communicating with is: not the developers themselves and those who are already heavily involved in the community - I think this certainly is not the place to publicize changes. Do you seriously expect people who are trying to find information (not as a regular code contributor) about what is going on to start delving through Gerrit? We have two audiences. The contributors who elect us, and the broader community of deployers, users, etc. I think all of us do what we can individually to engage with that broader community, through meetups, our own blogs, and other channels. I don't expect them to use or read gerrit, or even necessarily subscribe to this list. On the other hand, the developer electorate is quite capable of subscribing to notices about changes happening in the governance repository and it does seem reasonable that if they really want to watch the minutia of TC's deliberations that they *would* take advantage of that capability. That's not to say it should be the only way we communicate, just that the option is there for those interested in using it. I don't think that we are talking about the developer electorate here, they already know how this works. It is trying to make this accessible to those others that are not aware of the intricacies of OpenStack. Not going to happen. Does this mean that the TC has to change the way they make decisions? The TC should do what what they find works for them. But they also need to take into consideration that there are others who are interested in the information - but have no idea how to access it. We need make this more accessible - to those who are not like us.
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Maish Saidel-Keesing's message of 2015-04-29 18:28:45 +0300: On 04/29/15 17:28, Doug Hellmann wrote: Taking as given that we should be open and communicate more, I would like to ask a concrete question. It seems like there is a general sense of concern about communication, but I want to make sure it's not related to ongoing discussions. Is there something specific that happened over the last year that was a surprise, or that was not communicated well? Something we could address in the short term with a blog post or email discussion? How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] I could be wrong, but I don't think that was a TC decision. I believe that was set at the foundation level, since they organize the event. Perhaps part of clearing up communication for the next cycle will need to be explaining who is responsible for different aspects of the community. 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
Re: [openstack-dev] [all] Question for the TC candidates
On 2015-04-29 12:59:35 +0300 (+0300), Maish Saidel-Keesing wrote: [...] Excerpts from Jeremy Stanley's message of 2015-04-28 16:21:17 +: / On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: // [...] // What's important to avoid is the blog postings being only reporting of // conclusions. They also need to be invitations to participate in the // discussions. Yes, the mailing list, gerrit and meeting logs have some // of the ongoing discussions but often, without a nudge, people won't // know. // [...] // // Perhaps better visibility for the meeting agenda would help? As in // these are the major topics we're planning to cover in the upcoming // meeting, everyone is encouraged to attend sort of messaging? // Blogging that might be a bit obnoxious, not really sure (I'm one of // those luddites who prefer mailing lists to blogs so tend not to // follow the latter anyway). / I am not sure that you want people chiming in every single TC meeting - that will become quite chaotic. [...] As a constituent, I feel it's not only my right but also my duty to address the TC on relevant topics if I'm concerned they're not considering certain aspects/implications of what's being deliberated. Arbitrary, off-topic banter from random lurkers is of course unwelcome because it adds unnecessary noise and slows down the meeting, but I do think people who have concerns should be encouraged to participate (keeping to the agenda of course) as long as it's constructive and not preventing the TC from holding a productive meeting. I also attend meetings of the Foundation Board, even though I'm not a board member. As with any government, if you elect people, you should certainly engage with them in appropriate venues. Sometimes that means being present for their public assemblies (be they physical or virtual) so you can participate in those discussions. -- Jeremy Stanley __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 2015-04-29 11:48:36 -0400 (-0400), Doug Hellmann wrote: Excerpts from Maish Saidel-Keesing's message of 2015-04-29 18:28:45 +0300: [...] How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] I could be wrong, but I don't think that was a TC decision. I believe that was set at the foundation level, since they organize the event. [...] Yes, that was a decision made by the event organizers at the OpenStack Foundation, primarily to reduce the planning problems associated with people who exercise the free registration but then don't attend the event. It also allowed them to keep the number of free passes down to a reasonable couple thousands of contributors. To be clear, that decision did not involve the TC at all. Also there has been an effort not to call them ATC passes because the definition of ATC is necessarily tied to the technical committee electorate. Instead these are complimentary passes offered by the OpenStack Foundation for current contributors to make it easier for them to get involved in planning sessions at the Design Summit (which runs in parallel to the conference). While it also gets them access to the conference sessions and expo hall, there are many like me who don't take advantage of that since the Design Summit itself occupies pretty much all of their available time anyway. -- Jeremy Stanley __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Wed, 2015-04-29 at 12:59 +0300, Maish Saidel-Keesing wrote: Again my apologies for the incorrect format - since I am still not receiving the messages from this thread. let me know if you want me to investigate this further. Doug - evidently this is not working as it should. As Chris said as well - the posts are not tagged and are not regular. I'd like to move the conversation to practical examples because in theory we all agree that communication is key and can be improved. In practice, that's hard and it's better to talk about specific examples. They were not noticed - because they didn't really happen. I sense that they happened until there were things fairly easy to communicate. Are there been significant discussions in TC meetings? Yes, the big tent and the accompanying tag system is the only one I can think of. Were they worth a blog post? Yes. Was that blog post easy to write? No because the topic has been under development for quite some time with not enough clear roadmap to write a summary for wider consumption. If a blog post comes out saying something half-baked over a change so important, the TC members will be distracted by noise from people not involved enough to understand the challenges. There is always a fine balance to strike between being open and being effective. Considering that all TC members are volunteers with day jobs, get busier and busier as the release approaches, I'm really not surprised that the TC has scheduled time to present the progress on the 'big tent' and tags in person at events (the operators summit in PHL) and in Vancouver. IMHO the topic is getting clear enough to be summarized in 500-700 words blog post only in the past weeks... The thing is that tags and big tent have been discussed widely *outside* of the TC, I think nobody interested in the OpenStack governance issues may have missed the fact that such conversation was happening. They may have missed the *details* but not missed the existence of the conversation itself. what other topic has the TC discussed and decided upon that have you not seen announced? If the audience that you are planning on communicating with is: not the developers themselves and those who are already heavily involved in the community - I think this certainly is not the place to publicize changes. Do you seriously expect people who are trying to find information (not as a regular code contributor) about what is going on to start delving through Gerrit? Maybe we should document better how to get notifications of new discussions on the governance repository. I could also start including the proposals pending for review in the newsletter so people can at least skim through the commit titles weekly. If you check the latest changes though you'll see how much of that is really not important: https://review.openstack.org/#/q/project:openstack/governance,n,z the important ones I find in 2015: https://review.openstack.org/150604 Add the release naming process https://review.openstack.org/159930 Add IRC channel policies a few new project teams added and the tag-stuff, like https://review.openstack.org/145740 Move from program-based structure to project-based https://review.openstack.org/149961 Introduce tag attributes https://review.openstack.org/145734 Add template for project taxonomy tags definition /stef __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Chris Dent's message of 2015-04-29 18:45:54 +0100: On Wed, 29 Apr 2015, Doug Hellmann wrote: Taking as given that we should be open and communicate more, I would like to ask a concrete question. It seems like there is a general sense of concern about communication, but I want to make sure it's not related to ongoing discussions. Is there something specific that happened over the last year that was a surprise, or that was not communicated well? Something we could address in the short term with a blog post or email discussion? I don't know about others, but for me it has been a general concern and nothing specific. In fact until this subthread went (mildly) boom OK, that's good. I think it's a general concern for the TC, too, in that we do recognize we need to communicate about what we're doing. Knowing that there have been some issues with how that played out in the past is helpful. I had just kind of assumed it was a well known concern and no one would be surprised by it being an issue of import for the coming cycle and beyond. Oh, I'm not surprised, I'm just taking advantage of the opportunity of it having come up and me having time to address it. :-) For what it's worth, I'm not reading this discussion as us disagreeing in any way. We made some reasonable starts at publicizing our ongoing work, but it's clear we can do better from a technical standpoint (tagging posts) and from a volume standpoint (publishing more often). I'm interested in having more input into how best to improve communication, so I keep asking questions and I'm glad you're all still answering. :-) It sounds like you and I are and have been mostly on the same page, finding data, exploring the options, etc. I think it has been pretty productive, at least in the sense that we know more than we did before. +1 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
Re: [openstack-dev] [all] Question for the TC candidates
On 04/29/15 21:59, Stefano Maffulli wrote: On Wed, 2015-04-29 at 18:28 +0300, Maish Saidel-Keesing wrote: How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] This was not a decision of the TC, it was a decision of the Foundation staff. The definition of ATC has *not* changed, that's embedded in the bylaws. I stand corrected. (more than once :) ) Thanks for the clarification Stefano, Doug and Jeremy. And who gets the pass hasn't changed much either: people who are *actively* committing code and documentation to OpenStack have received an invite. Previously we have considered *actively* committing code and docs == ATC. For this cycle the Foundation staff started considering better ways to identify those that actually contribute to the design discussions. The details of who gets a free invite may change again in the future because we want to keep the Open promises, without compromising the event. HTH stef -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Wed, 29 Apr 2015, Doug Hellmann wrote: Taking as given that we should be open and communicate more, I would like to ask a concrete question. It seems like there is a general sense of concern about communication, but I want to make sure it's not related to ongoing discussions. Is there something specific that happened over the last year that was a surprise, or that was not communicated well? Something we could address in the short term with a blog post or email discussion? I don't know about others, but for me it has been a general concern and nothing specific. In fact until this subthread went (mildly) boom I had just kind of assumed it was a well known concern and no one would be surprised by it being an issue of import for the coming cycle and beyond. For what it's worth, I'm not reading this discussion as us disagreeing in any way. We made some reasonable starts at publicizing our ongoing work, but it's clear we can do better from a technical standpoint (tagging posts) and from a volume standpoint (publishing more often). I'm interested in having more input into how best to improve communication, so I keep asking questions and I'm glad you're all still answering. :-) It sounds like you and I are and have been mostly on the same page, finding data, exploring the options, etc. I think it has been pretty productive, at least in the sense that we know more than we did before. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Wed, 2015-04-29 at 18:28 +0300, Maish Saidel-Keesing wrote: How about the fact that the definition of an ATC was changed [1] for a free Summit pass? [2] This was not a decision of the TC, it was a decision of the Foundation staff. The definition of ATC has *not* changed, that's embedded in the bylaws. And who gets the pass hasn't changed much either: people who are *actively* committing code and documentation to OpenStack have received an invite. Previously we have considered *actively* committing code and docs == ATC. For this cycle the Foundation staff started considering better ways to identify those that actually contribute to the design discussions. The details of who gets a free invite may change again in the future because we want to keep the Open promises, without compromising the event. HTH stef __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Maish Saidel-Keesing's message of 2015-04-29 12:59:35 +0300: Again my apologies for the incorrect format - since I am still not receiving the messages from this thread. Please see my comments with the abstracts within (unfortunately not necessarily in the correct order) I think that the point here was that Doug mentioned that there was communication / I believe all of the posts were on the main OpenStack foundation blog // under the technical committee tag [1], and they also went to // planet.openstack.org for folks who subscribe to the entire community // feed. // / Doug - evidently this is not working as it should. As Chris said as well - the posts are not tagged and are not regular. The lack of tags is an oversight, and should be easy to correct. Regarding this /For outgoing communication, during Kilo (and possibly Juno) we tried //blogging meeting summaries. Did folks notice? Were the posts useful?/ They were not noticed - because they didn't really happen. I don't think that's a fair characterization of the effort put into writing the posts. If you didn't see them because they didn't go to the right channel, that's one thing. If you didn't see them because there weren't enough of them, then I think we have different goals. I'm not sure it's as useful to publish on a schedule as it is to publish at meaningful milestones. If we take this week's meeting [1] as an example, we made some clarifications to existing rules for teams that want to join as official OpenStack projects [2]; we tweaked the description of the Congress project [3] to try to convey what it is for; we approved 5 repos as part of existing projects [4][5][6][7][8]; we updated the PTLs for projects [9]; and then we discussed the cross-project track at the summit. It's not clear those things warrant blog posts. Maybe they do, but aside from the summit planning, and possibly the meeting rule clarification, the others seem trivial enough that they would be noise in a channel we should preserve for communicating more important changes. I honestly don't know. If I was going to write a blog post about that meeting, which topics would you want me to have included? [1] http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-04-28-20.02.log.html [2] https://review.openstack.org/175427 [3] https://review.openstack.org/169480 [4] https://review.openstack.org/175620 [5] https://review.openstack.org/172802 [6] https://review.openstack.org/175610 [7] https://review.openstack.org/177070 [8] https://review.openstack.org/176338 [9] https://review.openstack.org/175007 Excerpts from Chris Dent's message of 2015-04-27 17:32:12 +0100: / The only way I've been able to get any sense of what the TC might be // up to is by watching the governance project on gerrit and that tends // to be too soon and insufficiently summarized and thus a fair bit of // work to separate the details from the destinations./ If the audience that you are planning on communicating with is: not the developers themselves and those who are already heavily involved in the community - I think this certainly is not the place to publicize changes. Do you seriously expect people who are trying to find information (not as a regular code contributor) about what is going on to start delving through Gerrit? We have two audiences. The contributors who elect us, and the broader community of deployers, users, etc. I think all of us do what we can individually to engage with that broader community, through meetups, our own blogs, and other channels. I don't expect them to use or read gerrit, or even necessarily subscribe to this list. On the other hand, the developer electorate is quite capable of subscribing to notices about changes happening in the governance repository and it does seem reasonable that if they really want to watch the minutia of TC's deliberations that they *would* take advantage of that capability. That's not to say it should be the only way we communicate, just that the option is there for those interested in using it. Not going to happen. Does this mean that the TC has to change the way they make decisions? The TC should do what what they find works for them. But they also need to take into consideration that there are others who are interested in the information - but have no idea how to access it. We need make this more accessible - to those who are not like us. Yes, I don't think anyone is arguing against that point. The question remains, though: How? Is a blog post a useful medium, or should we be doing something else? Excerpts from Jeremy Stanley's message of 2015-04-28 16:21:17 +: / On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: // [...] // What's important to avoid is the blog postings being only reporting of // conclusions. They also need to be invitations to participate in the // discussions. Yes, the mailing list, gerrit and meeting logs
Re: [openstack-dev] [all] Question for the TC candidates
Thank you for your honest and forthright reply, Chris. I shall respond inline. On 04/28/2015 02:11 PM, Chris Dent wrote: On Tue, 28 Apr 2015, Anita Kuno wrote: At present, I am beginning to wonder to what degree you are being honest with us? Is you intention to know the candidates or to communicate your dissatisfaction with the current blog post situation? You'll note that I didn't have anything to say about the blog situation until this week, after the emails with voting links were already out (I've already voted). That's on purpose. I didn't want to cloud my genuine desire to know the candidates with other issues nor distract this thread for its original purpose until everyone who wanted to had a chance to have their say. There's been another issue (about downstream) that I've not responded to because of exactly this. Thank you for holding your actions true to your original intent, Chris, I appreciate that. One of the issues affecting elections is that our electorate is growing so quickly, fewer people in the electorate feel involved. I appreciate that you withheld your commentary until after you had voted, however voting is still open. I wouldn't have joined the commentary on the blogging issue if there hadn't already been a fair bit of talk about how fixing the feedback loop was one of the roads to improving. Also, critically, when Doug (who I can see is just trying to point out the current picture of reality so I'm not criticizing him, in fact I'd like to laud his efforts in pursuit of write it down which he has mentioned many times) pointed out the existing situation there were, effectively, bugs: * disconnected taxonomy in the presentation of the blogs * misconceptions about the frequency of postings If we can clear up those preconceptions then we can find the stable state from which improvements can be made. I too would like to laud Doug in his efforts to clarify and improve the situation. However I wonder if perhaps the conversation could have taken place in its own thread where others, who possibly didn't want to be seen as weighing in on the candidate's statements thread had thoughts to share on this topic? It is true that I have dissatisfaction about the visibility of the TC and I think a lot of the candidates have made it clear that they are concerned with that issue too. That's great! I am glad that you are feeling your concerns are being addressed. It is detrimental to our overall electoral process if folks cloak personal points of disagreement in the guise of open discussion. I would think that disagreements are in fact exactly the reason for having open discussion and such discussion is one of the best ways to know where people stand. I didn't, however, have that in mind when I responded to clarify things with Doug. Clarifying disagreements and working towards consensus in a respectful way are indeed the purpose of having open discussion. My point is that if our approach to learning about the candidates becomes a platform for folks with personal points of grievance to come to the fore that actually undermines the open discussion process. Apparently my efforts to be lighthearted about that didn't quite play as I planned, and for that I apologize. Thank you, Chris. As I was looking for blog postings I found so _few_ that I assumed any statements of there's 3 here and 4 over there[1] (covering the last greater than a year) were similarly lighthearted. I guess my expectations are way off? I do encourage people who feel that they are unable to understand or access the TC and its activities in a meaningful way to communicate their needs so that the current TC can address those needs. Should there be an attempt to do so and the attempt is dismissed or ignored then it is fair game for a new field of candidates to weigh in. I do continue to hope that candidate statements and responses are helpful to the electorate and that they cast their ballot without feeling that doing so is an indication about their feelings regarding a secondary issue. I can't let this go without making yet another comment. I feel like I should just leave it alone because apparently I'm in deep water You aren't in deep water. I asked if you were being honest. You are indicating in both word choice and tone that you are, I appreciate and respect that, thank you. but: In what fashion is the effectiveness of TC communication a secondary issue? It is difficult for the current field of 19 candidates to discuss TC communication effectively as less than 25% of current candidates had any ability to influence the current situation. Sure if you like we can all say I'll do better but that is not nearly as effective as bringing up the issue with the folks whose decisions created the situation in the first place. I propose that in future should such issues arise that they move to their own thread so that all concerned with that issue feel free to
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Chris Dent's message of 2015-04-27 23:20:39 +0100: On Mon, 27 Apr 2015, Doug Hellmann wrote: I believe all of the posts were on the main OpenStack foundation blog under the technical committee tag [1], and they also went to planet.openstack.org for folks who subscribe to the entire community feed. Ah. Some things about that: * in the right sidebar, under categories, there is no category for the tag technical-committee * assuming the blog is up to date there were three postings in that tag last year, and none so far this year * there are some posts from this year, but they didn't get the tag Obviously we need to work on our consistency, there. :-) I scanned the archives and found a few posts starting in July and covering the big themes of what we were discussing for the last half of Juno. http://www.openstack.org/blog/2014/07/openstack-technical-committee-update-july-1/ http://www.openstack.org/blog/2014/09/latest-technical-committee-updates/ http://www.openstack.org/blog/2014/10/openstack-technical-committee-update-2/ I think this post from Anne was inspired by a discussion we had in a TC meeting, but I'm not sure if it was meant as an update: http://www.openstack.org/blog/2014/12/studying-midcycle-sprints-and-meetings/ And then Thierry's post from this year summarizing the big tent work: http://www.openstack.org/blog/2015/02/tc-update-project-reform-progress/ I didn't find any summaries after that, but I was scanning quickly and might have missed one. The only way I've been able to get any sense of what the TC might be up to is by watching the governance project on gerrit and that tends to be too soon and insufficiently summarized and thus a fair bit of work to separate the details from the destinations. I think we chose blog posts for their relative permanence, and retweetability. Maybe we should post to the mailing list instead, if the contributor community follows the list more regularly than blogs? I think on a blog is a great idea, but my point with above and the earlier message is either that the blogging is not happening or I'm not finding it. The impression I got from your earlier message was that summaries from the meetings were being produced. The TC met more than three times in 2014, yes? So either something is amiss with linking up the blog posts or the summaries aren't happening. We didn't summarize each meeting. There were only meant to be posts every few weeks, since often a topic will take a couple of weeks to iron out. We started in July, mid-way through Juno, which also contributed to a lower count. I think it would be great if there were weekly or montly summaries. They can go to whatever medium is deemed appropriate but it is critical that new folk are able to find them. _Summaries_ are critical as it is important that the information is digested and contextualized so its relevance can be more clear. I know that I can read the IRC logs but I suspect most people don't want to make the time for that. As you say, the meeting logs are published, but it's not reasonable to expect everyone to read those. A fair amount of the discussion is happening in gerrit review comments now, too, and those aren't part of the meeting logs. OTOH, I'm not sure a strict weekly summary is going to be that useful. We do not always resolve all issues in a week, so we won't always have a conclusion to report. Ongoing discussions are tracked either here on the mailing list or in gerrit, and I'm not sure we want to try to duplicate that information to summarize it. So we need to find a balance, and I agree that we need to continue posting summaries. 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
Re: [openstack-dev] [all] Question for the TC candidates
On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: [...] What's important to avoid is the blog postings being only reporting of conclusions. They also need to be invitations to participate in the discussions. Yes, the mailing list, gerrit and meeting logs have some of the ongoing discussions but often, without a nudge, people won't know. [...] Perhaps better visibility for the meeting agenda would help? As in these are the major topics we're planning to cover in the upcoming meeting, everyone is encouraged to attend sort of messaging? Blogging that might be a bit obnoxious, not really sure (I'm one of those luddites who prefer mailing lists to blogs so tend not to follow the latter anyway). -- Jeremy Stanley __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Jeremy Stanley's message of 2015-04-28 16:21:17 +: On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: [...] What's important to avoid is the blog postings being only reporting of conclusions. They also need to be invitations to participate in the discussions. Yes, the mailing list, gerrit and meeting logs have some of the ongoing discussions but often, without a nudge, people won't know. [...] Perhaps better visibility for the meeting agenda would help? As in these are the major topics we're planning to cover in the upcoming meeting, everyone is encouraged to attend sort of messaging? Blogging that might be a bit obnoxious, not really sure (I'm one of those luddites who prefer mailing lists to blogs so tend not to follow the latter anyway). The agenda is managed in the wiki [1] and Thierry sends a copy to the openstack-tc mailing list every week. Maybe those should come here to this list, with the topic tag [tc], instead? Doug [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Mon, 2015-04-27 at 17:00 -0400, Doug Hellmann wrote: I would have to go back and check, but I'm pretty sure the posts were highlighted in Stef's community newsletter email. They were, in fact. But I know as a fact that even if people many love the newsletter, I have the impression that few people follow the links. The blog posts from the TC were on openstack.org/blog, on planet.openstack.org, relayed on twitter and mentioned in the weekly newsletter. I don't think we can give more visibility than this without getting annoying. Maybe better titles and leads in the posts would help more. The problem is that there is just too much traffic and it's impossible for anyone to keep up with everything. People skim through their emails checking the subjects, their rss feeds reading only the titles, parsing twitter feed for a couple of pages down (at best) and that's it. If nothing catches their attention, pieces of information get lost. Even the weekly newsletter I'm sure few people click to follow the links and read further (unless it has a cool title). I've long come to the conclusion that it is what it is: at the size we're at, we can't expect every voter to be fully informed about all the issues. Better titles and a sort of TL;DR first paragraph in blog posts are very helpful. But in order to write those, the author needs to have more training as a communicator and more time. It's just a hard problem. /stef __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 04/23/2015 12:14 PM, Chris Dent wrote: This might be a bit presumptuous, but why not give it a try... This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think it would be useful to get answers from the candidates on at least one topical but open-ended question. Maybe other people have additional questions they think are important but this one is the one that matters to me and also captures the role that I wish the TC filled more strongly. Here's the preamble: There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. There are many different ways to define quality. For the sake of this question feel free to use whatever definition you like but take it as given that quality needs to be improved. Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Chris: I welcomed your question as I welcome all questions from the electorate with the intention and motivation of getting to know the candidates better, hopefully to improve engagement in the electoral process and to increase the extent to which people feel a part of the structure they participate in. At present, I am beginning to wonder to what degree you are being honest with us? Is you intention to know the candidates or to communicate your dissatisfaction with the current blog post situation? It is detrimental to our overall electoral process if folks cloak personal points of disagreement in the guise of open discussion. Going forward, I encourage those who actually would like to get to know all candidates in an electoral contest better to ask all the candidates fair questions and let them respond. Should something come from that, please follow up in a neutral way that does not weigh down the impartial nature (hopefully) intended by the original question. I do continue to hope that candidate statements and responses are helpful to the electorate and that they cast their ballot without feeling that doing so is an indication about their feelings regarding a secondary issue. My thanks, Anita. __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Tue, 2015-04-28 at 16:30 +0100, Chris Dent wrote: What's important to avoid is the blog postings being only reporting of conclusions. They also need to be invitations to participate in the discussions. Yes, the mailing list, gerrit and meeting logs have some of the ongoing discussions but often, without a nudge, people won't know. Not being a member of the TC, I have noticed that the hottest topics touched by the TC were indeed discussed on this list quite extensively. I'm sure you've not missed the conversation about big tent, tags, release naming process, the use of secret IRC channels, etc. Important conversations happen on this list first, then move to the tc and eventually become decisions published on http://governance.openstack.org. Applications of new projects also are discussed on this list before they land on TC meeting agenda. The mailing list of the TC is open and is low traffic. The agenda is published there regularly: people who care about the TC and *have time to spare* are on that list. If you haven't seen many blog posts in 2015 is because the most important change is the 'big tent' and its tagging system. My feeling is that this topic is so huge that it will take another cycle before it can be digested, nobody yet considers it 'completed' enough to summarize in a blog post. I expect that after the release and the Summit the topic will be more clear. BTW, add this session to your calendar for Vancouver: http://openstacksummitmay2015vancouver.sched.org/event/4f51d5c18865d24d9a8fbb5a0603f0c9 I'm not trying to suggest that the TC is trying to keep people in the dark, rather that it always takes more effort than anyone would like to make sure things are lit. I have the feeling that the largest and most important changes are being communicated widely. They're hard and complex and will require time and more efforts by all (not just TC members) before they're also understood properly. It'll take time. .stef __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Tue, 28 Apr 2015, Anita Kuno wrote: At present, I am beginning to wonder to what degree you are being honest with us? Is you intention to know the candidates or to communicate your dissatisfaction with the current blog post situation? You'll note that I didn't have anything to say about the blog situation until this week, after the emails with voting links were already out (I've already voted). That's on purpose. I didn't want to cloud my genuine desire to know the candidates with other issues nor distract this thread for its original purpose until everyone who wanted to had a chance to have their say. There's been another issue (about downstream) that I've not responded to because of exactly this. I wouldn't have joined the commentary on the blogging issue if there hadn't already been a fair bit of talk about how fixing the feedback loop was one of the roads to improving. Also, critically, when Doug (who I can see is just trying to point out the current picture of reality so I'm not criticizing him, in fact I'd like to laud his efforts in pursuit of write it down which he has mentioned many times) pointed out the existing situation there were, effectively, bugs: * disconnected taxonomy in the presentation of the blogs * misconceptions about the frequency of postings If we can clear up those preconceptions then we can find the stable state from which improvements can be made. It is true that I have dissatisfaction about the visibility of the TC and I think a lot of the candidates have made it clear that they are concerned with that issue too. That's great! It is detrimental to our overall electoral process if folks cloak personal points of disagreement in the guise of open discussion. I would think that disagreements are in fact exactly the reason for having open discussion and such discussion is one of the best ways to know where people stand. I didn't, however, have that in mind when I responded to clarify things with Doug. Apparently my efforts to be lighthearted about that didn't quite play as I planned, and for that I apologize. As I was looking for blog postings I found so _few_ that I assumed any statements of there's 3 here and 4 over there[1] (covering the last greater than a year) were similarly lighthearted. I guess my expectations are way off? I do continue to hope that candidate statements and responses are helpful to the electorate and that they cast their ballot without feeling that doing so is an indication about their feelings regarding a secondary issue. I can't let this go without making yet another comment. I feel like I should just leave it alone because apparently I'm in deep water but: In what fashion is the effectiveness of TC communication a secondary issue? No, we're not going to solve it immediately and really we don't need to hash over the policies and procedures of the past. We might, however, like to make it better for the future. [1] This statement is not a quote and is not even supposed to be a representation of any truth, just a conveyance of the feeling of the moment, thank you very much. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Jeremy Stanley wrote: On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: [...] What's important to avoid is the blog postings being only reporting of conclusions. They also need to be invitations to participate in the discussions. Yes, the mailing list, gerrit and meeting logs have some of the ongoing discussions but often, without a nudge, people won't know. [...] Perhaps better visibility for the meeting agenda would help? As in these are the major topics we're planning to cover in the upcoming meeting, everyone is encouraged to attend sort of messaging? Blogging that might be a bit obnoxious, not really sure (I'm one of those luddites who prefer mailing lists to blogs so tend not to follow the latter anyway). What about having a IRC bot that announces meetings + agends (based on some calendar/config file/other...), then people could log-in to say a #openstack-meeting-announce channel and be notified of meetings that are about to start (including the TC one...); could be useful? and then if people complain well u can say there exists a channel where all this notification happens (and if they think it to noisy, leave the channel)... -Josh __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 04/28/2015 12:42 PM, Doug Hellmann wrote: Excerpts from Jeremy Stanley's message of 2015-04-28 16:21:17 +: On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: [...] What's important to avoid is the blog postings being only reporting of conclusions. They also need to be invitations to participate in the discussions. Yes, the mailing list, gerrit and meeting logs have some of the ongoing discussions but often, without a nudge, people won't know. [...] Perhaps better visibility for the meeting agenda would help? As in these are the major topics we're planning to cover in the upcoming meeting, everyone is encouraged to attend sort of messaging? Blogging that might be a bit obnoxious, not really sure (I'm one of those luddites who prefer mailing lists to blogs so tend not to follow the latter anyway). The agenda is managed in the wiki [1] and Thierry sends a copy to the openstack-tc mailing list every week. Maybe those should come here to this list, with the topic tag [tc], instead? Doug [1] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee I'd much prefer it on openstack-dev with the [tc] tag, I wasn't aware the agenda was emailed out at all. -- Ryan Brown / Software Engineer, Openstack / Red Hat, Inc. __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Joshua Harlow's message of 2015-04-28 11:30:01 -0700: Jeremy Stanley wrote: On 2015-04-28 16:30:21 +0100 (+0100), Chris Dent wrote: [...] What's important to avoid is the blog postings being only reporting of conclusions. They also need to be invitations to participate in the discussions. Yes, the mailing list, gerrit and meeting logs have some of the ongoing discussions but often, without a nudge, people won't know. [...] Perhaps better visibility for the meeting agenda would help? As in these are the major topics we're planning to cover in the upcoming meeting, everyone is encouraged to attend sort of messaging? Blogging that might be a bit obnoxious, not really sure (I'm one of those luddites who prefer mailing lists to blogs so tend not to follow the latter anyway). What about having a IRC bot that announces meetings + agends (based on some calendar/config file/other...), then people could log-in to say a #openstack-meeting-announce channel and be notified of meetings that are about to start (including the TC one...); could be useful? and then if people complain well u can say there exists a channel where all this notification happens (and if they think it to noisy, leave the channel)... Another option is to register #startmeeting as a notification word in your IRC client and lurk in the meeting channels. 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
Re: [openstack-dev] [all] Question for the TC candidates
On Tue, 28 Apr 2015, Doug Hellmann wrote: Thanks very much for the information about this stuff thus far. To take the discussion to its logical extreme, for the sake of the discussion and not (just) to be snarky, I want to respond to something from this last paragraph We do not always resolve all issues in a week, so we won't always have a conclusion to report. Ongoing discussions are tracked either here on the mailing list or in gerrit, and I'm not sure we want to try to duplicate that information to summarize it. What's important to avoid is the blog postings being only reporting of conclusions. They also need to be invitations to participate in the discussions. Yes, the mailing list, gerrit and meeting logs have some of the ongoing discussions but often, without a nudge, people won't know. If, in fact, improved engagement between the TC and everyone else is desired then a lot of effort is going to be required (from both sides of the engagement). I'm not trying to suggest that the TC is trying to keep people in the dark, rather that it always takes more effort than anyone would like to make sure things are lit. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 23/04/15 17:14 +0100, Chris Dent wrote: This might be a bit presumptuous, but why not give it a try... This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think it would be useful to get answers from the candidates on at least one topical but open-ended question. Maybe other people have additional questions they think are important but this one is the one that matters to me and also captures the role that I wish the TC filled more strongly. Here's the preamble: There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. There are many different ways to define quality. For the sake of this question feel free to use whatever definition you like but take it as given that quality needs to be improved. Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Thanks for bringing this up, Chris. First and foremost, sorry for my late answer. I just got back from a trip w/ limited internet access. With the latest changes in governance model, I believe we need to be very observant of the changes happening in our community. As I mentioned in my candidacy, new projects will start showing up and they'll want to join the OpenStack organization. While this is amazing, we need to have a scalable - yes, hard to do - way to guide those projects whenever it's needed. Therefore, I believe one thing we need to do is improve the communication between the TC and the commuity. I've heard a couple of times from members in our that it's sometimes hard to communicate with the TC and most of the times, it's not clear for them when certain topics should/shouldn't involve the TC. This, to me, is cause by a lack of communication between the TC and the community. Either we're failing to explain what the TC is there for or the communication channels between the TC and the rest of the community are not good enough. Note that I've emphasized comunication and not a very specific plan towards quality. The reason being that I believe that a good communication between the TC and the rest of the community will help with defining those guidelines I mentioned before and a good workflow that would help projects to improve their quality and that would also help developers to improve their experience in the community. Staying out of the way of projects sounds exciting but we still need to be almost-silent observers/actors in project's lifes to make sure the right people/projects are talking to each other. I'm a big believer in collaboration and I think that we should strive for it as much as possible and the TC should be there to help. This all will improve the quality of our projects in the long run as we'll be developing experiences that will be available for other projects to consume. That was from a TC perspective. Now, from a project perspective, I believe the TC needs to be vigilant and ensure that projects have all the tools and resources to be productive and independent. This goes along with what I said above. New groups have been born that should help improving different areas - API WG, for example - and these groups need to communicate with the rest of the community. We sould encourage folks from different projects to be part of these groups and contribute. Pretty much like we encourage folks to be part of Oslo, or at the very least follow its developments. Thanks for reading, Flavio -- @flaper87 Flavio Percoco pgpJQHL6bMxfr.pgp Description: PGP signature __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Chris Dent's message of 2015-04-27 17:32:12 +0100: On Mon, 27 Apr 2015, Doug Hellmann wrote: For outgoing communication, during Kilo (and possibly Juno) we tried blogging meeting summaries. Did folks notice? Were the posts useful? Is there a TC specific blog place of interest? I sometimes stumble on blog postings from people I know are TC people but I'm not sure if they are speaking in-their-position-as. And there is the governance category on the The OpenStack Blog with subjects that begin OpenStack Technical Committee Update:, but the last one of those that I can find is from February, so I assume you must mean somewhere else? Where do you mean? I believe all of the posts were on the main OpenStack foundation blog under the technical committee tag [1], and they also went to planet.openstack.org for folks who subscribe to the entire community feed. The only way I've been able to get any sense of what the TC might be up to is by watching the governance project on gerrit and that tends to be too soon and insufficiently summarized and thus a fair bit of work to separate the details from the destinations. I think we chose blog posts for their relative permanence, and retweetability. Maybe we should post to the mailing list instead, if the contributor community follows the list more regularly than blogs? Doug [1] http://www.openstack.org/blog/tag/technical-committee/ __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Richard Raseley's message of 2015-04-27 12:55:11 -0700: Doug Hellmann wrote: I think we chose blog posts for their relative permanence, and retweetability. Maybe we should post to the mailing list instead, if the contributor community follows the list more regularly than blogs? I like blog posts for the reasons you mentioned. Perhaps sending a message to the list with the link to the post (or some semi-regular digest) would bridge the gap? I would have to go back and check, but I'm pretty sure the posts were highlighted in Stef's community newsletter email. Not that we couldn't do something similar here, but I wouldn't want this email list to turn into an RSS mirror. Maybe we need to publicize the fact that those posts are going up in general, rather than each individual post. 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
Re: [openstack-dev] [all] Question for the TC candidates
Doug Hellmann wrote: I think we chose blog posts for their relative permanence, and retweetability. Maybe we should post to the mailing list instead, if the contributor community follows the list more regularly than blogs? I like blog posts for the reasons you mentioned. Perhaps sending a message to the list with the link to the post (or some semi-regular digest) would bridge the gap? Regards, Richard __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Excerpts from Flavio Percoco's message of 2015-04-27 08:52:01 +0200: On 23/04/15 17:14 +0100, Chris Dent wrote: This might be a bit presumptuous, but why not give it a try... This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think it would be useful to get answers from the candidates on at least one topical but open-ended question. Maybe other people have additional questions they think are important but this one is the one that matters to me and also captures the role that I wish the TC filled more strongly. Here's the preamble: There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. There are many different ways to define quality. For the sake of this question feel free to use whatever definition you like but take it as given that quality needs to be improved. Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Thanks for bringing this up, Chris. First and foremost, sorry for my late answer. I just got back from a trip w/ limited internet access. With the latest changes in governance model, I believe we need to be very observant of the changes happening in our community. As I mentioned in my candidacy, new projects will start showing up and they'll want to join the OpenStack organization. While this is amazing, we need to have a scalable - yes, hard to do - way to guide those projects whenever it's needed. Therefore, I believe one thing we need to do is improve the communication between the TC and the commuity. I've heard a couple of times from members in our that it's sometimes hard to communicate with the TC and most of the times, it's not clear for them when certain topics should/shouldn't involve the TC. This, to me, is cause by a lack of communication between the TC and the community. Either we're failing to explain what the TC is there for or the communication channels between the TC and the rest of the community are not good enough. I often say that most issues, even apparently technical issues, are caused by bad communication. So, I'm concerned that there are members of the community who don't know how to communicate with the TC. The best way to reach the entire committee is to email this list (openstack-dev) using [tc] in the subject line of your message. Regarding subjects where the TC should or should not be involved, I think the safest thing to do is ask. We would at least at that point help clarify who should be resolving a particular issue if we think it isn't the TC. For outgoing communication, during Kilo (and possibly Juno) we tried blogging meeting summaries. Did folks notice? Were the posts useful? 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
Re: [openstack-dev] [all] Question for the TC candidates
On 27/04/15 08:46 -0400, Doug Hellmann wrote: Excerpts from Flavio Percoco's message of 2015-04-27 08:52:01 +0200: On 23/04/15 17:14 +0100, Chris Dent wrote: This might be a bit presumptuous, but why not give it a try... This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think it would be useful to get answers from the candidates on at least one topical but open-ended question. Maybe other people have additional questions they think are important but this one is the one that matters to me and also captures the role that I wish the TC filled more strongly. Here's the preamble: There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. There are many different ways to define quality. For the sake of this question feel free to use whatever definition you like but take it as given that quality needs to be improved. Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Thanks for bringing this up, Chris. First and foremost, sorry for my late answer. I just got back from a trip w/ limited internet access. With the latest changes in governance model, I believe we need to be very observant of the changes happening in our community. As I mentioned in my candidacy, new projects will start showing up and they'll want to join the OpenStack organization. While this is amazing, we need to have a scalable - yes, hard to do - way to guide those projects whenever it's needed. Therefore, I believe one thing we need to do is improve the communication between the TC and the commuity. I've heard a couple of times from members in our that it's sometimes hard to communicate with the TC and most of the times, it's not clear for them when certain topics should/shouldn't involve the TC. This, to me, is cause by a lack of communication between the TC and the community. Either we're failing to explain what the TC is there for or the communication channels between the TC and the rest of the community are not good enough. I often say that most issues, even apparently technical issues, are caused by bad communication. So, I'm concerned that there are members of the community who don't know how to communicate with the TC. The best way to reach the entire committee is to email this list (openstack-dev) using [tc] in the subject line of your message. Regarding subjects where the TC should or should not be involved, I think the safest thing to do is ask. We would at least at that point help clarify who should be resolving a particular issue if we think it isn't the TC. This is exactly what concerns me and I think it's not clear to the overall community. By improving this communication, we will also help improving projects, the overall community and the developer's experience. For outgoing communication, during Kilo (and possibly Juno) we tried blogging meeting summaries. Did folks notice? Were the posts useful? I noticed and they were useful for me. Did others notice? Flavio -- @flaper87 Flavio Percoco pgppRJp763HdY.pgp Description: PGP signature __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Chris, apologies for the late reply. No real excuse other than I wanted to hear what the other candidates had to say and listen a bit before I responded. On 04/23/2015 12:14 PM, Chris Dent wrote: Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Broad question :) I think there's a couple things we (the TC) could do to improve the quality of OpenStack for developers: = Focus on the public APIs = No surprise here, but I'm a bit proponent of improving the consistency, usability, and documentation of our public APIs. I say public APIs because while I love the fact that the API working group has thus far focused on the RESTful APIs, I also think we should put some focus on non-RESTful APIs, like our notification message format, our RPC APIs (not currently public, but perhaps should be especially when things like the Nova scheduler are fully broken out). The REST APIs are the first impression our community makes to our developer community. It should be a good impression. The guidance of the API working group should continue, and I think that we should also begin to produce recommendations for cleaning up the *existing* APIs of the OpenStack projects. = Start a working group for building applications on top of OpenStack = We have the Win the Enterprise working group. IMHO, we would do well to have a Win the Future working group that focuses on *modern* cloud application architecture and needs, and not legacy stuff. Such a working group would be responsible for building a modern, distributed application reference that would use the various OpenStack APIs for infrastructure and platform management. It would showcase what can be done with and on OpenStack deployments. And for operators of OpenStack, here's a couple ideas on things the TC could do to improve the quality of OpenStack for our operator community: = Have a monthly Feedback from Operators conversation = Dedicate part or all of one TC IRC meeting time per month to discuss operator feedback. Invite the operator community to come and tell us what has improved, what needs improving, and how the TC can find advocates in the contributor community to sponsor bugs and blueprints that operators need worked on. = Develop a set of operator:XXX tags = One big idea in the big tent initiative is to have more fine-grained tags that describe useful information to specific audiences. The TC can have a process (survey?) that gathers operator feedback on specific tags as they are applied to particular projects. For instance, we might work with the operator community to come up with a definition of a operator:scales-to-100-nodes (totally random example) that would apply to projects that the operator community verifies work at that particular scale. Have the operator community vote on whether various projects in the OpenStack code namespace have been deployed at that particular scale by the operator. Anyway, those a just a few ideas. I'm looking forward to listening to new ideas from the newly elected TC members (regardless of whether I'm given the opportunity to be one of them ;) Best, -jay __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Mon, 27 Apr 2015, Doug Hellmann wrote: I believe all of the posts were on the main OpenStack foundation blog under the technical committee tag [1], and they also went to planet.openstack.org for folks who subscribe to the entire community feed. Ah. Some things about that: * in the right sidebar, under categories, there is no category for the tag technical-committee * assuming the blog is up to date there were three postings in that tag last year, and none so far this year * there are some posts from this year, but they didn't get the tag The only way I've been able to get any sense of what the TC might be up to is by watching the governance project on gerrit and that tends to be too soon and insufficiently summarized and thus a fair bit of work to separate the details from the destinations. I think we chose blog posts for their relative permanence, and retweetability. Maybe we should post to the mailing list instead, if the contributor community follows the list more regularly than blogs? I think on a blog is a great idea, but my point with above and the earlier message is either that the blogging is not happening or I'm not finding it. The impression I got from your earlier message was that summaries from the meetings were being produced. The TC met more than three times in 2014, yes? So either something is amiss with linking up the blog posts or the summaries aren't happening. I think it would be great if there were weekly or montly summaries. They can go to whatever medium is deemed appropriate but it is critical that new folk are able to find them. _Summaries_ are critical as it is important that the information is digested and contextualized so its relevance can be more clear. I know that I can read the IRC logs but I suspect most people don't want to make the time for that. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 23 April 2015 at 09:14, Chris Dent chd...@redhat.com wrote: This might be a bit presumptuous, but why not give it a try... This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think it would be useful to get answers from the candidates on at least one topical but open-ended question. Maybe other people have additional questions they think are important but this one is the one that matters to me and also captures the role that I wish the TC filled more strongly. Here's the preamble: There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. There are many different ways to define quality. For the sake of this question feel free to use whatever definition you like but take it as given that quality needs to be improved. Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? I am possibly the latest candidate to respond to this thread...what a lousy candidate that I am! :) Without incurring the risk of becoming incredibly verbose, and trying to keep this discussion down to earth, one thing I would like to see happen is addressing the sort of quality that can be qualitatively measured on an ongoing basis. For instance, to date we cannot tell at any given time (and without support of downstream tools) whether certain key operations (like VM boot) have degraded because of a specific change (if there is, as a developer I'd be keen to learn how to take advantage of it, but that's another discussion)! For instance, when I was at VMware and in charge of 3rd party CI, I designed a small mechanism to track the mobile average of test run times that would tell a developer the impact of his/her change to the overall performance of the system (single devstack). For instance, in change [1], the VMware CI reported back 94.32% faster than the average run time. That clearly meant that the change had no negative impact to the operations that involved the VMware plugin for Neutron. Had that number been 150%, that would have alerted a reviewer and triggered further analysis. That number is obviously a coarse grained way of capturing quality, and may have its own flaws but I found it incredibly useful and I would like to see something along those lines be implemented in Zuul. Anyhow, I hope you get the gist, should you want to know more, I guess you'd have to vote for me :P Cheers, Armando [1] https://review.openstack.org/#/c/80387/ -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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 __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Apr 27, 2015, at 9:20 AM, Jay Pipes jaypi...@gmail.com wrote: = Have a monthly Feedback from Operators conversation = Dedicate part or all of one TC IRC meeting time per month to discuss operator feedback. Invite the operator community to come and tell us what has improved, what needs improving, and how the TC can find advocates in the contributor community to sponsor bugs and blueprints that operators need worked on. +1! -- Ed Leafe signature.asc Description: Message signed with OpenPGP using GPGMail __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Mon, 27 Apr 2015, Doug Hellmann wrote: For outgoing communication, during Kilo (and possibly Juno) we tried blogging meeting summaries. Did folks notice? Were the posts useful? Is there a TC specific blog place of interest? I sometimes stumble on blog postings from people I know are TC people but I'm not sure if they are speaking in-their-position-as. And there is the governance category on the The OpenStack Blog with subjects that begin OpenStack Technical Committee Update:, but the last one of those that I can find is from February, so I assume you must mean somewhere else? Where do you mean? The only way I've been able to get any sense of what the TC might be up to is by watching the governance project on gerrit and that tends to be too soon and insufficiently summarized and thus a fair bit of work to separate the details from the destinations. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Chris Dent wrote: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? At a strategic level, as I mention in my candidacy email, I think we have naturally done a reasonably good job at serving a middle-tier use case. However, the natural forces that drive OpenStack development (basically the interests of the companies funding most of the development) won't naturally drive us to well supporting the other tiers: small deployments / POC / university lab experimentation on one side, and large public cloud needs on the other. And those are essential to the long-term success of OpenStack. While the Technical Committee has a limited influence (as it doesn't, per se, drive development resources), I still think it can highlight the importance of those use cases and encourage project teams to integrate them in their priorities and roadmaps. At a tactical level, I think Technical Committee members are well-placed to take a step back on OpenStack as a whole and notice long-standing issues, investigate them and propose solutions. The TC has been traditionally staffed with very busy people that had little time to dedicate to deeper issues: just keeping up with governance model updates was enough to keep everyone busy. As chair, Technical Committee matters represent nearly half of my work time. With 3 members stepping down, this election is the occasion to select new blood that may be able to commit the same part of their worktime. If elected, I intend to encourage Technical Committee members to follow those directions, to form smaller workgroups and work on issues beyond the weekly meeting. That should allow us to address those long-standing, cross-project issues that durably impact quality for developers, end-users and operators of OpenStack. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Hello Chris, and thank you for posting this question. First I must apologize since I was not able to answer this thread earlier - due to a problem with me receiving the emails from the list. I had to ask the election committee how to add my answer to the thread, I hope this attempt works forgive me if the formatting in this answer comes out a bit weird. There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. I think that there is a basic misconception here - and that is one of the reasons I decided to run. You mentioned the stakeholders - developers, end-users, and operators. Yes they all have a direct interaction with the community and the products being written, but I think it is safe to say that they all interact on a very different level. Their is a very clear hierarchy here - even if it has not been explicitly defined. These stakeholders are not equal. I am not saying that they should be equal but I do think that the current balance is nowhere near the way it should be - so that it is beneficial for each of these groups. What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? A solution is only as good as those who use it. Those who use it will only do so it if it useful to them. They will use it when it can solve a problem they have. They will use it when they know there is someone one the other side who is receptive to their questions, their suggestions and their input. I think that the TC in the upcoming terms should find a way to help each of the teams and their PTL's prioritize what should be done in the next two cycles (because that is what the election term is for). This should be based on the aspirations of each of the teams, but it also must consider the feedback from both the users and the operators as to what features they would like to see implemented and what things need to be fixed. As for me personally, if elected, I would like to invest my efforts in finding a way to get that feedback back into the TC and further down into each of the products. we have several initiatives running in parallel today, and I hope that I can find a way to allow this information to flow back in a more streamlined manner in order to improve the quality of each of the projects and help them meet the needs of the people who are actually going to be using it. In addition to the above, I do believe the quality of the product will improve if we become more receptive to input from those who are not writing the code. Today that is a substantial hurdle for most end-users and operators, something that I would like to try and make accessible - without lowering the quality of the code and our products. It is fine balance - yet one that I think it is all of our best interests to find, hard as it may be. -- Best Regards, Maish Saidel-Keesing __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Thu, Apr 23, 2015 at 11:14 AM, Chris Dent chd...@redhat.com wrote: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? One thing that I see as an indicator of quality is how a system fits together. Does it feel like a well-designed cohesive unit or a collection of individually well-designed parts? Current indications are that OpenStack feels to most people like a collection of parts. I believe it is the TC's responsibility to facilitate and encourage the cross-project communication required to achieve a cohesive whole. Work is already being done with this goal in mind, for example Thierry leads a weekly cross-project meeting for exactly this purpose, to facilitate communication between projects. I do think he is wearing his Release Manager hat then, but that further illustrates that it is not the TC that need to be doing the work, but they should be setting the direction and expectations, and providing a framework within which to operate. With all of the talk about the TC needing to 'get out of the way', I also believe that one of the responsibilities it has in technical leadership is to make some hard decisions when something is not working. I know I sometimes have difficulty knowing when a project I am working on is going nowhere because I am too close to it. I need someone with perspective to let me know what I can not see for myself. To put it into the Big Tent metaphor, someone has to occasionally clean the elephant poo out of the tent. Fortunately this has been a rare event so far in OpenStack's history, but the opening of the tent flaps changes that activity from an up-front one to an after-the-fact one and the TC must not forget that building a quality product is both including quality parts and assemblies, and removing the lesser quality ones. As I said before, the majority of my time with OpenStack has been in cross-project activities and I get a first-hand taste of what people have to do to work with it. It is not pretty. There already are working groups addressing two of the most glaring inconsistent areas: APIs and log files. The TC role here is to encourage and support these groups and prompt others to form where they will be able to do good work. I have staked my future with OpenStack to two areas that both need this attention and I work every day to provide frameworks for developers and those wanting to do small-scale exercises, and for deployers and end-users who need to actually use an OpenStack cloud. I think that the next level for that vision is strengthen that from within the TC itself. dt -- Dean Troyer dtro...@gmail.com __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Apr 23, 2015, at 11:14 AM, Chris Dent chd...@redhat.com wrote: This might be a bit presumptuous, but why not give it a try… Presumptuous? Nah, any candidate should be willing to answer questions. This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think it would be useful to get answers from the candidates on at least one topical but open-ended question. Maybe other people have additional questions they think are important but this one is the one that matters to me and also captures the role that I wish the TC filled more strongly. Here's the preamble: [snip] Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? You really weren't kidding about it being open-ended, huh? :) Let me start with developers, since that's the area that's closest to home for me, and especially Nova developers, since that's where my focus is. For devs who are new to contributing to Nova, the biggest frustration is the sheer amount of time it takes to get a patch reviewed. Sure, different reviewers will focus on different things, and will ask you to fix this or that, but you expect that if you've been working in open source for any length of time. What you don't expect is that you work on something, test the hell out of it, and submit it, only to… wait. And wait. And then rebase because it's been sitting so long. And then wait some more. This isn't the result of reviewers being lazy; it's the result of having too few people available compared to the number of patches in need of review. I would like to see the TC take an active role in helping various teams set up training for new potential core reviewers where there is a shortage to help alleviate this bottleneck. I'm not sure what you see as the difference between the end users and the operators of OpenStack, because in my mind they are one and the same. I don't consider the people using, say, public cloud services to be OpenStack end users, because ultimately they just want stuff that works, and if it doesn't, they'll blame the provider, not OpenStack. I see our end users as the people who deploy and run OpenStack clouds. I'd like to see the core of OpenStack defined more clearly (i.e., Monty's Layer #1 [0]), and everything else able to be added as needed. The current situation is a bit confusing, because there are just so many pieces that one can put together to get something called 'OpenStack'. The Big Tent movement is great, and I'm all for it, but I can see the growth of these 'parts' causing a lot of pain to operators if they don't all work the same way. We know that there is pain now getting things to play together nicely; having dozens more potential pieces would make things much worse for ops. Project that have interfaces that are clearly defined, however, will allow for a much better loose coupling of these parts, and would go a long way to making the work that operators do to integrate things smoother. I think efforts such as the API Working Group is an excellent start in this direction, and I would push for other such standards. They aren't mandatory, but if your project doesn't follow them, you're probably not going to win many friends in the ops community. [0] http://superuser.openstack.org/articles/openstack-as-layers-but-also-a-big-tent-but-also-a-bunch-of-cats -- Ed Leafe signature.asc Description: Message signed with OpenPGP using GPGMail __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 24/04/15 09:00, Ed Leafe wrote: I'm not sure what you see as the difference between the end users and the operators of OpenStack, because in my mind they are one and the same. I don't consider the people using, say, public cloud services to be OpenStack end users, because ultimately they just want stuff that works, and if it doesn't, they'll blame the provider, not OpenStack. I see our end users as the people who deploy and run OpenStack clouds. Whoa! Back the terminology train up. There's been longstanding confusion whenever anyone mentions the word users because it is ambiguous whether it refers to the people who deploy OpenStack clouds or the people who deploy workloads on them. This has largely been resolved by a conscious effort to refer to the two groups as operators and end users respectively. The *last* thing we need is to muddy the waters again since, contrary to your (I hope inadvertent) implication, both groups are important and they often have different (and occasionally conflicting) interests. The qualifier end is there for a reason; don't ignore it. cheers, Zane. __ 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
Re: [openstack-dev] [all] Question for the TC candidates
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/24/2015 08:30 AM, Zane Bitter wrote: I'm not sure what you see as the difference between the end users and the operators of OpenStack, because in my mind they are one and the same. I don't consider the people using, say, public cloud services to be OpenStack end users, because ultimately they just want stuff that works, and if it doesn't, they'll blame the provider, not OpenStack. I see our end users as the people who deploy and run OpenStack clouds. Whoa! Back the terminology train up. There's been longstanding confusion whenever anyone mentions the word users because it is ambiguous whether it refers to the people who deploy OpenStack clouds or the people who deploy workloads on them. This has largely been resolved by a conscious effort to refer to the two groups as operators and end users respectively. The *last* thing we need is to muddy the waters again since, contrary to your (I hope inadvertent) implication, both groups are important and they often have different (and occasionally conflicting) interests. The qualifier end is there for a reason; don't ignore it. Well, of course they are important, and shouldn't be ignored, but the question explicitly stated: I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. I read the downstream to mean what you refer to as people who deploy workloads on them. In this context, I saw the operators as the end-users of the work the devs do. If that gave the impression that I don't care about people who actually run their stuff on the clouds we build, I apologize - I was simply trying to answer what was asked. - -- - -- Ed Leafe -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCgAGBQJVOkqtAAoJEKMgtcocwZqLkhEQAJub3Ae6+4/8Cf08kiB8vTd4 f3U8s7SOnfP371Jv72F1QbA1Ar4qSL7eTQF2/aybMpnNx9zIIE/DD6x52l1qmREm fCis2CrxlhzFlS5cx7IQipmJlo+DtiPT9dUS+FfeMoy1zuLojFFGIUt11bgW6uiK 9JpP1VDCS16PxdclfpPr1a36LIppU2Izr4d/Yxrl/N3Xnk8zPMNTBISHptoMSNNZ lme/Txm5D9wY3UVTivvxx39mGtP74whMTeqrvJflrJGs9hXBGHu197JzuNhvL/8N tVGFl2rikaDmQJOFC0N37lj59512Ch6pvfMoIJQB+ppWs+6nqgp4NB8gF/Z+IcDi +qwpe2LWT4qluQ7h4k/2V/t2elhmxrZMEMJIOm+azAh+KmotyLbckC1D2tkuELLP 07JyKwmLxAPyquT6OsruU1i57xdTCIM9TN1G78IcfSGlaN90oHOhPQxfvL6Xz/+N SERxxlJjt/ofb9tU2UFBNPHEIKbgwHmBiYFr3NkG8FXb55abCUVX51d/4vg+iChO k8KKUmyY7Ny4vPmQXMBUnojOUnMxhpfV4kuBtRLOcn3hGq66xKJ+oeb6S9SC0bZV ylDXagHzPKjZSfzwRBg/DohNVPVImWNG7qFpfyt/o3Biy0ZW1YaDdSBBZiBaKXZ+ YTRS4fizC4ASrKg1imoL =xR9N -END PGP SIGNATURE- __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 24/04/15 09:52, Ed Leafe wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 04/24/2015 08:30 AM, Zane Bitter wrote: I'm not sure what you see as the difference between the end users and the operators of OpenStack, because in my mind they are one and the same. I don't consider the people using, say, public cloud services to be OpenStack end users, because ultimately they just want stuff that works, and if it doesn't, they'll blame the provider, not OpenStack. I see our end users as the people who deploy and run OpenStack clouds. Whoa! Back the terminology train up. There's been longstanding confusion whenever anyone mentions the word users because it is ambiguous whether it refers to the people who deploy OpenStack clouds or the people who deploy workloads on them. This has largely been resolved by a conscious effort to refer to the two groups as operators and end users respectively. The *last* thing we need is to muddy the waters again since, contrary to your (I hope inadvertent) implication, both groups are important and they often have different (and occasionally conflicting) interests. The qualifier end is there for a reason; don't ignore it. Well, of course they are important, and shouldn't be ignored, but the question explicitly stated: I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. I read the downstream to mean what you refer to as people who deploy workloads on them. Downstream means people who package/distribute OpenStack. To those of us (like Chris) who also do this as well as being developers it's literally an everyday term, but this was a good reminder to me that not everyone shares the same context :) In this context, I saw the operators as the end-users of the work the devs do. If that gave the impression that I don't care about people who actually run their stuff on the clouds we build, I apologize - I was simply trying to answer what was asked. Thanks for clarifying, I understand your meaning much better now. cheers, Zane. __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 04/24/2015 06:28 PM, David Medberry wrote: On Fri, Apr 24, 2015 at 2:14 AM, Chris Dent chd...@redhat.com wrote: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Hello Chris et al, OpenStack quality will improve for the operators with a strong operator voice that helps focus developers and the overall technical focus on usage. OpenStack quality improves for developers in other ways: by hearing from end users and operators they can in part anticipate (or respond more quickly) to issues that will otherwise become truly raging hotspots (crises if you will.) The other way to directly improve quality for OpenStack Devs is to improve test coverage and gate checks on more production-like systems. As an operator and advocate, I can persuade or motivate other operators to offer up resources (people as well as systems) to aid in this area of improvement. These are indeed new times with operators playing a very critical role in OpenStack. As a follow up to this thought - we _may_ be in a place over the next cycle where Infra would be in a position to accept systems from operators or others. Up until now we've only been in a position really to deal with public clouds - but we're taking a stab at something new and if it works out, it should open the door to taking advantage of offers like this - which I agree will be a good thing for the project. __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Fri, Apr 24, 2015 at 2:14 AM, Chris Dent chd...@redhat.com wrote: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Hello Chris et al, OpenStack quality will improve for the operators with a strong operator voice that helps focus developers and the overall technical focus on usage. OpenStack quality improves for developers in other ways: by hearing from end users and operators they can in part anticipate (or respond more quickly) to issues that will otherwise become truly raging hotspots (crises if you will.) The other way to directly improve quality for OpenStack Devs is to improve test coverage and gate checks on more production-like systems. As an operator and advocate, I can persuade or motivate other operators to offer up resources (people as well as systems) to aid in this area of improvement. These are indeed new times with operators playing a very critical role in OpenStack. __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Fri, 24 Apr 2015, Ed Leafe wrote: I read the downstream to mean what you refer to as people who deploy workloads on them. In this context, I saw the operators as the end-users of the work the devs do. If that gave the impression that I don't care about people who actually run their stuff on the clouds we build, I apologize - I was simply trying to answer what was asked. I left the terminology intentional vague to allow people to interpret them as they felt appropriate. To be clear I was thinking in these sorts of ways: * Downstream: The companies that are packaging and selling OpenStack in some fashion. I left these people out because I personally think the OpenStack project does _far_ too much to keep these people happy and should actually do less and since that is a somewhat contentious position I wanted to leave it out of the discussion (at least initially) as it would just muddy the waters. * End-users: Someone who might run 'nova boot' or 'heat stack-create' or the openstack client or horizon to get something going. I have access to clouds where I do this, but I do not operate them (I do, however, operate my own little mini clouds at home). * Operators: People responsible for making sure one or more cloud installations exist and/or are running smoothly. * Developers: The people writing and testing the code. Some individuals will have one of these roles, some will have more. Some individuals will have entirely different definitions. That's cool. Thanks to everyone for participating. It's been very useful I think. -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 04/24/2015 10:42 AM, Chris Dent wrote: On Fri, 24 Apr 2015, Ed Leafe wrote: I read the downstream to mean what you refer to as people who deploy workloads on them. In this context, I saw the operators as the end-users of the work the devs do. If that gave the impression that I don't care about people who actually run their stuff on the clouds we build, I apologize - I was simply trying to answer what was asked. I left the terminology intentional vague to allow people to interpret them as they felt appropriate. To be clear I was thinking in these sorts of ways: * Downstream: The companies that are packaging and selling OpenStack in some fashion. I left these people out because I personally think the OpenStack project does _far_ too much to keep these people happy and should actually do less and since that is a somewhat contentious position I wanted to leave it out of the discussion (at least initially) as it would just muddy the waters. Interesting. Can you list a few specific things we do as a project that are only for the benefit of such companies and that you believe we should stop doing? -David __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Thu, Apr 23, 2015 at 10:14 AM, Chris Dent chd...@redhat.com wrote: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Thank you for your question. I think the largest hurdle for quality is a lack of a unified vision and direction for OpenStack. Without coordinated objectives for releases we have now 19+ projects driving in scattered directions. This effects quality on all levels. If we have a documented set of common release goals, we can better coordinate progress and deliver on the largest pain points for end-users and deployers. This was my hope for the Cross-Project Sessions at the summits, but it has not been realized. The TC should drive this coordination. A growing ecosystem provides choice for deployers, but it also creates more questions and uncertainty. We need to provide some guidance to deployers as to what components are considered ready for production use and which pieces work complimentary together. The integrated release previously served that goal. We don't have a concrete plan moving forward to provide this guidance. To improve quality for deployers we need to make choosing which services to install simpler and the process to deploy and configure those services simpler. Additionally for horizontal projects rapid ecosystem growth creates a very difficult situation where either those horizontal projects attempt to provide that function for all, or leave it wide open which creates inconsistencies. This effects quality for end-users and deployers. The TC needs to stop hand-waiving here and concretely address the implications of this growth. Improving the experience for developers means driving our ability to effectively scale the development process. Progress around excising tests from the coordinated gate begins to improve how well the gate works for individual projects. The other central component of this is scaling the review process. Too much frustration faces developers submitting specs and patches. The TC needs to push targeting less bureaucracy for developers and more toward allowing developers to contribute. David __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Apr 23, 2015, at 9:14 AM, Chris Dent chd...@redhat.com wrote: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? I have strong opinions about how we can improve quality. I stated some of them in my candidate email. I think we have a more pressing concern, though. How do we ensure that our TC is capable of effecting the change we require? Our TC's primary mission used to be defining what OpenStack was and was not. The move to a 'big tent' model reduced the need to focus on that issue, and now our TC needs to direct its attention to improving our community and the software it delivers. This new mission changes the game, because top-down direction is not going to work. Without direct authority to make change happen, how can the TC hope to deliver? Indirect authority. 13 people of influence, with on-the-ground support developed and maintained at the project level, pulling in the same direction. That's the real power of the TC. And that's the power we're going to use to effect real change. This power is created by each TC member doing the hard work of engaging. It's writing, testing, debugging and documenting our software. It's conversations with developers, users, distros, and operators. It's developing an emotional connection - empathizing - with their constituents as they face the frustration caused by our community and software. It's making a difference so that their opinion is respected. This is the way things work in the individual projects, and our TC should differ only in the scale of the problems it tackles. This reinforces the idea, as has been suggested by other candidates, that the role of TC member needs to be taken more seriously. Change will not be decided because our TC knows best, but because its members collectively have first-hand experience with the problems at hand, have considered a diversity of potential solutions, and do the hard work of justifying their conclusions. Change will happen not because our TC commands it, but because project-level contributors have trust in our TC members and value their input. Only by being more engaged with the wider community can our TC hope to be an effective force for change. Respectfully, Maru __ 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
Re: [openstack-dev] [all] Question for the TC candidates
Hey there Chris! On Thu, Apr 23, 2015 at 9:17 AM Chris Dent chd...@redhat.com wrote: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? OpenStack needs to become as boring as possible. Clouds, to me, are plumbing. They're not themselves interesting, rather they are the platforms upon which interesting things are built. And they shouldn't be, either! Use hardware as an analogy: The RJ-45 connector is ubiquitous for physical network connections. If each manufacturer used something different, you'd soon be spending all your time soldering adapters, and the last thing I want our operators, developers, or customers to do is waste their time doing the cloud-equivalent. Example: Pep8 is boring. Benefit: We don't waste time arguing about tabs vs. spaces anymore. The TC can set policies that encourage being boring. It's the closest we have to an ISO standards board, and while the TC has no real power to mobilize resources to build things, it can advise and encourage adoption of policies and standards. Some examples include: Test Coverage standards, common middleware, consistent API standards... you get the idea. The more boring OpenStack becomes, the easier it will be to work on, operate, and talk about. As for myself: I'm going to focus on making UI projects as boring as possible. This includes lots of things, so let me get into specifics: - Creating, and encouraging the use of, common middleware that encapsulates existing RFC's and standards which support UI development (CORS, Common Auth, etc.) - Researching, Drafting, Proposing, and Shepherding policies for UI development that involve all stakeholders, including upstream and downstream engineers, Package Maintainers, and operators. - Creating the tools that will allow us to publish UI libraries to the global community (mostly JS, we've got the Python part handled). - Getting involved in UI tooling projects (Node, Sass, etc) and advocating a more enterprise-supportive approach to topics like security, package signing, package structures, audit trails, and distribution. That about sums it up. Have a nice day! Michael __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 04/23/2015 12:14 PM, Chris Dent wrote: This might be a bit presumptuous, but why not give it a try... Thank you for asking the question, Chris, my response is below. Anita. This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think it would be useful to get answers from the candidates on at least one topical but open-ended question. Maybe other people have additional questions they think are important but this one is the one that matters to me and also captures the role that I wish the TC filled more strongly. Here's the preamble: There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. There are many different ways to define quality. For the sake of this question feel free to use whatever definition you like but take it as given that quality needs to be improved. Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? Answer: I'll move to my astrological perspective and what I interpret from OpenStack's birth chart here. OpenStack has a dynamic energy pattern of three powerful positions, two of which want to dominate the other and the third which is in the position to bring balance to the first two. Uranus (the rebel representing freedom) sits in the position of values with a pioneering spirit. Saturn representing structure, authority (the tc) and limitations of physical resources (human limitations and the real experience of burnout) sits directly opposite, pulling in the other direction of needing to find common ground, real solutions and to do so in a careful precise way. These two energies see-saw against each other, each trying to be the dominate force. Pluto is the balancer here (the strongly influential recently demoted former planet). It sits in the exact mid-point between the need for all of us to rebel and the need for all of us to have structure and be involved in building that structure. It sits in the position of groups, society and culture. By recognizing that the TC is one strong force among 3 forces, and ensuring that the TC play its role, our shared need to rebel and be free will be balanced by the community norms that come out of that interaction. The TC has a role to play in that dynamic but it isn't the entire role, nor actually is it the strongest role, but it is a strong role. This is my way of saying that the TC and members that serve it need to recognize the dynamic nature of the relationship it shares with all its parts. The phrase quality improvement implies for me, a linear direction, while I feel that the energy dynamic we share is more a triangular one. If one of the consequences of improvement of quality is less frustration on any one part of the dynamic it comes from a clearer appreciation of the other points of view in the dynamic. As a member of the community (and if the community decides its needs are best served by me having a voice on the TC) I do my best to look at the situation from my perspective first (I have to be true to myself here) and then look up and see what other perspectives are present. I do do my best to make myself available to hear and interact with other perspectives (chairing two third party meetings per week, attending infra, tc, neutron, nova as well as other project meetings as need be) while understanding my physical limitations at the same time and working to find my own balance. I realize my invocation of astrology vocabulary might dissuade those who are uncomfortable with it as a tool. I accept that. I see OpenStack as a constant dynamic dance we have selected to be a part of and we each have our role to play. Thank you for helping me to find mine, Anita. __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On Fri, Apr 24, 2015 at 2:14 AM, Chris Dent chd...@redhat.com wrote: This might be a bit presumptuous, but why not give it a try... This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think it would be useful to get answers from the candidates on at least one topical but open-ended question. Maybe other people have additional questions they think are important but this one is the one that matters to me and also captures the role that I wish the TC filled more strongly. Here's the preamble: There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. There are many different ways to define quality. For the sake of this question feel free to use whatever definition you like but take it as given that quality needs to be improved. Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? I think this can be broader still - How can the TC herd cats :-O Jokes aside, OpenStack is an opensource project and it's not easy for TC members or PTL's to make developers do their bidding. I'd like to think we at least need a better feedback loop from the user survey (or consumers of OpenStack in general) to what development actually happens. At the moment we have user feedback, but that doesn't always result in developers doing exactly that. I think we need a number of tools for PTLs and the TC be able to set priorities for particular themes OpenStack wide. 1. I think the TC and PTLs need a place to say what the priorities are (that is visible to everyone). 2. Then follow up with assigning blueprints and bug priorities accordingly 3. Be open to saying no to work that is not within these themes if it is creating a distraction. 4. recognition of work in these themes, perhaps on stackalytics (or else where). With some version of the above, we can hopefully get better at turning user requests into solutions. (or better quality). Regards Angus -- Chris Dent tw:@anticdent freenode:cdent https://tank.peermore.com/tanks/cdent __ 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 __ 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
Re: [openstack-dev] [all] Question for the TC candidates
On 23/04/15 12:14, Chris Dent wrote: This might be a bit presumptuous, but why not give it a try... Not at all, we should *strongly* encourage people to ask questions of the candidates. In fact, I think we should encourage everyone to contribute to the discussion, not just the candidates. This cycle's TC elections didn't come with a set of prepackaged questions and though the self-nomination messages have included some very interesting stuff I think it would be useful to get answers from the candidates on at least one topical but open-ended question. Maybe other people have additional questions they think are important but this one is the one that matters to me and also captures the role that I wish the TC filled more strongly. Here's the preamble: There are lots of different ways to categorize the various stakeholders in the OpenStack community, no list is complete. For the sake of this question the people I'm concerned with are the developers, end-users and operators of OpenStack: the individuals who are actively involved with it on a daily basis. I'm intentionally leaving out things like the downstream. There are many different ways to define quality. For the sake of this question feel free to use whatever definition you like but take it as given that quality needs to be improved. Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? As you've identified, that is an extremely broad question and therefore it can only be correctly answered with an extremely vague response ;) The only known way to improve 'quality' for all definitions of 'quality' is to make feedback loops shorter. As for what the Technical Committee can do specifically, in the short term I think the most important thing is to make sure that projects have the flexibility to respond to their own individual challenges. I think we've made some progress in this direction - for example, the reorganisation that Neutron has been/is going through would probably have been easier had it begun in a big-tent world (it's much easier to split repos up than to punt parts of your project to stackforge), and that's the kind of change that could potentially allow projects to bring in more (but more specialised) core reviewers to reduce average time-to-review, thus shortening an important feedback loop. So I think the TC needs to be vigilant to make sure it's not making those kinds of changes difficult. And of course we should try to identify ideas that work and introduce them to other projects who might benefit from them. But I don't think that needs to be the TC's responsibility alone - anyone in the community should feel able to do that. When I was a PTL I regarded my most important responsibility to be making sure that everyone on the team saw themselves as leaders of the project. I think the same applies to the TC. [Warning: hand-waving ahead] In the much longer term, I think the biggest improvement in quality would come from finding a way to not solve the same problems multiple times. I'll give an example: RabbitMQ doesn't scale. I hope that's not a controversial example, I think it's generally agreed that it just doesn't. Nova has developed Cells to enable itself to scale to very large deployments despite that limitation (and others). As a result of Cells being developed, every other project that uses RabbitMQ is... exactly where it was before. That seems suboptimal. Right now we have a lot of back-end interfaces where the semantics are unclear to OpenStack developers, since they're deployer-defined in many cases and no one project really owns them. (Example: even if oslo-messaging didn't explicitly rule out durability by acknowledging messages *before* they're delivered to the application, there's still no way we could rely on it because who knows in what configuration RabbitMQ is deployed?) Even worse, the interfaces don't support the invariants we care about - like being able to scale to both extremely large and extremely small deployments - so that every project must find a way to reinvent those itself (or not), on top of the aforementioned unclear semantics. I can't say how much impact this has on quality. I would guess that it is both substantial and negative. More co-operation between the various different deployment projects might help a little, and in any event would be a Good Thing, and we could start encouraging that right away. Solving the problem entirely will be much harder, to put it mildly. I don't know if we'll ever get there (though I don't think it's impossible). I do believe that the first step is to have a conversation about what our vision is for the OpenStack project as a whole, and I think it will be much harder to have that conversation and follow through on it
Re: [openstack-dev] [all] Question for the TC candidates
On 24 April 2015 at 04:14, Chris Dent chd...@redhat.com wrote: This might be a bit presumptuous, but why not give it a try... Nothing presumptuous about it at all :) There are many different ways to define quality. For the sake of this question feel free to use whatever definition you like but take it as given that quality needs to be improved. Here's the question: What can and should the TC at large, and you specifically, do to ensure quality improves for the developers, end-users and operators of OpenStack as a full system, both as a project being developed and a product being used? We've got a strong culture around many key elements of a high quality product: backwards compatibility around APIs, testing, asking our users and operators what their needs and pain points are. The balkanisation of OpenStack is a big concern for me though, particularly as it relates to usability. I'd like to see more cross-project collaboration around OpenStack as a product (vs N 'small' products) - and the TC can encourage that (even with the big tent model). Since we're an open source project, this has to be done in an inclusive opt-in fashion, not dictatorial, so my first approach here would be discussion and setting up a wg on it. The existing API working group for instance is one method aiming to provide consistency, but we've also got to look at differences like the tasks vs not-tasks approach different servers take, and where things like e.g. Zaqar are/aren't usable. Right now development is pretty hard on lots of OpenStack, and this holds us back - I referred to this in my TC candidacy email, and I believe sorting this out is a pre-requisite for improving the developer experience - but also for enabling improvements in quality for users. Some key things have improved in the last 6 months like review latency - but we can do more there. We need to make the gate be more reliable, isolating it from unintentional external failures, and reducing flakiness in OpenStack itself. I'm working on that now, working on improvements to pip to enable much better robustness in our gate. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud __ 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
