Thanks for the explanation Joe. It seems like you are suggesting a process that you have seen work in the past and that is great. But every project is different and not every project community will adopt the same process. Hence I think this is not a valid ask.
I too feel that Mailing Lists are the life blood of communities and must be utilized for all communication. However, where I respectfully disagree with you (and perhaps with David) is that I don't think a direct email holds more weight than a Jira notification. If I open a Jira and provide my input/thoughts/and even a patch on it, it is the same to me as having an open discussion and then taking it to Jira. It is just a different way of communicating - wherein the Mailing List is the vehicle that connects all interested parties in the community. I would argue that keeping the technical discussion on the Jira is much better/cleaner than having it on the mailing list - that is just my view, and something I have done in the projects I have worked on. If I extrapolate or read between the lines, I feel another issue being pointed out or which has been eluded to in the past is - who decides which Jiras should be fixed, what features to create etc, specially when they show up as Jira issues directly with patches that follow soon. It seems that in some ways the lack of using mailing lists directly for discussion is linked to this behavior of filing issues and fixing them rapidly, as if following a roadmap that the community does not have control over. Please pardon me if my interpretation/understanding of the issue is not right. But if it is right, then I do want to say that - that too is not an issue in my opinion at all. And here is why: When someone files a Jira, they are inviting the entire community to comment on it and provide feedback. If it is not in the interest of the project, I do believe that responsible members of the community will be quick to bring that out for discussion and even Veto it if necessary. If that is not happening, it is not an issue with lack of community participation, but rather it is an indicator of a project team that knows where the gaps are and understands how to go about filling them intuitively. I know this because I too have been on the side of a project - much like Sentry - which was accused of not having a diverse community, lack of email communication, and overload of Jira issues, and possibly being guided by a silent hand that was not open to the community. Those were wrong and misplaced concerns, and the project has always behaved in the same way - even till today. Going back to Sentry - I feel that the project team is desperately trying to mend their ways to accommodate mentor requests but I don't think they can, despite their best intentions. The whole idea of hangouts and calls for the community seems like an unnecessary attempt at building community when in fact they have a great community to begin with! The project was functioning great as it was before, but our lack of appreciation for their process has led to these efforts which I don't think are helping at all. In fact these could be more damaging than before. Yes, we as mentors can guide them to a certain behavior but if what they are doing works for them, complies with the Apache Way, then who are we to question it? Last but not the least, I do agree that there were process mistakes made in the past around release management. Those have since been taken care off by the project team and addressed for subsequent releases. If that were a gating criteria, I think they are good to go. Regards, Arvind Prabhakar On Sun, Nov 1, 2015 at 7:13 PM, Joe Brockmeier <[email protected]> wrote: > On Sat, Oct 31, 2015, at 04:59 PM, Lenni Kuff wrote: > > Thanks for all the comments. Based on the previous feedback, we have > > tried > > to bring any offline discussions back to the dev list and have been using > > the dev list as the forum for any decision making (as David pointed out). > > In addition, Sravya has organized a regular monthly Google hangout [1] to > > help facilitate discussions which may be easier to have face-to-face/over > > the phone. The hangout will be open for anyone to join and all meeting > > notes will be posted back the dev mailing list. > > "Have tried" is not the same as actually doing, nor am I comfortable at > this stage saying "yes, as a mentor I feel this group has adopted best > practices from Apache and is going to continue doing this on its own > post-graduation." > > "Sravya has organized a regular monthly Google hangout" not quite. > Sravya has sent out an email that appears to have gone directly to VOTE > (no DISCUSS) for a 30-minute hangout. > > Note that this was about a week ago, and none of these hangouts have > actually happened - so it's impossible to judge its effectiveness and > describing it as "regular" at this point is a bit early. > > (As a side note, as much as I prefer discussions happen on a mailing > list - if you're going to do a real-time conversation, I am not sure 30 > minutes is sufficient. At least in my experience, it usually takes ~5 > minutes for a distributed team to actually join a call and get started, > and if you have any amount of discussion at all it would take some > ruthless efficiency to get through a discussion *and* have time for an > open floor for newcomers to ask questions.) > > > I apologize, but it's still bit unclear to me - based on the remaining > > criteria you outlined - specifically what we still need to accomplish > > before graduation. > > So - the discussion at ApacheCon happened, what, about a month ago? The > types of things we're pointing out are not just checkboxes for the > project to tick off, but fundamental practices we need to see in order > to say "yes, this project is going to behave like an Apache project > after graduation." > > Is Sentry producing code? Yes. > Is Sentry producing releases? Yes. > Is Sentry's infrastructure (Web site, Jira, mailing lists, and so on) in > order? Yes.* > > All great! > > The tough one: Is Sentry creating an open and diverse community that > allows anyone to participate? Right now, I don't think Sentry is there. > What I see right now is a podling that has had a fair amount of > communication about development out of the public eye and/or in channels > that are difficult to join for the public at large. > > David and I have given feedback on steps Sentry can take to remedy this. > What Sentry needs to accomplish now is to follow through on this and > build a track record there. (See also [1]) > > * Pretty sure. I did a quick cursory glance and things look good. > > [1] http://incubator.apache.org/guides/community.html#communication > > Best, > > jzb > -- > Joe Brockmeier > [email protected] > Twitter: @jzb > http://www.dissociatedpress.net/ >
