Open Stack

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 <zbitter at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev