On 12/02/15 01:41 -0800, Nikhil Manchanda wrote:
On Wed, Feb 11, 2015 at 1:55 AM, Flavio Percoco <[email protected]> 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
pgpkVIwOjU40Z.pgp
Description: PGP signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
