On 11/02/15 11:31 +0000, Kuvaja, Erno wrote:
## Mailing List vs IRC ChannelI 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.
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? 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.
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 well. 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 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 PercocoThanks 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. Cheers, Flavio -- @flaper87 Flavio Percoco
pgpxVZ39g3wi6.pgp
Description: PGP signature
__________________________________________________________________________ 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
