Ok, let me reverse this discussion. We think hangouts are exclusive, and irc is not? I've seen multiple times when people were waaay into discussion, lines of text swarming the screen, somebody from outside speaks up, entirely reasonable and on topic thing, but is ignored because other actors in discussion were busy smashing keyboard to defend their mind? This person was unwillingly excluded from conversation and might feel bad enough to not speak up again. I've seen this happened. It happened to me on more than one occasion. That speak up thing might not be so easily ignored if actually spoken up in hangouts.
My point is, every communication channel has it's way to exclude people. Some people are intimidated to even speak up in public. Some people don't have money to travel to design summit. Saying that "we include everyone" is utopia. Best we can do is to try hard to be inclusive. I think having rules like "no ad hoc hangout meetings" will be extremely hurtful to communities. I am strong believer that different problems works better with different solutions, and that's true for communication too. Sometimes hot brainstorm-style ad hoc discussion is exactly what project need. Sometimes we need long, stretched discussion on ML, where everyone can speak up their mind in length. Kolla community have always put inclusiveness as one of it's main values to uphold, that is reflected in our diversity in both core team and general community stats. I did some digging and I think I know which particular hangout sprouted this whole discussion, so let me give you some context: 1. This hangout ended 2 week long ongoing disagreement that we couldn't resolve on irc or spec. It took 1hr of us actually talking to each other to finally come to conclusion. 2. Most of kolla-k8s active team was there discussing 3. Besides kolla-k8s team we also had kubernetes community members who are much more used to this type of discussion (not irc, so some could argue that *this* was inclusive way to work between two opensource communities, finding common toolset to communicate). 4. Part of why we did it in such an unplanned manned (therefore some people interested weren't present at the time) is that this k8s community members happened to join us at that time and we wanted to make most of it. 5. At the end it helped us greatly to move past problems that stalled our development for weeks. I will defend this thing as something what we needed at the time. Sometimes heated up video discussion helps to resolve misunderstandings which otherwise could grow up and become conflicts in community, which would be much worse. So please, let's not put artificial rules regarding our communication just to be "inclusive". If there is a will to be inclusive, we can be regardless of tool, if there is none, no tool will help. I will advocate to allow whichever way community decides to work to that community and focus on building culture of inclusiveness. If we have correct mindset, that's all that matters and I, for one, am strong believer that Kolla community has been built on top of this mindset, and we keep doing good job on following it. Regards, Michal On 15 December 2016 at 14:16, Zane Bitter <zbit...@redhat.com> wrote: > On 14/12/16 18:18, Michał Jastrzębski wrote: >> >> I agree that meeting notes are crucial to this type of meeting.I just >> say that gerrit PoC/demo is valid form of 'notes' if meeting was about >> some implementional detail, which I assume is the case for this type of >> meetings. >> >> Do we agree that as hoc hangout meetings are acceptable form of >> cooperation if invitation is own and notes are published? > > > It's not possible to have 100% open design. When I'm sitting alone at my > desk thinking, that's kind of like a videoconference of one. Nobody else can > be inside my head (much to y'all's relief, I'm sure). But open design means > that everything I come up with there is subject to review, and possibly > reversal, by the community. As such, it makes sense to keep the community > updated as regularly as possible. It may seem like that's slowing down your > work, but it actually speeds up the project as a whole because there's less > work to be thrown out when the consensus comes down another way. > > IMHO the same rules apply when there's more than one person involved. It's > fine to discuss, but not to think that you can make a decision for the > community without the involvement of the rest of the community. What's > really annoying is when some group gets together in private to discuss > Problem X, and then comes back to the community to announce that "we need to > implement Solution Y". That's not open design. Open design means laying out > Problem X, Solution Y, alternative Solution Z, and the reasoning behind > preferring one over the other, and then letting the community at large have > their say (perhaps even proposing completely different solutions) before > reaching a consensus. > > If the outcome of a private discussion is simply a Gerrit patch implementing > Solution Y then that feels dangerously close to the undesirable case to me > unless it's accompanied by extensive commentary. > > A post to the mailing list with the extra details is one way of handling it. > You have to trade off the extra cost of doing that against the benefit of a > high-bandwidth burst of (effectively private) communication. If it's still > worth it then that's OK. But if you try to have your cake and eat it then > you risk compromising the openness of your design process. > >> So if one of potential attendees cannot join for that reason, again I >> would consider this to be reason enough to move meeting back to irc. >> IRC is and keep being our default communication channel. > > > I'm glad you see it that way too. However, we also need to be mindful of the > fact that some people, especially newcomers, may not feel able to speak up > and demand that an out-of-band meeting of cores not take place. Particularly > if this becomes a routine occurrence. > > The next 'generation' of core reviewers will acquire their knowledge largely > from discussions between the current cores. It's important to the long-term > health of the project not to cut them off from those discussions, even at > some cost to the short-term velocity. > > cheers, > Zane. > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ 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