Open Stack

On 12/02/15 01:41 -0800, Nikhil Manchanda wrote:
>
>On Wed, Feb 11, 2015 at 1:55 AM, Flavio Percoco <flavio at redhat.com> wrote:
>> [...]
>>
>> ## Keep discussions open
>>
>> I don't believe there's anything wrong about kicking off some
>> discussions in private channels about specs/bugs. I don't believe
>> there's anything wrong in having calls to speed up some discussions.
>> HOWEVER, I believe it's *completely* wrong to consider those private
>> discussions sufficient. If you have had that kind of private
>> discussions, if you've discussed a spec privately and right after you
>> went upstream and said: "This has been discussed in a call and it's
>> good to go", I beg you to stop for 2 seconds and reconsider that. I
>> don't believe you were able to fit all the community in that call and
>> that you had enough consensus.
>>
>
>Completely agree with what you've said here. I think there's a place for
>private conversation (eg. discussing a security issue that corresponds
>to a CVE, giving folks honest feedback without public shaming, quickly
>pinging someone, etc.) but when it comes to discussions that have a
>bearing on a project (albeit however minimal) we need to ensure that all
>of those happen in the open, so that any interested parties are able to
>participate. Personally, I have not seen any examples of private talks
>which have led to making decisions in the absence of community
>discussion, but if this is happening -- we need to put a definitive stop
>to it.

I have seen it and I've also seen things like: "This was discussed in
a call and it's good to go"

CVE's are a special exception and I'd even argue on the need of
private conversations there. However, lets say there's a private IRC
discussion to quickly solve the CVE. Right after such discussion, the
feedback *has* to be put on the bug otherwise people reviewing the
patch - or even just following the bug - will be missing some context
on the proposed solution or state of the discussion. This fallsback to
the point that it'll probably take as much time to discuss something
privately and then explain it to others than simply keep it open.

That's why we have private bugs for CVEs.

As far as giving honest feedback goes, that's a "personal" conversation
and I don't really care how/where that happens as long as there are no
discussions about the project itself. If feeedback w.r.t the project -
no individual's comments, performance, work, code, etc - is being
discussed, it can perfectly happen in the public channel.

>> [...]
>>
>> ## Mailing List vs IRC Channel
>>
>> I get it, our mailing list is freaking busy, keeping up with it is
>> hard and time consuming and that leads to lots of IRC discussions. I
>> don't think there's anything wrong with that but I believe it's wrong
>> to expect *EVERYONE* to be in the IRC channel when those discussions
>> happen.
>>
>> If you are discussing something on IRC that requires the attention of
>> most of your project's community, I highly recommend you to use the
>> mailing list as oppose to pinging everyone independently and fighting
>> with time zones. Using IRC bouncers as a replacement for something
>> that should go to the mailing list is absurd. Please, use the mailing
>> list and don't be afraid of having a bigger community chiming in in
>> your discussion.  *THAT'S A GOOD THING*
>>
>> Changes, specs, APIs, etc. Everything is good for the mailing list.
>> We've fought hard to make this community grow, why shouldn't we take
>> advantage of it?
>>
>
>We should absolutely take advantage of all forms of communication, and
>all the tools that we have at our disposal so that we can foster more
>open and clear communication. However, I do realize that different
>strokes work for different folks. While many might find it more
>effective to communicate over email, others find IRC, or even a
>VOIP call a better way of ironing out differences. I don't think that
>makes any one method of communication better than others. While
>I personally believe that every discussion or design conversation that
>happens on IRC does not need to be taken to the mailing list, there's
>absolutely nothing that should prohibit anyone in the community from
>taking a discussion from IRC (or anywhere else) to the mailing list at
>_any_ time.

Probably not every decision but I'd go as far as saying that almost
all of them. The reason goes even beyond just openness. The mailing
list also brings history, indexed contents, etc. Good thing that many
channels have logging enabled.

The important bit, thoguh, is that email is meant for asynchronous
communication and IRC isn't. If things that require the intervention
of other folks from the community are being discussed and those folks
are not on IRC, it'd be wrong to consider the topic as "discussed".

Will that slow down the work? Yes, likely, but that's the trade-off
we're paying to keep things right and keep this community as a place
where we all feel comfortable to work in.

There's a lot of common sense in the decision of moving discussions to
the m-l or not. However, when in doubt, I'd say the mailing list is
the way to go.

>> ## Cores are *NOT* special
>>
>> At some point, for some reason that is unknown to me, this message
>> changed and the feeling of core's being some kind of superheros became
>> a thing. It's gotten far enough to the point that I've came to know
>> that some projects even have private (flagged with +s), password
>> protected, irc channels for core reviewers.
>> [...]
>
>Completely agree with you about cores not being super-heroes. On the
>latter point though, I'd consider that there's certainly a reasonable
>subset of conversations that are okay to have in private (like security
>related issues, and some other examples already cited above). However,
>if the existence of machinery which makes having such conversations
>convenient (hangout, private IRC, face-to-face in a closed room,
>whatever) seems to have a detrimental effect on the spirit of openness
>in our community, then I would err on the side of caution and dismantle
>that machinery rather than let our commitment to openness come under
>fire.

re CVEs, ditto. Other than that, +1

Flavio

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150212/9a2805ec/attachment.pgp>