Re: [openstack-dev] [all] Design Summit planning
On 18/09/14 16:03, Thierry Carrez wrote: Maish Saidel-Keesing wrote: On 17/09/2014 23:12, Anita Kuno wrote: On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote: This looks great - but I am afraid that something might be missing. As part of the Design summit in Atlanta there was an Ops Meetup track. [1] I do not see where this fits into the current planning process that has been posted. I would like to assume that part of the purpose of the summit is to also collect feedback from Enterprise Operators and also from smaller ones as well. If that is so then I would kindly request that there be some other way of allowing that part of the community to voice their concerns, and provide feedback. Perhaps a track that is not only Operator centric - but also an End-user focused one as well (mixing the two would be fine as well) Most of them are not on the openstack-dev list and they do not participate in the IRC team meetings, simply because they have no idea that these exist or maybe do not feel comfortable there. So they will not have any exposure to the process. My 0.02 Shekels. [1] - http://junodesignsummit.sched.org/overview/type/ops+meetup Hi Maish: This thread is about the Design Summit, the Operators Track is a different thing. In Atlanta the Operators Track was organized by Tom Fifield and I have every confidence he is working hard to ensure the operators have a voice in Paris and that those interested can participate. Last summit the Operators Track ran on the Monday and the Friday giving folks who usually spend most of the time at the Design summit to participate and hear the operator's voices. I know I did and I found it highly educational. Thanks, Anita. Thanks for the clarification Anita :) I think the plan is to have the Ops summit run on Monday, with an extra day on Thursday to continue the discussions. I CCed Tom for more input on that. Sorry for the delay all, and thanks for the kind notes. The ops meetup will indeed return in Paris. Standby for details and planning etherpad any day now - on the openstack-operators mailing list. Regards, Tom ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
Maish Saidel-Keesing wrote: On 17/09/2014 23:12, Anita Kuno wrote: On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote: This looks great - but I am afraid that something might be missing. As part of the Design summit in Atlanta there was an Ops Meetup track. [1] I do not see where this fits into the current planning process that has been posted. I would like to assume that part of the purpose of the summit is to also collect feedback from Enterprise Operators and also from smaller ones as well. If that is so then I would kindly request that there be some other way of allowing that part of the community to voice their concerns, and provide feedback. Perhaps a track that is not only Operator centric - but also an End-user focused one as well (mixing the two would be fine as well) Most of them are not on the openstack-dev list and they do not participate in the IRC team meetings, simply because they have no idea that these exist or maybe do not feel comfortable there. So they will not have any exposure to the process. My 0.02 Shekels. [1] - http://junodesignsummit.sched.org/overview/type/ops+meetup Hi Maish: This thread is about the Design Summit, the Operators Track is a different thing. In Atlanta the Operators Track was organized by Tom Fifield and I have every confidence he is working hard to ensure the operators have a voice in Paris and that those interested can participate. Last summit the Operators Track ran on the Monday and the Friday giving folks who usually spend most of the time at the Design summit to participate and hear the operator's voices. I know I did and I found it highly educational. Thanks, Anita. Thanks for the clarification Anita :) I think the plan is to have the Ops summit run on Monday, with an extra day on Thursday to continue the discussions. I CCed Tom for more input on that. -- 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] [all] Design Summit planning
This looks great - but I am afraid that something might be missing. As part of the Design summit in Atlanta there was an Ops Meetup track. [1] I do not see where this fits into the current planning process that has been posted. I would like to assume that part of the purpose of the summit is to also collect feedback from Enterprise Operators and also from smaller ones as well. If that is so then I would kindly request that there be some other way of allowing that part of the community to voice their concerns, and provide feedback. Perhaps a track that is not only Operator centric - but also an End-user focused one as well (mixing the two would be fine as well) Most of them are not on the openstack-dev list and they do not participate in the IRC team meetings, simply because they have no idea that these exist or maybe do not feel comfortable there. So they will not have any exposure to the process. My 0.02 Shekels. [1] - http://junodesignsummit.sched.org/overview/type/ops+meetup On 12/09/2014 18:42, Thierry Carrez wrote: Eoghan Glynn wrote: If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. +1 on a collaborative scheduling process within each project. That's pretty much what we did within the ceilometer core group for the Juno summit, except that we used a googledocs spreadsheet instead of an etherpad. So I don't think we need to necessarily mandate usage of an etherpad, just let every project decide whatever shared document format they want to use. FTR the benefit of a googledocs spreadsheet in my view would include the ease of totalling votes sessions slots, color-coding candidate sessions for merging etc. Good point. I've replaced the wording in the wiki page -- just use whatever suits you best, as long as it's a public document and you can link to it. -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote: This looks great - but I am afraid that something might be missing. As part of the Design summit in Atlanta there was an Ops Meetup track. [1] I do not see where this fits into the current planning process that has been posted. I would like to assume that part of the purpose of the summit is to also collect feedback from Enterprise Operators and also from smaller ones as well. If that is so then I would kindly request that there be some other way of allowing that part of the community to voice their concerns, and provide feedback. Perhaps a track that is not only Operator centric - but also an End-user focused one as well (mixing the two would be fine as well) Most of them are not on the openstack-dev list and they do not participate in the IRC team meetings, simply because they have no idea that these exist or maybe do not feel comfortable there. So they will not have any exposure to the process. My 0.02 Shekels. [1] - http://junodesignsummit.sched.org/overview/type/ops+meetup Hi Maish: This thread is about the Design Summit, the Operators Track is a different thing. In Atlanta the Operators Track was organized by Tom Fifield and I have every confidence he is working hard to ensure the operators have a voice in Paris and that those interested can participate. Last summit the Operators Track ran on the Monday and the Friday giving folks who usually spend most of the time at the Design summit to participate and hear the operator's voices. I know I did and I found it highly educational. Thanks, Anita. On 12/09/2014 18:42, Thierry Carrez wrote: Eoghan Glynn wrote: If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. +1 on a collaborative scheduling process within each project. That's pretty much what we did within the ceilometer core group for the Juno summit, except that we used a googledocs spreadsheet instead of an etherpad. So I don't think we need to necessarily mandate usage of an etherpad, just let every project decide whatever shared document format they want to use. FTR the benefit of a googledocs spreadsheet in my view would include the ease of totalling votes sessions slots, color-coding candidate sessions for merging etc. Good point. I've replaced the wording in the wiki page -- just use whatever suits you best, as long as it's a public document and you can link to it. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
On 17/09/2014 23:12, Anita Kuno wrote: On 09/17/2014 04:01 PM, Maish Saidel-Keesing wrote: This looks great - but I am afraid that something might be missing. As part of the Design summit in Atlanta there was an Ops Meetup track. [1] I do not see where this fits into the current planning process that has been posted. I would like to assume that part of the purpose of the summit is to also collect feedback from Enterprise Operators and also from smaller ones as well. If that is so then I would kindly request that there be some other way of allowing that part of the community to voice their concerns, and provide feedback. Perhaps a track that is not only Operator centric - but also an End-user focused one as well (mixing the two would be fine as well) Most of them are not on the openstack-dev list and they do not participate in the IRC team meetings, simply because they have no idea that these exist or maybe do not feel comfortable there. So they will not have any exposure to the process. My 0.02 Shekels. [1] - http://junodesignsummit.sched.org/overview/type/ops+meetup Hi Maish: This thread is about the Design Summit, the Operators Track is a different thing. In Atlanta the Operators Track was organized by Tom Fifield and I have every confidence he is working hard to ensure the operators have a voice in Paris and that those interested can participate. Last summit the Operators Track ran on the Monday and the Friday giving folks who usually spend most of the time at the Design summit to participate and hear the operator's voices. I know I did and I found it highly educational. Thanks, Anita. Thanks for the clarification Anita :) Maish On 12/09/2014 18:42, Thierry Carrez wrote: Eoghan Glynn wrote: If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. +1 on a collaborative scheduling process within each project. That's pretty much what we did within the ceilometer core group for the Juno summit, except that we used a googledocs spreadsheet instead of an etherpad. So I don't think we need to necessarily mandate usage of an etherpad, just let every project decide whatever shared document format they want to use. FTR the benefit of a googledocs spreadsheet in my view would include the ease of totalling votes sessions slots, color-coding candidate sessions for merging etc. Good point. I've replaced the wording in the wiki page -- just use whatever suits you best, as long as it's a public document and you can link to it. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Maish Saidel-Keesing ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
On 09/12/2014 11:54 AM, Thierry Carrez wrote: Anita Kuno wrote: My question involves third party discussions. Now I know at least Neutron is going to have a chat about drivers which involves third party ci accounts as a supportive aspect of that discussion, but I am wondering about the framework for a discussion which I can recommend attendees of the third party meetings to attend. They are shaping up to be an attentive, forward thinking group and are supporting each other which I was hoping for from the beginning so I am very heartened by our progress. I am feeling that as a group folks have questions and concerns they would appreciate the opportunity to air in a mutually constructive venue. What day and where would be the mutually constructive venue? I held off on Joe's thread since third party ci affects 4 or 5 programs, not enough to qualify in my mind as a topic that is OpenStack wide, but the programs it affects are quite affected, so I do feel it is time to mention it. I think those discussions could happen in a cross-project workshop. We'll run 2 or 3 of those in parallel all day Tuesday, so there is definitely room there. Thanks Thierry: The etherpad to co-ordinate discussions and priortization of third party items has been created: https://etherpad.openstack.org/p/kilo-third-party-items It will be announced at the third party meeting today: https://wiki.openstack.org/wiki/Meetings/ThirdParty#09.2F15.2F14 and is linked on this etherpad: https://etherpad.openstack.org/p/kilo-crossproject-summit-topics which is linked from this page: https://wiki.openstack.org/wiki/Summit/Planning Be sure to read the instructions at the top of the etherpad, which state: This is the planning document for the third party items we would like to discuss at Kilo Summit in Paris, November 2014 Please add items below, they will be discussed at the weekly third party meeting and top priorities will be selected. If there is an item which is of particular importance to you, I highly recommend that you or a delegate regularly attend the weekly third party meetings so that others may understand your perspective and take it into account when item priority is decided. While we welcome your submission and especially your participation, adding items to this etherpad is not a guarantee that your item will be dicussed during the alloted time, we will have to prioritize items to fit our timeslot. Weekly third party meeting: https://wiki.openstack.org/wiki/Meetings/ThirdParty Please bring any questions to todays or a subsequent third party meeting so we may discuss them. Thank you, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [all] Design Summit planning
Hi everyone, I visited the Paris Design Summit space on Monday and confirmed that it should be possible to split it in a way that would allow to have per-program contributors meetups on the Friday. The schedule would go as follows: Tuesday: cross-project workshops Wednesday, Thursday: traditional scheduled slots Friday: contributors meetups We'll also have pods available all 4 days for more ad-hoc small meetings. In the mean time, we need to discuss how we want to handle the selection of session topics. In past summits we used a Design-Summit-specific session suggestion website, and PTLs would approve/deny them. This setup grew less and less useful: session topics were selected collaboratively on etherpads, discussed in meetings, and finally filed/reorganized/merged on the website just before scheduling. Furthermore, with even less scheduled slots, we would have to reject most of the suggestions, which is more frustrating for submitters than the positive experience of joining team meetings to discuss which topics are the most important. Finally, topics will need to be split between scheduled sessions and the contributors meetup agenda, and that's easier to do on an Etherpad anyway. This is why I'd like to suggest that all programs use etherpads to collect important topics, select which ones would get in the very few scheduled slots we'll have left, which will get discussed in the contributors meetup, and which are better left for a pod discussion. I suggest we all use IRC team meetings to collaboratively discuss that content between interested contributors. To simplify the communication around this, I tried to collect the already-announced etherpads on a single page at: https://wiki.openstack.org/wiki/Summit/Planning Please add any that I missed ! If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. Regards, -- 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] [all] Design Summit planning
On 12/09/14 07:37, Thierry Carrez wrote: Hi everyone, I visited the Paris Design Summit space on Monday and confirmed that it should be possible to split it in a way that would allow to have per-program contributors meetups on the Friday. The schedule would go as follows: Tuesday: cross-project workshops Wednesday, Thursday: traditional scheduled slots Friday: contributors meetups We'll also have pods available all 4 days for more ad-hoc small meetings. In the mean time, we need to discuss how we want to handle the selection of session topics. In past summits we used a Design-Summit-specific session suggestion website, and PTLs would approve/deny them. This setup grew less and less useful: session topics were selected collaboratively on etherpads, discussed in meetings, and finally filed/reorganized/merged on the website just before scheduling. Furthermore, with even less scheduled slots, we would have to reject most of the suggestions, which is more frustrating for submitters than the positive experience of joining team meetings to discuss which topics are the most important. Finally, topics will need to be split between scheduled sessions and the contributors meetup agenda, and that's easier to do on an Etherpad anyway. This is why I'd like to suggest that all programs use etherpads to collect important topics, select which ones would get in the very few scheduled slots we'll have left, which will get discussed in the contributors meetup, and which are better left for a pod discussion. I suggest we all use IRC team meetings to collaboratively discuss that content between interested contributors. +1, this was #1 or #2 on my list of things where the PTL becomes a single point of failure. - ZB To simplify the communication around this, I tried to collect the already-announced etherpads on a single page at: https://wiki.openstack.org/wiki/Summit/Planning Please add any that I missed ! If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. Regards, ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
I visited the Paris Design Summit space on Monday and confirmed that it should be possible to split it in a way that would allow to have per-program contributors meetups on the Friday. The schedule would go as follows: Tuesday: cross-project workshops Wednesday, Thursday: traditional scheduled slots Friday: contributors meetups We'll also have pods available all 4 days for more ad-hoc small meetings. Excellent :) In the mean time, we need to discuss how we want to handle the selection of session topics. In past summits we used a Design-Summit-specific session suggestion website, and PTLs would approve/deny them. This setup grew less and less useful: session topics were selected collaboratively on etherpads, discussed in meetings, and finally filed/reorganized/merged on the website just before scheduling. Furthermore, with even less scheduled slots, we would have to reject most of the suggestions, which is more frustrating for submitters than the positive experience of joining team meetings to discuss which topics are the most important. Finally, topics will need to be split between scheduled sessions and the contributors meetup agenda, and that's easier to do on an Etherpad anyway. This is why I'd like to suggest that all programs use etherpads to collect important topics, select which ones would get in the very few scheduled slots we'll have left, which will get discussed in the contributors meetup, and which are better left for a pod discussion. I suggest we all use IRC team meetings to collaboratively discuss that content between interested contributors. To simplify the communication around this, I tried to collect the already-announced etherpads on a single page at: https://wiki.openstack.org/wiki/Summit/Planning Please add any that I missed ! If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. +1 on a collaborative scheduling process within each project. That's pretty much what we did within the ceilometer core group for the Juno summit, except that we used a googledocs spreadsheet instead of an etherpad. So I don't think we need to necessarily mandate usage of an etherpad, just let every project decide whatever shared document format they want to use. FTR the benefit of a googledocs spreadsheet in my view would include the ease of totalling votes sessions slots, color-coding candidate sessions for merging etc. Cheers, Eoghan ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
On 09/12/2014 07:37 AM, Thierry Carrez wrote: If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. I think this is fine, especially if it's a better reflection of reality and lets the teams work more efficiently. However, one of the benefits of the old submission system was the clarity of the process and openness to submissions from anyone. We don't want to be in a situation where non-core folks feel like they have a harder time submitting a session. Once this is settled, as long as the wiki pages [1][2] reflect the process and is publicized, it should be fine. [1] https://wiki.openstack.org/wiki/Summit [2] https://wiki.openstack.org/wiki/Summit/Planning -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
On 09/12/2014 07:37 AM, Thierry Carrez wrote: Hi everyone, I visited the Paris Design Summit space on Monday and confirmed that it should be possible to split it in a way that would allow to have per-program contributors meetups on the Friday. The schedule would go as follows: Tuesday: cross-project workshops Wednesday, Thursday: traditional scheduled slots Friday: contributors meetups We'll also have pods available all 4 days for more ad-hoc small meetings. In the mean time, we need to discuss how we want to handle the selection of session topics. In past summits we used a Design-Summit-specific session suggestion website, and PTLs would approve/deny them. This setup grew less and less useful: session topics were selected collaboratively on etherpads, discussed in meetings, and finally filed/reorganized/merged on the website just before scheduling. Furthermore, with even less scheduled slots, we would have to reject most of the suggestions, which is more frustrating for submitters than the positive experience of joining team meetings to discuss which topics are the most important. Finally, topics will need to be split between scheduled sessions and the contributors meetup agenda, and that's easier to do on an Etherpad anyway. This is why I'd like to suggest that all programs use etherpads to collect important topics, select which ones would get in the very few scheduled slots we'll have left, which will get discussed in the contributors meetup, and which are better left for a pod discussion. I suggest we all use IRC team meetings to collaboratively discuss that content between interested contributors. To simplify the communication around this, I tried to collect the already-announced etherpads on a single page at: https://wiki.openstack.org/wiki/Summit/Planning Please add any that I missed ! If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. Regards, Thanks Thierry, This looks like it should shape up to be a nice buffet of formats for us to evaluate and then provide feedback on what works best for whom at the wrap-up (which I believe will now be on the mailing list after the summit). My question involves third party discussions. Now I know at least Neutron is going to have a chat about drivers which involves third party ci accounts as a supportive aspect of that discussion, but I am wondering about the framework for a discussion which I can recommend attendees of the third party meetings to attend. They are shaping up to be an attentive, forward thinking group and are supporting each other which I was hoping for from the beginning so I am very heartened by our progress. I am feeling that as a group folks have questions and concerns they would appreciate the opportunity to air in a mutually constructive venue. What day and where would be the mutually constructive venue? I held off on Joe's thread since third party ci affects 4 or 5 programs, not enough to qualify in my mind as a topic that is OpenStack wide, but the programs it affects are quite affected, so I do feel it is time to mention it. Thanks, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
Eoghan Glynn wrote: If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. +1 on a collaborative scheduling process within each project. That's pretty much what we did within the ceilometer core group for the Juno summit, except that we used a googledocs spreadsheet instead of an etherpad. So I don't think we need to necessarily mandate usage of an etherpad, just let every project decide whatever shared document format they want to use. FTR the benefit of a googledocs spreadsheet in my view would include the ease of totalling votes sessions slots, color-coding candidate sessions for merging etc. Good point. I've replaced the wording in the wiki page -- just use whatever suits you best, as long as it's a public document and you can link to it. -- 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] [all] Design Summit planning
Russell Bryant wrote: On 09/12/2014 07:37 AM, Thierry Carrez wrote: If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. I think this is fine, especially if it's a better reflection of reality and lets the teams work more efficiently. However, one of the benefits of the old submission system was the clarity of the process and openness to submissions from anyone. We don't want to be in a situation where non-core folks feel like they have a harder time submitting a session. Once this is settled, as long as the wiki pages [1][2] reflect the process and is publicized, it should be fine. [1] https://wiki.openstack.org/wiki/Summit [2] https://wiki.openstack.org/wiki/Summit/Planning Yes, I'll document the new process and heavily publicize it, once I'm sure that's the way forward :) -- 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] [all] Design Summit planning
Anita Kuno wrote: My question involves third party discussions. Now I know at least Neutron is going to have a chat about drivers which involves third party ci accounts as a supportive aspect of that discussion, but I am wondering about the framework for a discussion which I can recommend attendees of the third party meetings to attend. They are shaping up to be an attentive, forward thinking group and are supporting each other which I was hoping for from the beginning so I am very heartened by our progress. I am feeling that as a group folks have questions and concerns they would appreciate the opportunity to air in a mutually constructive venue. What day and where would be the mutually constructive venue? I held off on Joe's thread since third party ci affects 4 or 5 programs, not enough to qualify in my mind as a topic that is OpenStack wide, but the programs it affects are quite affected, so I do feel it is time to mention it. I think those discussions could happen in a cross-project workshop. We'll run 2 or 3 of those in parallel all day Tuesday, so there is definitely room there. -- 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] [all] Design Summit planning
On 09/12/2014 11:54 AM, Thierry Carrez wrote: Anita Kuno wrote: My question involves third party discussions. Now I know at least Neutron is going to have a chat about drivers which involves third party ci accounts as a supportive aspect of that discussion, but I am wondering about the framework for a discussion which I can recommend attendees of the third party meetings to attend. They are shaping up to be an attentive, forward thinking group and are supporting each other which I was hoping for from the beginning so I am very heartened by our progress. I am feeling that as a group folks have questions and concerns they would appreciate the opportunity to air in a mutually constructive venue. What day and where would be the mutually constructive venue? I held off on Joe's thread since third party ci affects 4 or 5 programs, not enough to qualify in my mind as a topic that is OpenStack wide, but the programs it affects are quite affected, so I do feel it is time to mention it. I think those discussions could happen in a cross-project workshop. We'll run 2 or 3 of those in parallel all day Tuesday, so there is definitely room there. Thank you, I will co-ordinate with the group on an etherpad and start to prioritize items that we want to discuss. Thanks Thierry, Anita. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [all] Design Summit planning
On Sep 12, 2014 10:05 AM, Russell Bryant rbry...@redhat.com wrote: On 09/12/2014 07:37 AM, Thierry Carrez wrote: If you think this is wrong and think the design summit suggestion website is a better way to do it, let me know why! If some programs really can't stand the 'etherpad/IRC' approach I'll see how we can spin up a limited instance. I think this is fine, especially if it's a better reflection of reality and lets the teams work more efficiently. +1 this is the direction that Keystone's summit session planning was naturally headed. The session submission website was headed in a direction where it felt like more of a formality that didn't quite serve its intended purpose (aggregating and organizing discussion ideas), and didn't particularly benefit the community as a result, than it felt like a useful tool. The scheduling piece of it (which mapped topics to timeslots and pushed to sched.org), which I presume most non-PTLs ever saw, generally worked great. However, one of the benefits of the old submission system was the clarity of the process and openness to submissions from anyone. We don't want to be in a situation where non-core folks feel like they have a harder time submitting a session. I really hope that a less structured process will make it easier for everyone to contribute and advocate for discussion ideas in a collaborative manner. The design summit isn't about my session topic vs your session topic, it's about collaborating with our peers, regardless of whether that peer group is 2 people or 100. A discussion shouldn't be rejected because the group of interested parties is too small, it should simply find its place. Once this is settled, as long as the wiki pages [1][2] reflect the process and is publicized, it should be fine. [1] https://wiki.openstack.org/wiki/Summit [2] https://wiki.openstack.org/wiki/Summit/Planning -- Russell Bryant ___ 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
