I watch these lists, so I have a fair understanding of how things work around here. I don't give direct input in the day to day activities though, like Greg Stein on the other thread, so I can understand if it looks like it came from up above. Apache Members come around and give opinions time to time, you don't need to take it as somebody up above forcing things down.
Thanks +Vinod On Apr 22, 2015, at 2:33 PM, Nicholas Chammas <nicholas.cham...@gmail.com<mailto:nicholas.cham...@gmail.com>> wrote: I want to take this opportunity to call out the approach to communication you took here. As a random contributor to Spark and active participant on this list, my reaction when I read your email was this: * You do not know how the Spark community actually works. * You read a thread that contains some trigger phrases. * You wrote a lengthy response as a knee-jerk reaction. I’m not trying to mock, but I want to be direct and honest about how you came off in this thread to me and probably many others. Why not ask questions first—many questions? Why not make doubly sure that you understand the situation correctly before responding? In many ways this is much like filing a bug report. “I’m seeing this. It seems wrong to me. Is this expected?” I think we all know from experience that this kind of bug report is polite and will likely lead to a productive discussion. On the other hand: “You’re returning a -1 here? This is obviously wrong! And, boy, lemme tell you how wrong you are!!!” No-one likes to deal with bug reports like this. More importantly, they get in the way of fixing the actual problem, if there is one. This is not about the Apache Way or not. It’s about basic etiquette and effective communication. I understand that there are legitimate potential concerns here, and it’s important that, as an Apache project, Spark work according to Apache principles. But when some person who has never participated on this list pops up out of nowhere with a lengthy lecture on the Apache Way and whatnot, I have to say that that is not an effective way to communicate. Pretty much the same thing happened with Greg Stein on an earlier thread some months ago about designating maintainers for components. The concerns are legitimate, I’m sure, and we want to keep Spark in line with the Apache Way. And certainly, there have been many times when a project veered off course and needed to corrected. But when we want to make things right, I hope we can do it in a way that respectfully and tactfully engages the community. These “lectures delivered from above” — which is how they come off — are not helpful. Nick
