So while I will agree that in person communication is faster, and has higher throughput, it's not without problems for decision making for this community.
First it dramatically raises the barrier to participation. This is supposed to be a meritocracy. But shifting decisions, especially important decisions like release planning to an on-premise venue destroys that. It entails extensive travel for many if not most. In addition to the travel cost, for people whose $dayjob isn't 100% on CloudStack they'd miss several days of works, and then we can assume it's probably several hundred dollars a night for a hotel. This is not a cheap proposition, and we shouldn't presume that everyone wants to or can afford to attend an event. Keep in mind that the last event had around 1/3 of committers absent, and probably 1/3 or more of our current PMC was absent as well. We are not going to disenfranchise them. There is a reason that this conference doesn't bear a name like the CloudStack Design Conference, or CloudStack Leadership Summit. Off-list decisions are a threat to the health of this community. While I am not speaking for the PMC, I suspect that we'd sooner revoke permission for the conference to be held than to permit it to degenerate into a conference where those who can schedule, travel, and afford to participate get to make decisions about the project. --David On Fri, Apr 19, 2013 at 11:40 AM, Min Chen <min.c...@citrix.com> wrote: > I like this idea too, this will be a much better channel for community to > understand features to be planned. +1 to this. > > -min > > On 4/19/13 7:02 AM, "Prasanna Santhanam" <t...@apache.org> wrote: > >>On Fri, Apr 19, 2013 at 10:16:35AM +0000, Murali Reddy wrote: >>> >>> Pardon my ignorance of project management, but it appears to me we are >>> talking of managing a release after half way through the cycle. May be >>> this is orthogonal discussion, but how about taking approach of >>>planning a >>> release early in the cycle (at least for future releases)? Having a time >>> window between each release where we actually plan for the next release. >>> Discussions include - direction of the project, what big features are to >>> be included, rough estimate of the effort, risks and timelines would >>>help >>> in planning releases better? Perhaps we should use Collab conferences >>>for >>> this purpose, where we can plan for the next release (apart from show >>> casing the features of previous release). Since Collab is also scheduled >>> to happen on a half-yearly timeline it makes this easier to execute >>> release management starting from there. >> >>I actually like the idea of 'collab conference' to do release >>planning! So +1 to that. >> >>-- >>Prasanna., >
