On 11/02/15 11:31 +0000, Kuvaja, Erno wrote:
## 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 
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.

As I mentioned, I don't think there's anything wrong with a quick chat
fo sort small issues out that don't have a huge impact on the project.
However, those communications shouldn't be considered the ultimate
decision for things that will happen in the project.

A good example is the #openstack-glance channe, which you decided to
leave since we enabled logging. If we need to discuss something
outside the meeting - or start a discussion that simple won't fit in a
meeting - I'd need to choose between IRC discussions or mailing list.
I'll obviously choose the mailing list because I would hate it to
reach a consensus without listenting to your thoughts.

If m-l is not used, you'll likely share your opinion and that *WILL*
slow down the process anyway - a discussion that should've followed a
different path.

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 ).

In the case of oslo.messaging, we do this because we actually have
different groups depending on the project. We have a oslo-core team
and a oslo.messaging-core team. This encourages contributions on
topics that folks care about.

I don't think there's anything bad about that, just use filters.

I would not discourage people to use irc or other communication means, just 
being prepared to answer those questions again.

I'm discouraging the usage of IRC as the *main* communication channel.
I really hope no one, across the gazillion of projects I'm part of, is
expecting me to be present at every time on every channel (although I
am thanks to ZNC). That's phisically impossible, hence emails.

## 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?


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.

Note that my complain is about private core channels used for general
discussion. However, since you've brought the CVE thing up, lemme
disagree with you. CVE discussions should be kept in the LP bug as

Do you want to have a quick chat with someone about a bug? Sure, go
ahead. Afterwards, you MUST get back to the LP bug and provide the
feedback there. Otherwise, you just broke the process and other folks
that weren't part of that conversation will be out.

Also, must core-sec teams have some core members in them but not *all*
of them, which means the super secure core channel is just bullshit.
Random channels with obscured names created in a per-bug basis would
be even more secure than the super secure channel with +s and password
protected (yes, I just made this up).

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 

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.


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.

Agreed. Logging has other purposes that go beyond just being open.
Although, I agree with having logging enabled and I'd like *ALL*
channels to be logged.

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 ;)

This last point is probable worth discussing in a separate thread
since it's an impact on the process and not necessarily the community
or the openness of it.


Flavio Percoco

Attachment: pgpxVZ39g3wi6.pgp
Description: PGP signature

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to