Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Aug 20, 2014 10:56 AM, John Garbutt j...@johngarbutt.com wrote: On 18 August 2014 11:18, Thierry Carrez thie...@openstack.org wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) Same here, sorry for posting so high up in the tread. There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I think its important we try to get everyone together as often as possible, it seems like 2 per year is the best compromise. I prefer expected rather than mandatory, but thats a detail. Some times there are more important family things, and thats totally fine. But lack of budget seems like a fairly poor excuse for something thats expected. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. What I remember about why we needed the mid-cycles: In Hong Kong: * we were missing some key people * so the midcycle in the US was very useful to catch up those people * but it was great to meet some new contributors In Atlanta, although we have fairly good core attendance, but: * done badly on tracking and following on what was discussed * we had quite a few information and mentoring sessions, that were not a great use of group time * had some big debates that needed more time, but we didn't have any slack * quite burnt out towards the end (after two previous days of ops and cross project sessions) My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. It feels a bit exclusive. I think saying we prefer ATLs attending seems OK. Maybe for Paris would could try out some of these things: 1) Get rid of sessions that can be replaced by the spec process: * this was a popular idea at the mid-cycle * Feature session, we should try write the spec first, to see if we really need a session * Also use the spec process to help mentor people * maybe have more targeted face to face mentor meetings, where a summit session is wasteful Yes! 2) Schedule an afternoon of freestyle big picture debates later in the week * quite often come up with but we must fix X first discussions, can follow through on those here * maybe after lunch on the last day? * doesn't mean we don't have other big picture sessions explicitly scheduled Interesting idea, I like it. 3) Schedule a slot to discuss, and propose some release priorities * it would be good to generate a release priority statement in the last session * sum up the key big issues that have come up and need resolving, etc ++, although I think we need to have a draft of this list when planning the summit to help pick what to talk about. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. +1
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 18 August 2014 11:18, Thierry Carrez thie...@openstack.org wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) Same here, sorry for posting so high up in the tread. There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I think its important we try to get everyone together as often as possible, it seems like 2 per year is the best compromise. I prefer expected rather than mandatory, but thats a detail. Some times there are more important family things, and thats totally fine. But lack of budget seems like a fairly poor excuse for something thats expected. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. What I remember about why we needed the mid-cycles: In Hong Kong: * we were missing some key people * so the midcycle in the US was very useful to catch up those people * but it was great to meet some new contributors In Atlanta, although we have fairly good core attendance, but: * done badly on tracking and following on what was discussed * we had quite a few information and mentoring sessions, that were not a great use of group time * had some big debates that needed more time, but we didn't have any slack * quite burnt out towards the end (after two previous days of ops and cross project sessions) My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. It feels a bit exclusive. I think saying we prefer ATLs attending seems OK. Maybe for Paris would could try out some of these things: 1) Get rid of sessions that can be replaced by the spec process: * this was a popular idea at the mid-cycle * Feature session, we should try write the spec first, to see if we really need a session * Also use the spec process to help mentor people * maybe have more targeted face to face mentor meetings, where a summit session is wasteful 2) Schedule an afternoon of freestyle big picture debates later in the week * quite often come up with but we must fix X first discussions, can follow through on those here * maybe after lunch on the last day? * doesn't mean we don't have other big picture sessions explicitly scheduled 3) Schedule a slot to discuss, and propose some release priorities * it would be good to generate a release priority statement in the last session * sum up the key big issues that have come up and need resolving, etc If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. +1 Cheers, John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
From: Joe Gordon joe.gord...@gmail.commailto:joe.gord...@gmail.com Reply-To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Date: Monday, August 18, 2014 at 9:31 PM To: OpenStack List openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org Subject: Re: [openstack-dev] [nova][core] Expectations of core reviewers On Mon, Aug 18, 2014 at 8:18 AM, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: On 08/18/2014 06:18 AM, Thierry Carrez wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.commailto:rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. Great response ... I agree with everything you've said here. Let's figure out how to improve the design summit to better achieve team alignment. Of the things you mentioned, I think the biggest limit to alignment has been the 40 minute format. There are some topics that need more time. It may be that we just need to take more advantage of the ability to give a single topic multiple time slots to ensure enough time is available. As Dan discussed, there are some topics that we could stand to turn down and distribute information another way that is just as effective. I would also say that the number of things going on at one time is also problematic. Not only are there several design summit sessions going once, but there are conference sessions and customer meetings. The rapid rate of jumping around and context switching is exhausting. It also makes it a bit harder to get critical mass for an extended period of time around a topic. In mid-cycle
Re: [openstack-dev] [nova][core] Expectations of core reviewers
I think to make the Summit sessions more effective: 1. The presenter to put in more effort beforehand - implement a rough POC, write up a detailed etherpad, etc. where everything is ready say 2-3 weeks before the Summit. Maybe even require a reviewed spec for sessions which introduce new features? 2. The active members of the project (core and otherwise) to put in more effort beforehand - review the POC and/or etherpad, digest the information, maybe even start a preliminary discussion on IRC to sharpen the proposal 3. Rather than the presenter giving a lecture and the project members trying to digest what is being said, with no time to think of implications, design options, etc., there should just be that debate to refine the idea (I think this is what usually happens at the mid-cycle meetup). 4. Community members who did not do their homework should be discouraged from actively participating in that session (i.e., asking basic questions or taking the discussion on tangents). Anyone who has questions or off-topic comments can take it up with the presenter or anyone else during the breaks. Of course this requires a lot discipline on everyone's part, but I think it would not only make the Summit sessions more valuable, but also help developers who present to get their code in quicker and thereby help the project to meet its objectives for that release. Thanks, Avishay On Mon, Aug 18, 2014 at 6:40 PM, John Griffith john.griff...@solidfire.com wrote: On Mon, Aug 18, 2014 at 9:18 AM, Russell Bryant rbry...@redhat.com wrote: On 08/18/2014 06:18 AM, Thierry Carrez wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. Cheers, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Mon, Aug 18, 2014 at 12:18:16PM +0200, Thierry Carrez wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. This pretty much all aligns with my thoughts on the matter. The key point is that the design summit is the right place from a cycle timing POV to have the critical f2f discussions debates, and we need to figure out what we can do to make it a more effective venue than it currently is. IME I'd probably say the design summit sessions I've been to fall into two broad camps. - Information dissemination - just talk through proposal(s) to let everyone know what's being planned / thought. Some questions and debate, but mostly a one-way presentation. - Technical debates - the topic is just a high level hook, around which, a lively argument debate was planned took place. I think that the number of the information dissemination sessions could be cut back on by encouraging people to take advantage of other equally as effective methods of communication. In many cases it would suffice to just have a more extensive blueprint / spec created, or a detailed wiki page or similar doc to outline the problem space. If we had some regular slot where people could do online presentations (Technical talks) that could be a good way to push the information, out of band from the main summits. If those online talks led to significant questions, then those questions could then justify design summit sessions for f2f debate. As an example, much as it is nice that we give every hypervisor driver in Nova a slot at the design
Re: [openstack-dev] [nova][core] Expectations of core reviewers
As the conversation has drifted away from a discussion pertaining the nova core team, I have some comments inline as well. On 18 August 2014 12:18, Thierry Carrez thie...@openstack.org wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I honestly think that it is simply not possible to require a minimum travel from core team members. This might sound naive, but I reckon the various core teams could just use a bit of common sense here. A core member that goes to every summit and meetup just for doing pub crawling in yet another city is definetely less productive than another team members which tries to collaborate remotely via etherpad/IRC/gerrit/etc. (ok this example was a bit extreme but I hope it clarifies my thoughts). I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. I totally agree on this point. I would be suprised if I were the first one that in conversation (off and on the record) has mentioned that it is very hard to achieve any form of consensus on anything at the design summit. And it is pretty much impossible to move from a declarations of intent to the definition of an architecture and/or actionable work items for the subsequent release cycle. Disclaimer: I spend 90% of my design summit time in the networking room, so my judgment might be skewed. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? I suggested in the past to decouple the summit from the main conference. This alone, in my opinion, would allow us to do the design summit at a point where it's best for the upcoming release cycle, and reduce the inevitable increased noise from rooms filled with over 150 people. Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. I think all of them apply and possibly other reasons, but probably we are a going a bit off-topic. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. While I agree that restricted attendance would increase productivity, it might also be perceived as a barrier for new contributors and a reduction of the overall democracy of the project. Maybe this could be achieved naturally by decoupling conference and summit. If we manage to have alignment at the design summit, then it doesn't spell the end
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Le 18 août 2014 14:36, Salvatore Orlando sorla...@nicira.com a écrit : As the conversation has drifted away from a discussion pertaining the nova core team, I have some comments inline as well. On 18 August 2014 12:18, Thierry Carrez thie...@openstack.org wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I honestly think that it is simply not possible to require a minimum travel from core team members. This might sound naive, but I reckon the various core teams could just use a bit of common sense here. A core member that goes to every summit and meetup just for doing pub crawling in yet another city is definetely less productive than another team members which tries to collaborate remotely via etherpad/IRC/gerrit/etc. (ok this example was a bit extreme but I hope it clarifies my thoughts). I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. I totally agree on this point. I would be suprised if I were the first one that in conversation (off and on the record) has mentioned that it is very hard to achieve any form of consensus on anything at the design summit. And it is pretty much impossible to move from a declarations of intent to the definition of an architecture and/or actionable work items for the subsequent release cycle. Disclaimer: I spend 90% of my design summit time in the networking room, so my judgment might be skewed. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? I suggested in the past to decouple the summit from the main conference. This alone, in my opinion, would allow us to do the design summit at a point where it's best for the upcoming release cycle, and reduce the inevitable increased noise from rooms filled with over 150 people. Strong -1 here. Having design sessions happening in the same time than conference is cool for having : - mixup of operators, developers and users in the same area, enjoying the atmosphere, creating a same view and team spirit within Openstack - newcomers able to join their first developers sessions (we lower the bar) - same budget for contributors able to propose good proposals for regular conference I had the chance to attend both Icehouse and Juno summits. IIRC, Icehouse design summit was restricted to ATCs while Juno one was open to everyone. That thing plus the fact that the audio quality of the Juno sessions was poor (cf. last design session about feedback) makes me think that the problem is rather a problem of having good sessions than more an overall problem. I'm pro restricting access to only ATCs and impose access to rooms only before the session starts, that would improve dramatically the quality without sending a bad signal to the community that now design discussions are a matter of only engineers. -Sylvain Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. I think all of them apply and possibly other reasons, but probably we are a going a bit off-topic. My gut feeling is that having a restricted audience and a
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/18/2014 06:18 AM, Thierry Carrez wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. Great response ... I agree with everything you've said here. Let's figure out how to improve the design summit to better achieve team alignment. Of the things you mentioned, I think the biggest limit to alignment has been the 40 minute format. There are some topics that need more time. It may be that we just need to take more advantage of the ability to give a single topic multiple time slots to ensure enough time is available. As Dan discussed, there are some topics that we could stand to turn down and distribute information another way that is just as effective. I would also say that the number of things going on at one time is also problematic. Not only are there several design summit sessions going once, but there are conference sessions and customer meetings. The rapid rate of jumping around and context switching is exhausting. It also makes it a bit harder to get critical mass for an extended period of time around a topic. In mid-cycle meetups, there is one track and no other things competing for time and attention. I don't have a good suggestion for fixing this issue with so many things competing for time and attention. I used to be a big proponent of splitting the event out completely, but I don't feel the same way anymore. In theory we could call the conference the optional event, but in practice it's going to be required for many folks anyway. I can't speak for everyone, but I suspect if you're a senior engineer at your
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Mon, Aug 18, 2014 at 9:18 AM, Russell Bryant rbry...@redhat.com wrote: On 08/18/2014 06:18 AM, Thierry Carrez wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. Great response ... I agree with everything you've said here. Let's figure out how to improve the design summit to better achieve team alignment. Of the things you mentioned, I think the biggest limit to alignment has been the 40 minute format. There are some topics that need more time. It may be that we just need to take more advantage of the ability to give a single topic multiple time slots to ensure enough time is available. As Dan discussed, there are some topics that we could stand to turn down and distribute information another way that is just as effective. I would also say that the number of things going on at one time is also problematic. Not only are there several design summit sessions going once, but there are conference sessions and customer meetings. The rapid rate of jumping around and context switching is exhausting. It also makes it a bit harder to get critical mass for an extended period of time around a topic. In mid-cycle meetups, there is one track and no other things competing for time and attention. I don't have a good suggestion for fixing this issue with so many things competing for time and attention. I used to be a big proponent of splitting the event out completely, but I don't feel the same way anymore. In theory we could call the conference the
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Mon, Aug 18, 2014 at 11:18:52AM -0400, Russell Bryant wrote: On 08/18/2014 06:18 AM, Thierry Carrez wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. Great response ... I agree with everything you've said here. Let's figure out how to improve the design summit to better achieve team alignment. Of the things you mentioned, I think the biggest limit to alignment has been the 40 minute format. There are some topics that need more time. It may be that we just need to take more advantage of the ability to give a single topic multiple time slots to ensure enough time is available. As Dan discussed, there are some topics that we could stand to turn down and distribute information another way that is just as effective. I would also say that the number of things going on at one time is also problematic. Not only are there several design summit sessions going once, but there are conference sessions and customer meetings. The rapid rate of jumping around and context switching is exhausting. It also makes it a bit harder to get critical mass for an extended period of time around a topic. In mid-cycle meetups, there is one track and no other things competing for time and attention. I don't have a good suggestion for fixing this issue with so many things competing for time and attention. I used to be a big proponent of splitting the event out completely, but I don't feel the same way anymore. In theory we could call the conference the optional
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Aug 14, 2014, at 8:52 AM, Russell Bryant rbry...@redhat.com wrote: On 08/14/2014 11:40 AM, David Kranz wrote: On 08/14/2014 10:54 AM, Matt Riedemann wrote: On 8/14/2014 3:47 AM, Daniel P. Berrange wrote: On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. Just speaking from
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Aug 13, 2014, at 10:32 PM, Michael Still mi...@stillhq.com wrote: On Thu, Aug 14, 2014 at 2:48 PM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com wrote: On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. What about making it easier for remote people to participate at the mid-cycle meetups? Set up some microphones and a Google hangout? At least that way attending the mid-cycle is not all or nothing. We did something like this last cycle (IIRC we didn't have enough mics) and it worked pretty well. As I said, I'm open to experimenting, but I need someone other than me to own that. I'm simply too busy to get to it. However, I don't think we should throw away the thing that works for best for us now, until we have a working replacement. I'm very much in favour of work being done on a replacement though. +1 I agree that that mid-cycles may not be sustainable over the long-term due to issues of travel cost (financial and otherwise) and a lack of inclusiveness, but I don't think they should stop happening until a suitably productive alternative has been found. Maru ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Mon, Aug 18, 2014 at 3:18 AM, Thierry Carrez thie...@openstack.org wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. For my self, the issue with the design summits have been around the duration and the number of sessions that I would like to attend that are scheduled at the same time. I have rarely seen the issue be too many non-contributors in the room, if they don't have anything to add they usually just listen. The 40 minute format is a bit too restrictive, but if all design summit tracks dropped the 40-min format it would be even harder for me to attend sessions across tracks, one of the main benefits of the design summit IMHO. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. Cheers, -- Thierry Carrez (ttx) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Mon, Aug 18, 2014 at 8:18 AM, Russell Bryant rbry...@redhat.com wrote: On 08/18/2014 06:18 AM, Thierry Carrez wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. Great response ... I agree with everything you've said here. Let's figure out how to improve the design summit to better achieve team alignment. Of the things you mentioned, I think the biggest limit to alignment has been the 40 minute format. There are some topics that need more time. It may be that we just need to take more advantage of the ability to give a single topic multiple time slots to ensure enough time is available. As Dan discussed, there are some topics that we could stand to turn down and distribute information another way that is just as effective. I would also say that the number of things going on at one time is also problematic. Not only are there several design summit sessions going once, but there are conference sessions and customer meetings. The rapid rate of jumping around and context switching is exhausting. It also makes it a bit harder to get critical mass for an extended period of time around a topic. In mid-cycle meetups, there is one track and no other things competing for time and attention. I don't have a good suggestion for fixing this issue with so many things competing for time and attention. I used to be a big proponent of splitting the event out completely, but I don't feel the same way anymore. In theory we could call the conference the
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Mon, Aug 18, 2014 at 5:22 AM, Daniel P. Berrange berra...@redhat.com wrote: On Mon, Aug 18, 2014 at 12:18:16PM +0200, Thierry Carrez wrote: Doug Hellmann wrote: On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. +1, well said. Sorry, I was away for a few days. This is a topic I have a few strong opinions on :) There is no denial that the meetup format is working well, comparatively better than the design summit format. There is also no denial that that requiring 4 travels per year for a core dev is unreasonable. Where is the limit ? Wouldn't we be more productive and aligned if we did one per month ? No, the question is how to reach a sufficient level of focus and alignment while keeping the number of mandatory travel at 2 per year. I don't think our issue comes from not having enough F2F time. Our issue is that the design summit no longer reaches its objectives of aligning key contributors on a common plan, and we need to fix it. We established the design summit as the once-per-cycle opportunity to have face-to-face time and get alignment across the main contributors to a project. That used to be completely sufficient, but now it doesn't work as well... which resulted in alignment and team discussions to be discussed at mid-cycle meetups instead. Why ? And what could we change to have those alignment discussions at the design summit again ? Why are design summits less productive that mid-cycle meetups those days ? Is it because there are too many non-contributors in the design summit rooms ? Is it the 40-min format ? Is it the distractions (having talks to give somewhere else, booths to attend, parties and dinners to be at) ? Is it that beginning of cycle is not the best moment ? Once we know WHY the design summit fails its main objective, maybe we can fix it. My gut feeling is that having a restricted audience and a smaller group lets people get to the bottom of an issue and reach consensus. And that you need at least half a day or a full day of open discussion to reach such alignment. And that it's not particularly great to get such alignment in the middle of the cycle, getting it at the start is still the right way to align with the release cycle. Nothing prevents us from changing part of the design summit format (even the Paris one!), and restrict attendance to some of the sessions. And if the main issue is the distraction from the conference colocation, we might have to discuss the future of co-location again. In that 2 events per year objective, we could make the conference the optional cycle thing, and a developer-oriented specific event the mandatory one. If we manage to have alignment at the design summit, then it doesn't spell the end of the mid-cycle things. But then, ideally the extra mid-cycle gatherings should be focused on getting specific stuff done, rather than general team alignment. Think workshop/hackathon rather than private gathering. The goal of the workshop would be published in advance, and people could opt to join that. It would be totally optional. This pretty much all aligns with my thoughts on the matter. The key point is that the design summit is the right place from a cycle timing POV to have the critical f2f discussions debates, and we need to figure out what we can do to make it a more effective venue than it currently is. IME I'd probably say the design summit sessions I've been to fall into two broad camps. - Information dissemination - just talk through proposal(s) to let everyone know what's being planned / thought. Some questions and debate, but mostly a one-way presentation. - Technical debates - the topic is just a high level hook, around which, a lively argument debate was planned took place. I think that the number of the information dissemination sessions could be cut back on by encouraging people to take advantage of other equally as effective methods of communication. In many cases it would suffice to just have a more extensive blueprint / spec created, or a detailed wiki page or similar doc to outline the problem space. If we had some regular slot where people could do online presentations (Technical talks) that could be a good way to push the information, out of band from the main summits. If those online talks led to significant questions, then those questions
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Hi On 14 Aug 2014, at 19:48, Dugger, Donald D donald.d.dug...@intel.com wrote: My experience with mics, no matter how good, In conference rooms is not good. +1 The ubuntu dev summits went through several iterations of trying to make remote participation effective, and I don't think we ever achieved it. I think the reality that needs to be accepted is that not every IRL conversation is going to be accessible to everyone who wants to take part (even if you have superb remote access, maybe some particular discussion is happening at 3am in some developer's timezone). I think we should be ok with that. So long as a quorum of cores can be present at any given event, progress can be made. Cheers, Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Maybe we need to think about this from a distributed software perspective? * Divide and Conquer? Can we split the topics to create more manageable sub-groups? This way it's not core-vs-non-core but intererested-vs-moderately-interested. (of course, this is much the way the mailing list works). Perhaps OnAir would work well for that? How about geographic separation? Meetings per time-zone that roll up into larger meetings (see More Workers below). This is much the same way the regional openstack meetups work, but with specific topics. Of course, then we get replication latency :) * More workers? Can we assign topic owners? Cores might delegate a topic to a non-core member to gather consensus, concerns, suggestions and summarize the result to present during weekly IRC meetings. * Better threading? Are there other tools than mailing lists for talking about these topics? Would mind-mapping software [1] work better for keeping the threads manageable? -Sandy [1] http://en.wikipedia.org/wiki/Mind_map ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 2014-08-14 09:33:20 -0400 (-0400), Russell Bryant wrote: [...] Another issue is that some folks are just fundamentally opposed to using Google [...] I think that's a shallow depiction of the issue. I'm sure *some* people really do just avoid Google specifically, but a bigger concern should be around the statement our use of those services presents to the rest of the World. By using commercial solutions because the open alternatives aren't as useful/featureful/stable, we rob those projects of a potential larger user community which could help them achieve greater momentum and eventually dominate their respective technologies. Would we, as a community, rather see OpenStack used in production and improved when it has bugs/lacks features? Or should users just view it as a cheap lab platform instead, and then pay for solid proprietary solutions to their production needs? I'm glad a lot of people think using and improving OpenStack, even when there might sometimes be easier/simpler closed alternatives, is worth the long-term investment. We, as visible leaders among the greater free software community, should think very hard when making the choice not to extend this same courtesy and consideration to other projects who may lack our extraordinary base of resources. Through our example as a project, we have the potential to improve things for open/free software communities far beyond our own. Of course I'm not a nova core reviewer and have never attended a nova mid-cycle meetup, so I really have no say in how you conduct your remote participation. But I do hope you'll consider, collectively, that focusing on immediate convenience for your own community can have negative longer-term consequences as you (whether consciously or not) promote the use of proprietary solutions to your needs rather than embracing less convenient free and open options which may still require improvement. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Fri, Aug 15, 2014 at 8:20 AM, Jeremy Stanley fu...@yuggoth.org wrote: On 2014-08-14 09:33:20 -0400 (-0400), Russell Bryant wrote: [...] Another issue is that some folks are just fundamentally opposed to using Google [...] I think that's a shallow depiction of the issue. I'm sure *some* people really do just avoid Google specifically, but a bigger concern should be around the statement our use of those services presents to the rest of the World. By using commercial solutions because the open alternatives aren't as useful/featureful/stable, we rob those projects of a potential larger user community which could help them achieve greater momentum and eventually dominate their respective technologies. Would we, as a community, rather see OpenStack used in production and improved when it has bugs/lacks features? Or should users just view it as a cheap lab platform instead, and then pay for solid proprietary solutions to their production needs? I'm glad a lot of people think using and improving OpenStack, even when there might sometimes be easier/simpler closed alternatives, is worth the long-term investment. We, as visible leaders among the greater free software community, should think very hard when making the choice not to extend this same courtesy and consideration to other projects who may lack our extraordinary base of resources. Through our example as a project, we have the potential to improve things for open/free software communities far beyond our own. Of course I'm not a nova core reviewer and have never attended a nova mid-cycle meetup, so I really have no say in how you conduct your remote participation. But I do hope you'll consider, collectively, that focusing on immediate convenience for your own community can have negative longer-term consequences as you (whether consciously or not) promote the use of proprietary solutions to your needs rather than embracing less convenient free and open options which may still require improvement. -- Jeremy Stanley ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Lots of stuff here, good points, bad points etc. I just want to take the opportunity to state that I have ZERO intention of ever pushing that if you're on core you must travel anywhere. I think it's completely alienating and unfair and frankly kinda surprised it was actually raised. For anybody that contributes, works hard and gives great reviews but can't travel to the various Nova events around the world, feel free to check out Cinder. We don't care if you meet us in person and we love good contributors regardless of where they live etc. I could insert snarky comment about unable to work remotely using technology and maybe should choose another project or career here but I won't. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
I've literally just finished the Cinder mid-cycle meetup (I'm still in my hotel room), and the value was huge and undeniable. Reading through this thread, I've just realised one massive advantage of the mid-cycle meetup that improved our productivity massively: it is in the middle of a cycle. We have actual implementations of the things we are discussing, which is something we rarely have at the summit - the sessions there are much more hand-waving and aspirational. In the meetup we effectively treated the post-summit work as a throw away prototype and redesigned things having learn lessons. This is obvious unfortunate for the people who put the effort into the code, but has I think let to a far better end result. I think that requiring, or at least giving preferences to proposals that have a working PoC before the summit might improve out productivity in a similar way. Certainly worth thinking about... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. As I explain in the rest of my email below I'm not advocating getting rid of mid-cycle events entirely. I'm suggesting that we can attain a reasonable % of the benefits of f2f meetings by doing more formal virtual meetups and so be
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 07:27 PM, Michael Still wrote: On Thu, Aug 14, 2014 at 3:44 AM, Russell Bryant rbry...@redhat.com wrote: On 08/13/2014 01:09 PM, Dan Smith wrote: Expecting cores to be at these sorts of things seems pretty reasonable to me, given the usefulness (and gravity) of the discussions we've been having so far. Companies with more cores will have to send more or make some hard decisions, but I don't want to cut back on the meetings until their value becomes unjustified. I disagree. IMO, *expecting* people to travel, potentially across the globe, 4 times a year is an unreasonable expectation, and quite uncharacteristic of open source projects. If we can't figure out a way to have the most important conversations in a way that is inclusive of everyone, we're failing with our processes. I am a bit confused by this stance to be honest. You yourself said when you were Icehouse PTL that you wanted cores to come to the summit. What changed? Yes, I would love for core team members to come to the design summit that's twice a year. I still don't *expect* it for them to remain a member of the team, and I certainly don't expect it 4 times a year. It's a matter of frequency and requirement. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 11:31 PM, Michael Still wrote: On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I'm not sure that's much different in reality. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. Yes, IRC is one option which we already use on a regular basis. We can also switch to voice communication for higher bandwidth when needed. We even have a conferencing server set up in OpenStack's infrastructure: https://wiki.openstack.org/wiki/Infrastructure/Conferencing In theory it even supports basic video conferencing, though I haven't tested it on this server yet. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 07:27 PM, Michael Still wrote: The etherpad for the meetup has extensive notes. Any summary I write will basically be those notes in prose. What are you looking for in a summary that isn't in the etherpad? There also wasn't a summary of the Icehouse midcycle produced that I can find. Whilst I am happy to do one for Juno, its a requirement that I hadn't planned for, and is therefore taking me some time to retrofit. I think we should chalk the request for summaries up experience and talk through how to better provide such things at future meetups. The summary from the Icehouse meetup is here: http://lists.openstack.org/pipermail/openstack-dev/2014-February/027370.html -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 08:31:48AM -0400, Russell Bryant wrote: On 08/13/2014 11:31 PM, Michael Still wrote: On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I'm not sure that's much different in reality. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. Yes, IRC is one option which we already use on a regular basis. We can also switch to voice communication for higher bandwidth when needed. We even have a conferencing server set up in OpenStack's infrastructure: https://wiki.openstack.org/wiki/Infrastructure/Conferencing In theory it even supports basic video conferencing, though I haven't tested it on this server yet. Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. It could be useful in cases where one (or a handful) of people want to present an idea / topic visually with slides / screencasts / etc and then let the broader interactive discussion take place on IRC / mailing list afterwards. I could see this being something that might let people present proposals for new Nova features without having to wait (+try for a limited) design summit slot in the 6 month cycle. One of the issues I feel with the design summit is that it was the first time hearing about many of the ideas, so there was not enough time to disgest the proposal and so some of the thorny things to discuss only come to mind afterwards. If we had to a approach for promoting features knowledge in this way the design summit could have more time to focus on areas of debate where the f2f prescence is most valuable. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/14/2014 10:04 AM, CARVER, PAUL wrote: Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 8/14/2014 3:47 AM, Daniel P. Berrange wrote: On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. Just speaking from experience, I attended the Icehouse meetup before my first summit (Juno in ATL) and the design summit sessions for Juno were a big disappointment after the meetup sessions, basically because of the time constraints. The meetups are nice since there
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 8/14/2014 11:28 AM, Russell Bryant wrote: On 08/14/2014 10:04 AM, CARVER, PAUL wrote: Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? http://bluejeans.com/ was a good experience. What about Google Hangout OnAir for the PTL and core, while others are view-only with chat/irc questions? http://www.google.com/+/learnmore/hangouts/onair.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 10:13 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: On 8/14/2014 11:28 AM, Russell Bryant wrote: On 08/14/2014 10:04 AM, CARVER, PAUL wrote: Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? http://bluejeans.com/ was a good experience. What about Google Hangout OnAir for the PTL and core, while others are view-only with chat/irc questions? http://www.google.com/+/learnmore/hangouts/onair.html We've done Google Hangout OnAir for the docs team with varied success due to the oddities with calendaring and having to know everyone's preferred Google identity. It's nice for high-fidelity conversations without requiring travel. It also lets people tune in then or watch a recording later. Anne ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 10:13 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: On 8/14/2014 11:28 AM, Russell Bryant wrote: On 08/14/2014 10:04 AM, CARVER, PAUL wrote: Daniel P. Berrange [mailto:berra...@redhat.com] wrote: Depending on the usage needs, I think Google hangouts is a quite useful technology. For many-to-many session its limit of 10 participants can be an issue, but for a few-to-many broadcast it could be practical. What I find particularly appealing is the way it can live stream the session over youtube which allows for unlimited number of viewers, as well as being available offline for later catchup. I can't actually offer ATT resources without getting some level of management approval first, but just for the sake of discussion here's some info about the telepresence system we use. -=-=-=-=-=-=-=-=-=- ATS B2B Telepresence conferences can be conducted with an external company's Telepresence room(s), which subscribe to the ATT Telepresence Solution, or a limited number of other Telepresence service provider's networks. Currently, the number of Telepresence rooms that can participate in a B2B conference is limited to a combined total of 20 rooms (19 of which can be ATT rooms, depending on the number of remote endpoints included). -=-=-=-=-=-=-=-=-=- We currently have B2B interconnect with over 100 companies and ATT has telepresence rooms in many of our locations around the US and around the world. If other large OpenStack companies also have telepresence rooms that we could interconnect with I think it might be possible to get management agreement to hold a couple OpenStack meetups per year. Most of our rooms are best suited for 6 people, but I know of at least one 18 person telepresence room near me. An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? http://bluejeans.com/ was a good experience. What about Google Hangout OnAir for the PTL and core, while others are view-only with chat/irc questions? This is a terrible idea, as it perpetuates the core vs. non-core argument. We need equal participation for cores and non-cores alike. http://www.google.com/+/learnmore/hangouts/onair.html ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Russell Bryant [mailto:rbry...@redhat.com] wrote: An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? In principle, yes, but that loses the immersive telepresence aspect which is the next best thing to an in-person meetup (which is where this thread started.) ATT Employees live and breathe on ATT Connect which is our teleconferencing (not telepresence) service. It supports webcam video as well as desktop sharing, but I'm on the verge of making a sales pitch here which was NOT my intent. I'm on ATT Connect meetings 5+ times a day but I'm biased so I won't offer any opinion on how it compares to WebEx, GotoMeeting, and other services. None of them are really equivalent to the purpose built telepresence rooms. My point was that there may well be a telepresence room within reasonable driving distance for a large number of OpenStack contributors if we were able to get a number of the large OpenStack participant companies to open their doors to an occasional meet-up. Instead of asking participants around the globe to converge on a single physical location for a meet-up, perhaps they could converge on the closest of 20 different locations that are linked via telepresence. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 10:31 AM, CARVER, PAUL pc2...@att.com wrote: Russell Bryant [mailto:rbry...@redhat.com] wrote: An ideal solution would allow attendees to join as individuals from anywhere. A lot of contributors work from home. Is that sort of thing compatible with your system? In principle, yes, but that loses the immersive telepresence aspect which is the next best thing to an in-person meetup (which is where this thread started.) ATT Employees live and breathe on ATT Connect which is our teleconferencing (not telepresence) service. It supports webcam video as well as desktop sharing, but I'm on the verge of making a sales pitch here which was NOT my intent. I'm on ATT Connect meetings 5+ times a day but I'm biased so I won't offer any opinion on how it compares to WebEx, GotoMeeting, and other services. None of them are really equivalent to the purpose built telepresence rooms. My point was that there may well be a telepresence room within reasonable driving distance for a large number of OpenStack contributors if we were able to get a number of the large OpenStack participant companies to open their doors to an occasional meet-up. Instead of asking participants around the globe to converge on a single physical location for a meet-up, perhaps they could converge on the closest of 20 different locations that are linked via telepresence. If we could make this work, I'd be up for it. It's a great balance to the travel and face-to-face argument here. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/14/2014 11:40 AM, David Kranz wrote: On 08/14/2014 10:54 AM, Matt Riedemann wrote: On 8/14/2014 3:47 AM, Daniel P. Berrange wrote: On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. Just speaking from experience, I attended the Icehouse meetup before my first summit (Juno in ATL) and the
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 1:47 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. As I explain in the rest of my email below I'm not advocating getting
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Le 14 août 2014 21:56, Joe Gordon joe.gord...@gmail.com a écrit : On Thu, Aug 14, 2014 at 1:47 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Aug 14, 2014 at 09:24:36AM +1000, Michael Still wrote: On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. We thought we had agreement on v3 API after Atlanta f2f summit and after Hong Kong f2f too. So I wouldn't neccessarily say that we needed another f2f meeting to resolve that, but rather than this is a very complex topic that takes a long time to resolve no matter how we discuss it and the discussions had just happened to reach a natural conclusion this time around. But lets see if this agreement actually sticks this time I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. I think the travel cost really is a big issue. Due to the number of people who had to travel to the many mid-cycle meetups, a good number of people I work with no longer have the ability to go to the Paris design summit. This is going to make it harder for them to feel a proper engaged part of our community. I can only see this situation get worse over time if greater emphasis is placed on attending the mid-cycle meetups. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. Maybe we should change the way we structure the design summit to improve that. If there are critical issues blocking nova, it feels like it is better to be able to discuss and resolve as much as possible at the start of the dev cycle rather than in the middle of the dev cycle because I feel that means we are causing ourselves pain during milestone 1/2. As I
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/14/2014 02:48 PM, Dugger, Donald D wrote: My experience with mics, no matter how good, In conference rooms is not good. You are always working hard to hear the soft spoken person who is drowned by the background noise. It’s always a strain and I don’t want to even think about doing it for a full 8 hrs. It’s better than nothing so I agree, we need to provide some sort of remote conferencing at meetups but nothing compares with actually being there. I’m not a core so I’m speaking from the outside but I think requiring attendance at the summits (absence requires a note from your parent Jwhile strongly encouraging attendance at mid-cycle meetups seems reasonable. I think expecting summit attendance, rather than requiring, is a better way to say it, but otherwise I agree that this seems reasonable. PS: In re companies spending millions on OpenStack so travel to f2f events should be a drop in the bucket. It doesn’t always work that way with the finance department, money comes out of different buckets and the travel bucket `always` dries up first. -- Don Dugger Censeo Toto nos in Kansa esse decisse. - D. Gale Ph: 303/443-3786 *From:*Joe Gordon [mailto:joe.gord...@gmail.com] *Sent:* Wednesday, August 13, 2014 10:48 PM *To:* OpenStack Development Mailing List (not for usage questions) *Subject:* Re: [openstack-dev] [nova][core] Expectations of core reviewers On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com mailto:mi...@stillhq.com wrote: On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. What about making it easier for remote people to participate at the mid-cycle meetups? Set up some microphones and a Google hangout? At least that way attending the mid-cycle is not all or nothing. We did something like this last cycle (IIRC we didn't have enough mics) and it worked pretty well. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org mailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote: Hi. One of the action items from the nova midcycle was that I was asked to make nova's expectations of core reviews more clear. This email is an attempt at that. Nova expects a minimum level of sustained code reviews from cores. In the past this has been generally held to be in the order of two code reviews a day, which is a pretty low bar compared to the review workload of many cores. I feel that existing cores understand this requirement well, and I am mostly stating it here for completeness. Additionally, there is increasing levels of concern that cores need to be on the same page about the criteria we hold code to, as well as the overall direction of nova. While the weekly meetings help here, it was agreed that summit attendance is really important to cores. Its the way we decide where we're going for the next cycle, as well as a chance to make sure that people are all pulling in the same direction and trust each other. There is also a strong preference for midcycle meetup attendance, although I understand that can sometimes be hard to arrange. My stance is that I'd like core's to try to attend, but understand that sometimes people will miss one. In response to the increasing importance of midcycles over time, I commit to trying to get the dates for these events announced further in advance. Personally I'm going to find it really hard to justify long distance travel 4 times a year for OpenStack for personal / family reasons, let alone company cost. I couldn't attend Icehouse mid-cycle because I just had too much travel in a short time to be able to do another week long trip away from family. I couldn't attend Juno mid-cycle because it clashed we personal holiday. There are other opensource related conferences that I also have to attend (LinuxCon, FOSDEM, KVM Forum, etc), etc so doubling the expected number of openstack conferences from 2 to 4 is really very undesirable from my POV. I might be able to attend the occassional mid-cycle meetup if the location was convenient, but in general I don't see myself being able to attend them regularly. I tend to view the fact that we're emphasising the need of in-person meetups to be somewhat of an indication of failure of our community operation. The majority of open source projects work very effectively with far less face-to-face time. OpenStack is fortunate that companies are currently willing to spend 6/7-figure sums flying 1000's of developers around the world many times a year, but I don't see that lasting forever so I'm concerned about baking the idea of f2f midcycle meetups into our way of life even more strongly. Given that we consider these physical events so important, I'd like people to let me know if they have travel funding issues. I can then approach the Foundation about funding travel if that is required. Travel funding is certainly an issue, but I'm not sure that Foundation funding would be a solution, because the impact probably isn't directly on the core devs. Speaking with my Red Hat on, if the midcycle meetup is important enough, the core devs will likely get the funding to attend. The fallout of this though is that every attendee at a mid-cycle summit means fewer attendees at the next design summit. So the impact of having more core devs at mid-cycle is that we'll get fewer non-core devs at the design summit. This sucks big time for the non-core devs who want to engage with our community. Also having each team do a f2f mid-cycle meetup at a different location makes it even harder for people who have a genuine desire / need to take part in multiple teams. Going to multiple mid-cycle meetups is even more difficult to justify so they're having to make difficult decisions about which to go to :-( I'm also not a fan of mid-cycle meetups because I feel it further stratifies our contributors into two increasly distinct camps - core vs non-core. I can see that a big benefit of a mid-cycle meetup is to be a focal point for collaboration, to forcably break contributors our of their day-to-day work pattern to concentrate on discussing specific issues. It also obviously solves the distinct timezone problem we have with our dispersed contributor base. I think that we should be examining what we can achieve with some kind of virtual online mid-cycle meetups instead. Using technology like google hangouts or some similar live collaboration technology, not merely an IRC discussion. Pick a 2-3 day period, schedule formal agendas / talking slots as you would with a physical summit and so on. I feel this would be more inclusive to our community as a whole, avoid excessive travel costs, so allowing more of our community to attend the bigger design summits. It would even open possibility of having multiple meetups during a cycle (eg could arrange mini virtual events around each milestone if we wanted) Regards, Daniel -- |: http://berrange.com -o-
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/12/2014 06:57 PM, Michael Still wrote: Hi. One of the action items from the nova midcycle was that I was asked to make nova's expectations of core reviews more clear. This email is an attempt at that. Note that we also have: https://wiki.openstack.org/wiki/Nova/CoreTeam so once new critera reaches consensus, it should be added there. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 05:57 AM, Daniel P. Berrange wrote: On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote: Hi. One of the action items from the nova midcycle was that I was asked to make nova's expectations of core reviews more clear. This email is an attempt at that. Nova expects a minimum level of sustained code reviews from cores. In the past this has been generally held to be in the order of two code reviews a day, which is a pretty low bar compared to the review workload of many cores. I feel that existing cores understand this requirement well, and I am mostly stating it here for completeness. Yep, this bit is obviously the most important. I would prefer a good level of review activity be the only *hard* requirement. Additionally, there is increasing levels of concern that cores need to be on the same page about the criteria we hold code to, as well as the overall direction of nova. While the weekly meetings help here, it was agreed that summit attendance is really important to cores. Its the way we decide where we're going for the next cycle, as well as a chance to make sure that people are all pulling in the same direction and trust each other. There is also a strong preference for midcycle meetup attendance, although I understand that can sometimes be hard to arrange. My stance is that I'd like core's to try to attend, but understand that sometimes people will miss one. In response to the increasing importance of midcycles over time, I commit to trying to get the dates for these events announced further in advance. Personally I'm going to find it really hard to justify long distance travel 4 times a year for OpenStack for personal / family reasons, let alone company cost. I couldn't attend Icehouse mid-cycle because I just had too much travel in a short time to be able to do another week long trip away from family. I couldn't attend Juno mid-cycle because it clashed we personal holiday. There are other opensource related conferences that I also have to attend (LinuxCon, FOSDEM, KVM Forum, etc), etc so doubling the expected number of openstack conferences from 2 to 4 is really very undesirable from my POV. I might be able to attend the occassional mid-cycle meetup if the location was convenient, but in general I don't see myself being able to attend them regularly. I tend to view the fact that we're emphasising the need of in-person meetups to be somewhat of an indication of failure of our community operation. The majority of open source projects work very effectively with far less face-to-face time. OpenStack is fortunate that companies are currently willing to spend 6/7-figure sums flying 1000's of developers around the world many times a year, but I don't see that lasting forever so I'm concerned about baking the idea of f2f midcycle meetups into our way of life even more strongly. I'm concerned about this, as well. There are lots of reasons people can't attend things (budget or personal reasons). I'd hate to think that not being able to travel this much (which I think is *a lot*) hurts someone's ability to be an important part of the nova team. Unfortunately, that's the direction we're trending. I also think it furthers the image of nova being an exclusive clique. I think we should always look at things as ways to be as inclusive as possible. Focusing the important conversations at the 4 in-person meetups per year leaves most of the community out. Given that we consider these physical events so important, I'd like people to let me know if they have travel funding issues. I can then approach the Foundation about funding travel if that is required. Travel funding is certainly an issue, but I'm not sure that Foundation funding would be a solution, because the impact probably isn't directly on the core devs. Speaking with my Red Hat on, if the midcycle meetup is important enough, the core devs will likely get the funding to attend. The fallout of this though is that every attendee at a mid-cycle summit means fewer attendees at the next design summit. So the impact of having more core devs at mid-cycle is that we'll get fewer non-core devs at the design summit. This sucks big time for the non-core devs who want to engage with our community. I can confirm that this is the effect I am seeing for our team. There were *a lot* of meetups this cycle, and it was expensive. This was actually one of the arguments against splitting the design summit out from the main conference, yet I'm afraid we've created the problem anyway. Also having each team do a f2f mid-cycle meetup at a different location makes it even harder for people who have a genuine desire / need to take part in multiple teams. Going to multiple mid-cycle meetups is even more difficult to justify so they're having to make difficult decisions about which to go to :-( Indeed, and we actually need to be strongly *encouraging* cross-project participation.
Re: [openstack-dev] [nova][core] Expectations of core reviewers
A big +1 to what daniel said, If f2f events are becoming so important the only way to get things done, IMHO we should really start to do some reflection on how our community operates and start thinking about what we are doing wrong. Expecting every company to send developers (core or non-core) to all these events is unrealistic (and IMHO is the wrong path our community should go down). If only cores go (they can probably convince their employers they should/need to), these f2f events become something akin to secret f2f meetings where decisions are made behind some set of closed-doors (maybe cores should then be renamed the 'secret society of core reviewers', maybe even giving them a illuminati like logo, haha), that doesn't seem very open to me (and as daniel said further stratifies the people who work on openstack...). Going the whole virtual route does seem better (although it still feels like something is wrong with how we are operating if that's even needed). -Josh On Wed, Aug 13, 2014 at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote: On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote: Hi. One of the action items from the nova midcycle was that I was asked to make nova's expectations of core reviews more clear. This email is an attempt at that. Nova expects a minimum level of sustained code reviews from cores. In the past this has been generally held to be in the order of two code reviews a day, which is a pretty low bar compared to the review workload of many cores. I feel that existing cores understand this requirement well, and I am mostly stating it here for completeness. Additionally, there is increasing levels of concern that cores need to be on the same page about the criteria we hold code to, as well as the overall direction of nova. While the weekly meetings help here, it was agreed that summit attendance is really important to cores. Its the way we decide where we're going for the next cycle, as well as a chance to make sure that people are all pulling in the same direction and trust each other. There is also a strong preference for midcycle meetup attendance, although I understand that can sometimes be hard to arrange. My stance is that I'd like core's to try to attend, but understand that sometimes people will miss one. In response to the increasing importance of midcycles over time, I commit to trying to get the dates for these events announced further in advance. Personally I'm going to find it really hard to justify long distance travel 4 times a year for OpenStack for personal / family reasons, let alone company cost. I couldn't attend Icehouse mid-cycle because I just had too much travel in a short time to be able to do another week long trip away from family. I couldn't attend Juno mid-cycle because it clashed we personal holiday. There are other opensource related conferences that I also have to attend (LinuxCon, FOSDEM, KVM Forum, etc), etc so doubling the expected number of openstack conferences from 2 to 4 is really very undesirable from my POV. I might be able to attend the occassional mid-cycle meetup if the location was convenient, but in general I don't see myself being able to attend them regularly. I tend to view the fact that we're emphasising the need of in-person meetups to be somewhat of an indication of failure of our community operation. The majority of open source projects work very effectively with far less face-to-face time. OpenStack is fortunate that companies are currently willing to spend 6/7-figure sums flying 1000's of developers around the world many times a year, but I don't see that lasting forever so I'm concerned about baking the idea of f2f midcycle meetups into our way of life even more strongly. Given that we consider these physical events so important, I'd like people to let me know if they have travel funding issues. I can then approach the Foundation about funding travel if that is required. Travel funding is certainly an issue, but I'm not sure that Foundation funding would be a solution, because the impact probably isn't directly on the core devs. Speaking with my Red Hat on, if the midcycle meetup is important enough, the core devs will likely get the funding to attend. The fallout of this though is that every attendee at a mid-cycle summit means fewer attendees at the next design summit. So the impact of having more core devs at mid-cycle is that we'll get fewer non-core devs at the design summit. This sucks big time for the non-core devs who want to engage with our community. Also having each team do a f2f mid-cycle meetup at a different location makes it even harder for people who have a genuine desire / need to take part in multiple teams. Going to multiple mid-cycle meetups is even more difficult to justify so they're having to make difficult decisions about which to go to :-( I'm also not a fan of mid-cycle meetups because I feel
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Wed, Aug 13, 2014 at 7:55 AM, Russell Bryant rbry...@redhat.com wrote: On 08/13/2014 05:57 AM, Daniel P. Berrange wrote: On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote: Hi. One of the action items from the nova midcycle was that I was asked to make nova's expectations of core reviews more clear. This email is an attempt at that. Nova expects a minimum level of sustained code reviews from cores. In the past this has been generally held to be in the order of two code reviews a day, which is a pretty low bar compared to the review workload of many cores. I feel that existing cores understand this requirement well, and I am mostly stating it here for completeness. Yep, this bit is obviously the most important. I would prefer a good level of review activity be the only *hard* requirement. Additionally, there is increasing levels of concern that cores need to be on the same page about the criteria we hold code to, as well as the overall direction of nova. While the weekly meetings help here, it was agreed that summit attendance is really important to cores. Its the way we decide where we're going for the next cycle, as well as a chance to make sure that people are all pulling in the same direction and trust each other. There is also a strong preference for midcycle meetup attendance, although I understand that can sometimes be hard to arrange. My stance is that I'd like core's to try to attend, but understand that sometimes people will miss one. In response to the increasing importance of midcycles over time, I commit to trying to get the dates for these events announced further in advance. Personally I'm going to find it really hard to justify long distance travel 4 times a year for OpenStack for personal / family reasons, let alone company cost. I couldn't attend Icehouse mid-cycle because I just had too much travel in a short time to be able to do another week long trip away from family. I couldn't attend Juno mid-cycle because it clashed we personal holiday. There are other opensource related conferences that I also have to attend (LinuxCon, FOSDEM, KVM Forum, etc), etc so doubling the expected number of openstack conferences from 2 to 4 is really very undesirable from my POV. I might be able to attend the occassional mid-cycle meetup if the location was convenient, but in general I don't see myself being able to attend them regularly. I tend to view the fact that we're emphasising the need of in-person meetups to be somewhat of an indication of failure of our community operation. The majority of open source projects work very effectively with far less face-to-face time. OpenStack is fortunate that companies are currently willing to spend 6/7-figure sums flying 1000's of developers around the world many times a year, but I don't see that lasting forever so I'm concerned about baking the idea of f2f midcycle meetups into our way of life even more strongly. I'm concerned about this, as well. There are lots of reasons people can't attend things (budget or personal reasons). I'd hate to think that not being able to travel this much (which I think is *a lot*) hurts someone's ability to be an important part of the nova team. Unfortunately, that's the direction we're trending. +1 I've seen a definitie uptick in travel for OpenStack, and it's not sustainable for all the reasons stated here. We need to figure out a better way to collaborate virtually, as we're a global Open Source project and we can't assume that everyone can travel all the time for all the mid-cycles, conferences, etc. I also think it furthers the image of nova being an exclusive clique. I think we should always look at things as ways to be as inclusive as possible. Focusing the important conversations at the 4 in-person meetups per year leaves most of the community out. Again, I agree with this assessment. We need to shift things back to the weekly IRC meetings, ML discussions, and perhaps some sort of virtual conference scheduling as well. Given that we consider these physical events so important, I'd like people to let me know if they have travel funding issues. I can then approach the Foundation about funding travel if that is required. Travel funding is certainly an issue, but I'm not sure that Foundation funding would be a solution, because the impact probably isn't directly on the core devs. Speaking with my Red Hat on, if the midcycle meetup is important enough, the core devs will likely get the funding to attend. The fallout of this though is that every attendee at a mid-cycle summit means fewer attendees at the next design summit. So the impact of having more core devs at mid-cycle is that we'll get fewer non-core devs at the design summit. This sucks big time for the non-core devs who want to engage with our community. I can confirm that this is the effect I am seeing for our team. There were *a lot* of meetups this cycle, and
Re: [openstack-dev] [nova][core] Expectations of core reviewers
Daniel P. Berrange [mailto:berra...@redhat.com] wrote: our dispersed contributor base. I think that we should be examining what we can achieve with some kind of virtual online mid-cycle meetups instead. Using technology like google hangouts or some similar live collaboration technology, not merely an IRC discussion. Pick a 2-3 day period, schedule formal agendas / talking slots as you would with a physical summit and so on. I feel this would be more inclusive to our community as a whole, avoid excessive travel costs, so allowing more of our community to attend the bigger design summits. It would even open possibility of having multiple meetups during a cycle (eg could arrange mini virtual events around each milestone if we wanted) How about arranging some high quality telepresence rooms? A number of the big companies associated with OpenStack either make or own some pretty nice systems. Perhaps it could be negotiated for some of these companies to open their doors to allow OpenStack developers for some scheduled events. With some scheduling and coordination effort it would probably be possible to setup a bunch of local meet-up points interconnected by telepresence links. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
Hi.
One of the action items from the nova midcycle was that I was asked to
make nova's expectations of core reviews more clear. This email is an
attempt at that.
Nova expects a minimum level of sustained code reviews from cores. In
the past this has been generally held to be in the order of two code
reviews a day, which is a pretty low bar compared to the review
workload of many cores. I feel that existing cores understand this
requirement well, and I am mostly stating it here for completeness.
Additionally, there is increasing levels of concern that cores need to
be on the same page about the criteria we hold code to, as well as the
overall direction of nova. While the weekly meetings help here, it was
agreed that summit attendance is really important to cores. Its the
way we decide where we're going for the next cycle, as well as a
chance to make sure that people are all pulling in the same direction
and trust each other.
There is also a strong preference for midcycle meetup attendance,
although I understand that can sometimes be hard to arrange. My stance
is that I'd like core's to try to attend, but understand that
sometimes people will miss one. In response to the increasing
importance of midcycles over time, I commit to trying to get the dates
for these events announced further in advance.
Personally I'm going to find it really hard to justify long distance
travel 4 times a year for OpenStack for personal / family reasons,
let alone company cost. I couldn't attend Icehouse mid-cycle because
I just had too much travel in a short time to be able to do another
week long trip away from family. I couldn't attend Juno mid-cycle
because it clashed we personal holiday. There are other opensource
related conferences that I also have to attend (LinuxCon, FOSDEM,
KVM Forum, etc), etc so doubling the expected number of openstack
conferences from 2 to 4 is really very undesirable from my POV.
I might be able to attend the occassional mid-cycle meetup if the
location was convenient, but in general I don't see myself being
able to attend them regularly.
I tend to view the fact that we're emphasising the need of in-person
meetups to be somewhat of an indication of failure of our community
operation. The majority of open source projects work very effectively
with far less face-to-face time. OpenStack is fortunate that companies
are currently willing to spend 6/7-figure sums flying 1000's of
developers around the world many times a year, but I don't see that
lasting forever so I'm concerned about baking the idea of f2f midcycle
meetups into our way of life even more strongly.
I was fortunate to attend both the Nova and Neutron mid-cycles last month, and
I can attest to how productive these gatherings were. Discussion moved quickly
and misunderstandings were rapidly resolved. Informal ('water-cooler')
conversation led to many interactions that might not otherwise have occurred.
Given your attendance of summit and other open source conferences, though, I'm
assuming the value of f2f is not in question.
Nothing good is ever free. The financial cost and exclusionary nature of an
in-person meetup should definitely be weighed against the opportunity for
focused and high-bandwidth communication. It's clear to myself and other
attendees just how valuable the recent mid-cycles were in terms of making
technical decisions and building the relationships to support their
implementation. Maybe it isn't sustainable over the long-term to meet so
often, but I don't think that should preclude us from deriving benefit in the
short-term. I also don't think we should ignore the opportunity for more
effective decision-making on the grounds that not everyone can directly
participate. Not everyone is able to attend summit, but it is nonetheless a
critical part of our community's decision-making process. The topic lists for a
mid-cycle are published beforehand, just like summit, to allow non-attendees
the chance to present their views in advance and/or designate one or more
attendees to advocate on
their behalf. It's not perfect, but the alternative - not holding mid-cycles
- would seem to be a case of throwing out the baby with the bathwater.
Maru
Given that we consider these physical events so important, I'd like
people to let me know if they have travel funding issues. I can then
approach the Foundation about funding travel if that is required.
Travel funding is certainly an issue, but I'm not sure that Foundation
funding would be a solution, because the impact probably isn't directly
on the core devs. Speaking with my Red Hat on, if the midcycle meetup
is important enough, the core devs will likely get the funding to attend.
The fallout of this though is that every attendee at a mid-cycle summit
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Wed, Aug 13, 2014 at 09:18:09AM -0700, Maru Newby wrote:
On Aug 13, 2014, at 2:57 AM, Daniel P. Berrange berra...@redhat.com wrote:
On Wed, Aug 13, 2014 at 08:57:40AM +1000, Michael Still wrote:
Hi.
One of the action items from the nova midcycle was that I was asked to
make nova's expectations of core reviews more clear. This email is an
attempt at that.
Nova expects a minimum level of sustained code reviews from cores. In
the past this has been generally held to be in the order of two code
reviews a day, which is a pretty low bar compared to the review
workload of many cores. I feel that existing cores understand this
requirement well, and I am mostly stating it here for completeness.
Additionally, there is increasing levels of concern that cores need to
be on the same page about the criteria we hold code to, as well as the
overall direction of nova. While the weekly meetings help here, it was
agreed that summit attendance is really important to cores. Its the
way we decide where we're going for the next cycle, as well as a
chance to make sure that people are all pulling in the same direction
and trust each other.
There is also a strong preference for midcycle meetup attendance,
although I understand that can sometimes be hard to arrange. My stance
is that I'd like core's to try to attend, but understand that
sometimes people will miss one. In response to the increasing
importance of midcycles over time, I commit to trying to get the dates
for these events announced further in advance.
Personally I'm going to find it really hard to justify long distance
travel 4 times a year for OpenStack for personal / family reasons,
let alone company cost. I couldn't attend Icehouse mid-cycle because
I just had too much travel in a short time to be able to do another
week long trip away from family. I couldn't attend Juno mid-cycle
because it clashed we personal holiday. There are other opensource
related conferences that I also have to attend (LinuxCon, FOSDEM,
KVM Forum, etc), etc so doubling the expected number of openstack
conferences from 2 to 4 is really very undesirable from my POV.
I might be able to attend the occassional mid-cycle meetup if the
location was convenient, but in general I don't see myself being
able to attend them regularly.
I tend to view the fact that we're emphasising the need of in-person
meetups to be somewhat of an indication of failure of our community
operation. The majority of open source projects work very effectively
with far less face-to-face time. OpenStack is fortunate that companies
are currently willing to spend 6/7-figure sums flying 1000's of
developers around the world many times a year, but I don't see that
lasting forever so I'm concerned about baking the idea of f2f midcycle
meetups into our way of life even more strongly.
I was fortunate to attend both the Nova and Neutron mid-cycles last
month, and I can attest to how productive these gatherings were.
Discussion moved quickly and misunderstandings were rapidly resolved.
Informal ('water-cooler') conversation led to many interactions that
might not otherwise have occurred. Given your attendance of summit
and other open source conferences, though, I'm assuming the value of
f2f is not in question.
I'm not questioning the value of f2f - I'm questioning the idea of
doing f2f meetings sooo many times a year. OpenStack is very much
the outlier here among open source projects - the vast majority of
projects get along very well with much less f2f time and a far
smaller % of their contributors attend those f2f meetings that do
happen. So I really do question what is missing from OpenStack's
community interaction that makes us believe that having 4 f2f
meetings a year is critical to our success.
Nothing good is ever free. The financial cost and exclusionary
nature of an in-person meetup should definitely be weighed against
the opportunity for focused and high-bandwidth communication. It's
clear to myself and other attendees just how valuable the recent
mid-cycles were in terms of making technical decisions and building
the relationships to support their implementation. Maybe it isn't
sustainable over the long-term to meet so often, but I don't think
that should preclude us from deriving benefit in the short-term.
As pointed out this benefit for core devs has a direct negative
impact on other non-core devs. I'm questioning whether this is
really a net win overall vs other approaches to collaboration.
I also don't think we should ignore the opportunity for more
effective decision-making on the grounds that not everyone
can directly participate. Not everyone is able to attend
summit, but it is nonetheless a critical part of our
community's decision-making process. The topic lists for a
mid-cycle are published beforehand, just like summit, to
allow non-attendees the chance to present their
Re: [openstack-dev] [nova][core] Expectations of core reviewers
I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). As pointed out this benefit for core devs has a direct negative impact on other non-core devs. I'm questioning whether this is really a net win overall vs other approaches to collaboration. It's a net win, IMHO. As I explain in the rest of my email below I'm not advocating getting rid of mid-cycle events entirely. I'm suggesting that we can attain a reasonable % of the benefits of f2f meetings by doing more formal virtual meetups and so be more efficient and inclusive overall. I'd love to see more high-bandwidth mechanisms used to have discussions in between f2f meetings. In fact, one of the outcomes of this last midcycle was that we should have one about APIv3 with the folks that couldn't attend for other reasons. It came up specifically because we made more progress in ninety minutes than we had in the previous eight months (yes, even with a design summit in the middle of that). Expecting cores to be at these sorts of things seems pretty reasonable to me, given the usefulness (and gravity) of the discussions we've been having so far. Companies with more cores will have to send more or make some hard decisions, but I don't want to cut back on the meetings until their value becomes unjustified. --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 01:09 PM, Dan Smith wrote: Expecting cores to be at these sorts of things seems pretty reasonable to me, given the usefulness (and gravity) of the discussions we've been having so far. Companies with more cores will have to send more or make some hard decisions, but I don't want to cut back on the meetings until their value becomes unjustified. I disagree. IMO, *expecting* people to travel, potentially across the globe, 4 times a year is an unreasonable expectation, and quite uncharacteristic of open source projects. If we can't figure out a way to have the most important conversations in a way that is inclusive of everyone, we're failing with our processes. By all means, if a subset wants to meet up and make progress on some things, I think that's fine. I don't think anyone think it's not useful. However, discussions need to be summarized and taken back to the list for discussion before decisions are made. That's not the way things are trending here, and I think that's a problem. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com wrote: On 08/13/2014 01:09 PM, Dan Smith wrote: Expecting cores to be at these sorts of things seems pretty reasonable to me, given the usefulness (and gravity) of the discussions we've been having so far. Companies with more cores will have to send more or make some hard decisions, but I don't want to cut back on the meetings until their value becomes unjustified. I disagree. IMO, *expecting* people to travel, potentially across the globe, 4 times a year is an unreasonable expectation, and quite uncharacteristic of open source projects. If we can't figure out a way to have the most important conversations in a way that is inclusive of everyone, we're failing with our processes. By all means, if a subset wants to meet up and make progress on some things, I think that's fine. I don't think anyone think it's not useful. However, discussions need to be summarized and taken back to the list for discussion before decisions are made. That's not the way things are trending here, and I think that's a problem. Count me in on the “not requiring travel” team here. I have multiple issues with travel, including that it is very stressful and tends to ruin my productivity for weeks leading up to it, and lots of us also have family responsibilities that are difficult and potentially expensive to arrange for an absense, such as child care. It’s difficult to compare OpenStack to other open source projects, in that it is on such a more massive and high velocity scale than almost any others (perhaps the Linux kernel is similar). It is certainly true that F2F meetings encourage better communications and sparking of new ideas and directions that wouldn’t otherwise have occurred, but then again I will also suggest that the difference in collaborative productivities for different individuals between F2F and remote probably varies highly based on the individual, including their social proclivities, specific projects and focus, and working styles.In this sense I’m really voting for an “all of the above” approach, in that yes we should do what we can to facilitate travel, we should do what we can to facilitate remote meetings over conferences and I love the idea of telepresence meetups, and we should give room to those who are very productive remotely and have difficulties with regular travel. The telepresence idea in particular opens the door to people meeting up in a semi-F2F style many more than four times per year, in fact. I wouldn’t mind at all going to an office every Friday to have our oslo.db meeting over a nice telepresence system. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 8/13/14 11:20 AM, Mike Bayer wrote: On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com wrote: I disagree. IMO, *expecting* people to travel, potentially across the globe, 4 times a year is an unreasonable expectation, and quite uncharacteristic of open source projects. If we can't figure out a way to have the most important conversations in a way that is inclusive of everyone, we're failing with our processes. By all means, if a subset wants to meet up and make progress on some things, I think that's fine. I don't think anyone think it's not useful. Well, it doesn't seem at all excessive to me, given the rate and volume at which we do things around here. That said, if a significant number of cores think it's not doable, then I guess that's a data point. From what you said above, it sounds like you're okay with the meetings but not the requirement for cores. I said expect above -- is that a reasonable thing? Expect them to be present, unless they have a reason not to be there? Reasons could be personal or preference, but hopefully not I never come to midcycles because $reason. It’s difficult to compare OpenStack to other open source projects, in that it is on such a more massive and high velocity scale than almost any others (perhaps the Linux kernel is similar). Yeah, I have a hard time justifying anything by comparing us to other projects. I've been involved with plenty and don't think any of them are useful data points for what we should or should not do here in terms of anything related to velocity :) --Dan signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 02:33 PM, Dan Smith wrote: On 8/13/14 11:20 AM, Mike Bayer wrote: On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com wrote: I disagree. IMO, *expecting* people to travel, potentially across the globe, 4 times a year is an unreasonable expectation, and quite uncharacteristic of open source projects. If we can't figure out a way to have the most important conversations in a way that is inclusive of everyone, we're failing with our processes. By all means, if a subset wants to meet up and make progress on some things, I think that's fine. I don't think anyone think it's not useful. Well, it doesn't seem at all excessive to me, given the rate and volume at which we do things around here. That said, if a significant number of cores think it's not doable, then I guess that's a data point. From what you said above, it sounds like you're okay with the meetings but not the requirement for cores. I said expect above -- is that a reasonable thing? Expect them to be present, unless they have a reason not to be there? Reasons could be personal or preference, but hopefully not I never come to midcycles because $reason. It’s difficult to compare OpenStack to other open source projects, in that it is on such a more massive and high velocity scale than almost any others (perhaps the Linux kernel is similar). Yeah, I have a hard time justifying anything by comparing us to other projects. I've been involved with plenty and don't think any of them are useful data points for what we should or should not do here in terms of anything related to velocity :) I think we also need to be careful with not continuing to increase expectations because of velocity. Burnout is a real problem. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/13/2014 02:44 PM, Russell Bryant wrote: On 08/13/2014 02:33 PM, Dan Smith wrote: On 8/13/14 11:20 AM, Mike Bayer wrote: On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com wrote: I disagree. IMO, *expecting* people to travel, potentially across the globe, 4 times a year is an unreasonable expectation, and quite uncharacteristic of open source projects. If we can't figure out a way to have the most important conversations in a way that is inclusive of everyone, we're failing with our processes. By all means, if a subset wants to meet up and make progress on some things, I think that's fine. I don't think anyone think it's not useful. Well, it doesn't seem at all excessive to me, given the rate and volume at which we do things around here. That said, if a significant number of cores think it's not doable, then I guess that's a data point. From what you said above, it sounds like you're okay with the meetings but not the requirement for cores. I said expect above -- is that a reasonable thing? Expect them to be present, unless they have a reason not to be there? Reasons could be personal or preference, but hopefully not I never come to midcycles because $reason. It’s difficult to compare OpenStack to other open source projects, in that it is on such a more massive and high velocity scale than almost any others (perhaps the Linux kernel is similar). Yeah, I have a hard time justifying anything by comparing us to other projects. I've been involved with plenty and don't think any of them are useful data points for what we should or should not do here in terms of anything related to velocity :) I think we also need to be careful with not continuing to increase expectations because of velocity. Burnout is a real problem. Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Aug 13, 2014, at 4:42 PM, Russell Bryant rbry...@redhat.com wrote: On 08/13/2014 02:44 PM, Russell Bryant wrote: On 08/13/2014 02:33 PM, Dan Smith wrote: On 8/13/14 11:20 AM, Mike Bayer wrote: On Aug 13, 2014, at 1:44 PM, Russell Bryant rbry...@redhat.com wrote: I disagree. IMO, *expecting* people to travel, potentially across the globe, 4 times a year is an unreasonable expectation, and quite uncharacteristic of open source projects. If we can't figure out a way to have the most important conversations in a way that is inclusive of everyone, we're failing with our processes. By all means, if a subset wants to meet up and make progress on some things, I think that's fine. I don't think anyone think it's not useful. Well, it doesn't seem at all excessive to me, given the rate and volume at which we do things around here. That said, if a significant number of cores think it's not doable, then I guess that's a data point. From what you said above, it sounds like you're okay with the meetings but not the requirement for cores. I said expect above -- is that a reasonable thing? Expect them to be present, unless they have a reason not to be there? Reasons could be personal or preference, but hopefully not I never come to midcycles because $reason. It’s difficult to compare OpenStack to other open source projects, in that it is on such a more massive and high velocity scale than almost any others (perhaps the Linux kernel is similar). Yeah, I have a hard time justifying anything by comparing us to other projects. I've been involved with plenty and don't think any of them are useful data points for what we should or should not do here in terms of anything related to velocity :) I think we also need to be careful with not continuing to increase expectations because of velocity. Burnout is a real problem. Let me try to say it another way. You seemed to say that it wasn't much to ask given the rate at which things happen in OpenStack. I would argue that given the rate, we should not try to ask more of individuals (like this proposal) and risk burnout. Instead, we should be doing our best to be more open an inclusive to give the project the best chance to grow, as that's the best way to get more done. I think an increased travel expectation is a raised bar that will hinder team growth, not help it. -- Russell Bryant +1, well said. Doug ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 3:09 AM, Dan Smith d...@danplanet.com wrote: I'm not questioning the value of f2f - I'm questioning the idea of doing f2f meetings sooo many times a year. OpenStack is very much the outlier here among open source projects - the vast majority of projects get along very well with much less f2f time and a far smaller % of their contributors attend those f2f meetings that do happen. So I really do question what is missing from OpenStack's community interaction that makes us believe that having 4 f2f meetings a year is critical to our success. How many is too many? So far, I have found the midcycles to be extremely productive -- productive in a way that we don't see at the summits, and I think other attendees agree. Obviously if budgets start limiting them, then we'll have to deal with it, but I don't want to stop meeting preemptively. I agree they're very productive. Let's pick on the nova v3 API case as an example... We had failed as a community to reach a consensus using our existing discussion mechanisms (hundreds of emails, at least three specs, phone calls between the various parties, et cetera), yet at the summit and then a midcycle meetup we managed to nail down an agreement on a very contentious and complicated topic. I can see the argument that travel cost is an issue, but I think its also not a very strong argument. We have companies spending millions of dollars on OpenStack -- surely spending a relatively small amount on travel to keep the development team as efficient as possible isn't a big deal? I wouldn't be at all surprised if the financial costs of the v3 API debate (staff time mainly) were much higher than the travel costs of those involved in the summit and midcycle discussions which sorted it out. Travelling to places to talk to people isn't a great solution, but it is the most effective one we've found so far. We should continue to experiment with other options, but until we find something that works as well as meetups, I think we need to keep having them. IMHO, the reasons to cut back would be: - People leaving with a well, that was useless... feeling - Not enough people able to travel to make it worthwhile So far, neither of those have been outcomes of the midcycles we've had, so I think we're doing okay. The design summits are structured differently, where we see a lot more diverse attendance because of the colocation with the user summit. It doesn't lend itself well to long and in-depth discussions about specific things, but it's very useful for what it gives us in the way of exposure. We could try to have less of that at the summit and more midcycle-ish time, but I think it's unlikely to achieve the same level of usefulness in that environment. Specifically, the lack of colocation with too many other projects has been a benefit. This time, Mark and Maru where there from Neutron. Last time, Mark from Neutron and the other Mark from Glance were there. If they were having meetups in other rooms (like at summit) they wouldn't have been there exposed to discussions that didn't seem like they'd have a component for their participation, but did after all (re: nova and glance and who should own flavors). I agree. The ability to focus on the issues that were blocking nova was very important. That's hard to do at a design summit when there is so much happening at the same time. As pointed out this benefit for core devs has a direct negative impact on other non-core devs. I'm questioning whether this is really a net win overall vs other approaches to collaboration. It's a net win, IMHO. As I explain in the rest of my email below I'm not advocating getting rid of mid-cycle events entirely. I'm suggesting that we can attain a reasonable % of the benefits of f2f meetings by doing more formal virtual meetups and so be more efficient and inclusive overall. I'd love to see more high-bandwidth mechanisms used to have discussions in between f2f meetings. In fact, one of the outcomes of this last midcycle was that we should have one about APIv3 with the folks that couldn't attend for other reasons. It came up specifically because we made more progress in ninety minutes than we had in the previous eight months (yes, even with a design summit in the middle of that). Expecting cores to be at these sorts of things seems pretty reasonable to me, given the usefulness (and gravity) of the discussions we've been having so far. Companies with more cores will have to send more or make some hard decisions, but I don't want to cut back on the meetings until their value becomes unjustified. I think this gets to the crux of the original email -- we are increasingly needing cores to understand the overall direction nova is going. You could argue for example that our failure to land many high priority blueprints in Juno is because cores aren't acting in coordinated a manner. So, we're attempting to come up with ways to improve
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 3:44 AM, Russell Bryant rbry...@redhat.com wrote: On 08/13/2014 01:09 PM, Dan Smith wrote: Expecting cores to be at these sorts of things seems pretty reasonable to me, given the usefulness (and gravity) of the discussions we've been having so far. Companies with more cores will have to send more or make some hard decisions, but I don't want to cut back on the meetings until their value becomes unjustified. I disagree. IMO, *expecting* people to travel, potentially across the globe, 4 times a year is an unreasonable expectation, and quite uncharacteristic of open source projects. If we can't figure out a way to have the most important conversations in a way that is inclusive of everyone, we're failing with our processes. I am a bit confused by this stance to be honest. You yourself said when you were Icehouse PTL that you wanted cores to come to the summit. What changed? By all means, if a subset wants to meet up and make progress on some things, I think that's fine. I don't think anyone think it's not useful. However, discussions need to be summarized and taken back to the list for discussion before decisions are made. That's not the way things are trending here, and I think that's a problem. The etherpad for the meetup has extensive notes. Any summary I write will basically be those notes in prose. What are you looking for in a summary that isn't in the etherpad? There also wasn't a summary of the Icehouse midcycle produced that I can find. Whilst I am happy to do one for Juno, its a requirement that I hadn't planned for, and is therefore taking me some time to retrofit. I think we should chalk the request for summaries up experience and talk through how to better provide such things at future meetups. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 14 August 2014 05:44, Russell Bryant rbry...@redhat.com wrote: By all means, if a subset wants to meet up and make progress on some things, I think that's fine. I don't think anyone think it's not useful. However, discussions need to be summarized and taken back to the list for discussion before decisions are made. That's not the way things are trending here, and I think that's a problem. Just to note, in the TripleO meetup we explicitly deferred most things - all things which we'd seek consensus on in the first place - back to the list for further discussion, once we had rough consensus at the f2f. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On 08/12/2014 06:57 PM, Michael Still wrote: Hi. One of the action items from the nova midcycle was that I was asked to make nova's expectations of core reviews more clear. This email is an attempt at that. Nova expects a minimum level of sustained code reviews from cores. In the past this has been generally held to be in the order of two code reviews a day, which is a pretty low bar compared to the review workload of many cores. I feel that existing cores understand this requirement well, and I am mostly stating it here for completeness. Additionally, there is increasing levels of concern that cores need to be on the same page about the criteria we hold code to, as well as the overall direction of nova. While the weekly meetings help here, it was agreed that summit attendance is really important to cores. Its the way we decide where we're going for the next cycle, as well as a chance to make sure that people are all pulling in the same direction and trust each other. There is also a strong preference for midcycle meetup attendance, although I understand that can sometimes be hard to arrange. My stance is that I'd like core's to try to attend, but understand that sometimes people will miss one. In response to the increasing importance of midcycles over time, I commit to trying to get the dates for these events announced further in advance. Given that we consider these physical events so important, I'd like people to let me know if they have travel funding issues. I can then approach the Foundation about funding travel if that is required. Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. Best, -jay ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com wrote: On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. What about making it easier for remote people to participate at the mid-cycle meetups? Set up some microphones and a Google hangout? At least that way attending the mid-cycle is not all or nothing. We did something like this last cycle (IIRC we didn't have enough mics) and it worked pretty well. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova][core] Expectations of core reviewers
On Thu, Aug 14, 2014 at 2:48 PM, Joe Gordon joe.gord...@gmail.com wrote: On Wed, Aug 13, 2014 at 8:31 PM, Michael Still mi...@stillhq.com wrote: On Thu, Aug 14, 2014 at 1:24 PM, Jay Pipes jaypi...@gmail.com wrote: Just wanted to quickly weigh in with my thoughts on this important topic. I very much valued the face-to-face interaction that came from the mid-cycle meetup in Beaverton (it was the only one I've ever been to). That said, I do not believe it should be a requirement that cores make it to the face-to-face meetings in-person. A number of folks have brought up very valid concerns about personal/family time, travel costs and burnout. I'm not proposing they be a requirement. I am proposing that they be strongly encouraged. I believe that the issue raised about furthering the divide between core and non-core folks is actually the biggest reason I don't support a mandate to have cores at the face-to-face meetings, and I think we should make our best efforts to support quality virtual meetings that can be done on a more frequent basis than the face-to-face meetings that would be optional. I am all for online meetings, but we don't have a practical way to do them at the moment apart from IRC. Until someone has a concrete proposal that's been shown to work, I feel its a straw man argument. What about making it easier for remote people to participate at the mid-cycle meetups? Set up some microphones and a Google hangout? At least that way attending the mid-cycle is not all or nothing. We did something like this last cycle (IIRC we didn't have enough mics) and it worked pretty well. As I said, I'm open to experimenting, but I need someone other than me to own that. I'm simply too busy to get to it. However, I don't think we should throw away the thing that works for best for us now, until we have a working replacement. I'm very much in favour of work being done on a replacement though. Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova][core] Expectations of core reviewers
Hi. One of the action items from the nova midcycle was that I was asked to make nova's expectations of core reviews more clear. This email is an attempt at that. Nova expects a minimum level of sustained code reviews from cores. In the past this has been generally held to be in the order of two code reviews a day, which is a pretty low bar compared to the review workload of many cores. I feel that existing cores understand this requirement well, and I am mostly stating it here for completeness. Additionally, there is increasing levels of concern that cores need to be on the same page about the criteria we hold code to, as well as the overall direction of nova. While the weekly meetings help here, it was agreed that summit attendance is really important to cores. Its the way we decide where we're going for the next cycle, as well as a chance to make sure that people are all pulling in the same direction and trust each other. There is also a strong preference for midcycle meetup attendance, although I understand that can sometimes be hard to arrange. My stance is that I'd like core's to try to attend, but understand that sometimes people will miss one. In response to the increasing importance of midcycles over time, I commit to trying to get the dates for these events announced further in advance. Given that we consider these physical events so important, I'd like people to let me know if they have travel funding issues. I can then approach the Foundation about funding travel if that is required. Thanks, Michael -- Rackspace Australia ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
