Excerpts from Jan Klare's message of 2016-02-25 17:43:19 +0100: > > > On 25 Feb 2016, at 15:54, Doug Hellmann <d...@doughellmann.com> wrote: > > > > Excerpts from Jan Klare's message of 2016-02-25 15:29:08 +0100: > >> > >>> On 25 Feb 2016, at 13:39, Daniel P. Berrange <berra...@redhat.com> wrote: > >>> > >>> On Thu, Feb 25, 2016 at 12:40:27PM +0100, Thierry Carrez wrote: > >>>> Qiming Teng wrote: > >>>>> [...] > >>>>> Week 1: > >>>>> Wednesday-Friday: 3 days Summit. > >>>>> * Primarily an event for marketing, sales, CTOs, architects, > >>>>> operators, journalists, ... > >>>>> * Contributors can decide whether they want to attend this. > >>>>> Saturday-Sunday: > >>>>> * Social activities: contributors meet-up, hang outs ... > >>>>> > >>>>> Week 2: > >>>>> Monday-Wednesday: 3 days Design Summit > >>>>> * Primarily an event for developers. > >>>>> * Operators can hold meetups during these days, or join project > >>>>> design summits. > >>>>> > >>>>> If you need to attend both events, you don't need two trips. Scheduling > >>>>> both events by the end of a release cycle can help gather more > >>>>> meaningful feedbacks, experiences or lessons from previous releases and > >>>>> ensure a better plan for the coming release. > >>>>> > >>>>> If you want to attend just the main Summit or only the Design Summit, > >>>>> you can plan your trip accordingly. > >>>> > >>>> This was an option we considered. The main objection was that we are > >>>> pretty > >>>> burnt out and ready to go home when comes Friday on a single-week event, > >>>> so > >>>> the prospect of doing two consecutive weeks looked a bit like madness > >>>> (especially considering ancillary events like upstream training, the > >>>> board > >>>> meeting etc. which tend to happen on the weekend before summit already). > >>>> It > >>>> felt like a good way to reduce our productivity and not make the most of > >>>> the > >>>> limited common time together. Furthermore it doesn't solve the issue of > >>>> suboptimal timing as described in my original email. > >> > >> I do not think that the other suggestion of two different events solves > >> the issues, but instead moves it to another suboptimal timing issue. > >>> > >>> I'd wager a sizeable number of contributors would outright refuse to > >>> attend > >>> an event for 2 weeks. 6-7 days away from family is already a long time. As > >>> such, I would certainly never do any event which spanned 2 weeks, even if > >>> both weeks were relevant to my work. > >> > >> I don’t think that the suggestion here was to create an event spanning two > >> full weeks. As far as i understand it, the OpenStack summit itself would > >> span nearly the exact same time as before and maybe even less if you > >> decide that you do not want to attend the main summit (or only a part of > >> it), but just the design one (or only a part of it). In addition to that, > >> i think the suggestion of 3 days in the first week and 3 days in the > >> following one is just something we can start a discussion about. I think > >> it would be enough to just have a 2 day main event (maybe Monday and > >> Tuesday) and schedule the design summit with 2 or 3 days directly after > >> that (Wednesday to Thursday or Friday). > > > > For most folks the summit now is a work week + 2 days for travel > > on either side of it, or at least 7 days (some of us travel further > > than others). Spreading it across 7 full days like this would mean > > I do not understand the 7 days you mention here, since i suggested an event > starting Monday and ending Friday, which would mean a total of 5 days. Adding > the travel time of two days, means we end up with a total of 7 days, which is > exactly the work week you mentioned.
The original proposal started on a Wednesday and ended on a Wednesday, and I should have been more clear that I was responding to that. Your proposal of 2 days followed by 3 is what we did before the contributor portion of the summit needed to grow to allow for more projects. I think 3 days won't be enough time to be effective. > > > at least 9 days for anyone who needs to be present for the entire > > event. Given that many technical folks do also need to be present > > for the conference portion of the event to meet with customers, I > > think there would likely be quite a few folks for whom this would > > turn into a very long, tiring, trip where productivity would drop off > > steeply near the middle. > > > > As Thierry pointed out, it's a bit questionable whether there's > > actually much savings for participants with the extended event. > > Anyone attending only one half will still need to fly to and stay > > in the more expensive venues we're using now, so they save nothing. > > Anyone attending both halves may save the cost of one airline ticket, > > unless they're going to mid-cycles which we wouldn't be able to > > eliminate. In which case extending the event *increases* their costs > > because they end up staying in the more expensive hotel for more > > nights. > > The difference in nights in comparison to the current summit of 4 days + 2 > days travel would be just one night and i do not think than one night in a > hotel is more expensive than the expenses for a completely separate event. The math works, but the shortened contributor event schedule does not. Doug > > > > > We also have to consider the extra difficulty and expense of trying > > to book a venue for such an extended time (considering set up and > > tear down time we need it for longer than we'll be actively using > > it, even if not by a lot). > > > > Doug > > > >> > >> Cheers, > >> Jan > >> > >>> > >>> > >>> Regards, > >>> Daniel > >>> -- > >>> |: http://berrange.com <http://berrange.com/> <http://berrange.com/ > >>> <http://berrange.com/>> -o- > >>> http://www.flickr.com/photos/dberrange/ > >>> <http://www.flickr.com/photos/dberrange/><http://www.flickr.com/photos/dberrange/ > >>> <http://www.flickr.com/photos/dberrange/>>:| > >>> |: http://libvirt.org <http://libvirt.org/> <http://libvirt.org/ > >>> <http://libvirt.org/>> -o- > >>> http://virt-manager.org <http://virt-manager.org/> > >>> <http://virt-manager.org/ <http://virt-manager.org/>> :| > >>> |: http://autobuild.org <http://autobuild.org/> <http://autobuild.org/ > >>> <http://autobuild.org/>> -o- > >>> http://search.cpan.org/~danberr/ > >>> <http://search.cpan.org/~danberr/><http://search.cpan.org/~danberr/ > >>> <http://search.cpan.org/~danberr/>> :| > >>> |: http://entangle-photo.org <http://entangle-photo.org/> > >>> <http://entangle-photo.org/ <http://entangle-photo.org/>> -o- > >>> http://live.gnome.org/gtk-vnc <http://live.gnome.org/gtk-vnc> > >>> <http://live.gnome.org/gtk-vnc <http://live.gnome.org/gtk-vnc>> :| > >>> > >>> __________________________________________________________________________ > >>> OpenStack Development Mailing List (not for usage questions) > >>> Unsubscribe: openstack-dev-requ...@lists.openstack.org > >>> <mailto:openstack-dev-requ...@lists.openstack.org><mailto:openstack-dev-requ...@lists.openstack.org > >>> <mailto:openstack-dev-requ...@lists.openstack.org>>?subject:unsubscribe > >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev><http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >>> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>> > > > > __________________________________________________________________________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: openstack-dev-requ...@lists.openstack.org > > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
