Open Stack

> -----Original Message-----
> From: Flavio Percoco [mailto:flavio at redhat.com]
> Sent: Wednesday, February 11, 2015 9:55 AM
> To: openstack-dev at lists.openstack.org
> Subject: [openstack-dev] [all][tc] Lets keep our community open, lets fight
> for it
> 
> Greetings all,
> 
> During the last two cycles, I've had the feeling that some of the things I love
> the most about this community are degrading and moving to a state that I
> personally disagree with. With the hope of seeing these things improve, I'm
> taking the time today to share one of my concerns.
> 
> Since I believe we all work with good faith and we *all* should assume such
> when it comes to things happening in our community, I won't make names
> and I won't point fingers - yes, I don't have enough fingers to point based on
> the info I have. People that fall into the groups I'll mention below know that
> I'm talking to them.
> 
> This email is dedicated to the openness of our community/project.
> 
> ## 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.

++
> 
> Furthermore, you should consider that having private conversations, at the
> very end, doesn't help with speeding up discussions. We've a community of
> people who *care* about the project they're working on.
> This means that whenever they see something that doesn't make much
> sense, they'll chime in and ask for clarification. If there was a private
> discussion on that topic, you'll have to provide the details of such discussion
> and bring that person up to date, which means the discussion will basically
> start again... from scratch.

And when they do come and ask for clarification do not just state that this was discussed and agreed already.
> 
> ## 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?

This is tough call ... ~ real time communication is just so much more efficient. You can get things done in minutes that would take hours & days to deal with over e-mail. It also does not help that the -dev mailing list is really crowded, the tags are not consistent (sorry for finger pointing but oslo seems to be specially inconsistent with some tagging [oslo] some tagging [oslo.something] etc. Please keep that [oslo] there ;D ).

I would not discourage people to use irc or other communication means, just being prepared to answer those questions again.
> 
> ## 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.
> 
> This is the point where my good faith assumption skill falls short.
> Seriously, don't get me wrong but: WHAT IN THE ACTUAL F**K?
> 
> THERE IS ABSOLUTELY NOTHING PRIVATE FOR CORE ****REVIEWERS*****
> TO DISCUSS.

Here I do disagree. There is stuff called private bugs for security etc. that _should_ kept private. Again speeds up progress hugely when the discussion does not need to happen in Launchpad and it keeps the bug itself cleaner as well. I do agree that there should not be secret society making common decisions behind closed doors, but there is reasons to keep some details initially between closed group only. And most commonly that closed group seems to be cores.
> 
> If anything core reviewers should be the ones *FORCING* - it seems that
> *encouraging* doesn't have the same effect anymore - *OPENNESS* in
> order to include other non-core members in those discussions.
> 
> Remember that the "core" flag is granted because of the reviews that person
> has provided and because that individual *WANTS* to be part of it. It's not a
> prize for people. In fact, I consider core reviewers to be volunteers and their
> job is infinitely thanked.
> 
> Since, "All generalizations are false, including this one. - Mark Twain", I'm
> pretty sure there are folks that disagree with the above.
> If you do, I care about your thoughts. This is worth discussing and fighting for.
> 
> All the above being said, I'd like to thank everyone who fights for the
> openness of our community and encourage everyone to make that a must
> have thing in each sub-community. You don't need to be core-reviewer or
> PTL to do so. Speak up and help keeping the community as open as possible.
> 
> Cheers,
> Flavio
> 
> --
> @flaper87
> Flavio Percoco

Thanks Flavio! 

I'd like to add couple general extra thoughts here:
1) Summit sessions seems to be "the ultimate decision making" ... I see constantly references to summit sessions as "decided" or "not open to discussion anymore". So much for openness! The sessions are not even recorded. If you don't belong to the group of privileged living in the area and receiving free ticket somehow or company paying your participation you're not included. $600 + travel + accommodation is quite hefty premium to be included, not really FOSS. I would heavily encourage all teams bringing the design session transcripts/memos/etc. to the mailing list for open discussion after the summit.

2) Open discussion != publicly recorded. My biggest concern here is currently our IRC channels. Most of them logged but not all, participants not notified about that logging and the logs _publicly_ available. Even gerrit does not show names before one has logged in. 

3) Not pointing any fingers here but gentle reminder for everyone. If we want to be open we need to be open for discussion as well. Please folks listen more and yell less (unless you are trying to get attention and participants to the discussion itself). I know I tend to get really pushy when I have strong opinions about something and I'm working on it. Don't take it personally, never intended so. But I know that there is other folks as well who need to look into mirror. If we really want to be as open as we claim to we need to stop having pseudo conversations with preset results.

4) Make noise to those whose life/work you're going to affect. Don't expect that the cross project spec repo is monitored by everybody or that single announcement on mailing list tagged with [nova][neutron] catches everybody's attention just because those project happened to be prototyping the proposal. Get that message out, promote the discussion on the IRC meetings and try to get that discussion started instead of proposing a spec into a repo and merging agreed two weeks later because no-one noticed it in the middle of the holiday season ;)

- Erno