On Mon, Nov 02, 2015 at 05:27PM, Vinod Vavilapalli wrote: > Many of the active TLPs do tend to center all project discussions on JIRA as > opposed to mailing lists. OTOH, non-code discussions are usually best served > on mailing lists. > > Instead of making it a JIRA vs mailing list discussion, how about the > podling be advised about putting a cool-off period for JIRA resolutions - > 24-36hrs before they get closed. Again, this is something a bunch of active > TLPs practice in the interest of leaving enough time windows for everyone > (many times around the world in different time-zones) to pitch in.
I think these might be good development practices, but if there's an underlying issues with off-line decision making none of these tweak will solve it. The root issue needs to be addressed, if it indeed exists. But even for the tweaks you've proposed: some fixes/patches are mundane and keeping them on-hold for an arbitrary number of the hours will simply slow down the development. Some of the new features might be as well trivial: say adding new build target to combine certain build functions in a more convenient way, etc. etc. So, how to line up the rules and control they are being followed? Creation new policies even before the graduation happened sounds completely broken to me. What's important IMO is that committers on a project have enough sense to know when the input from the rest of the developers is needed and when a change is trivial enough to "just go in". That's a part of the podling maturity, as I see it: the effectiveness of the community inner-working; the trust that your peers are doing "the right thing". Cos > > On Nov 2, 2015, at 3:59 AM, Joe Brockmeier <j...@zonker.net> wrote: > > > > Hi all, > > > > I'm one of the mentors of Sentry, which has been in incubation for some > > time. The project has progressed in a number of ways, but my largest > > concern is that the podling is doing [in my opinion] too much > > development and discussion out-of-sight. > > > > I've raised issues about this, as has David Nalley. David had a > > conversation with members of Sentry at ApacheCon Big Data in September, > > and that discussion was brought back to the list. [1] > > > > Jiras are being filed, and swiftly acted on, in a way that strongly > > suggests that a lot of discussion and direction of the project are > > happening off-list and out-of-sight to the average participant. David > > and myself have suggested ways that the community can remedy this, but > > the most recent mail from Arvind indicates that he (and others in the > > podling) don't feel it is a "valid ask." > > > > At this point, I'm raising this to general@ because I'd like second (and > > third, etc.) opinions. Perhaps I'm deeply wrong, and others here feel > > Sentry is ready to graduate. My feeling is that the podling is not > > operating in "the Apache Way" and doesn't show a great deal of interest > > in doing so. [2] To quote Arvind: > > > > "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." > > > > The model that Sentry is pursing may work very well *for the existing > > members of the podling.* In my opinion, its process is entirely too > > opaque to allow for interested parties outside of the existing podling > > and companies interested in Sentry development to become involved. > > > > The podling is pressing to move to graduation, and I cannot in good > > conscience vote +1 or even +0 at this point. I'm strongly -1 as a mentor > > and don't feel the podling has any interest in working in "the Apache > > Way" as commonly understood. [3] > > > > However, I feel we've reached an impasse and there's little value in > > continuing to debate amongst the mentors / podling. They've stated their > > position(s) and I've stated mine. (I *think* David Nalley is in > > agreement with me, but I don't wish to speak for him.) > > > > I'm bringing this to the IPMC fully understanding that I might be > > totally wrong - maybe I'm holding to a too strict or outdated idea of > > how projects should operate. I'm happy to be told so if that's the case > > so I can improve as a mentor or decide to bow out from mentoring in the > > future, if it's the case that my idea of a project is out-of-line with > > the majority here. > > > > [1] http://s.apache.org/611 > > [2] http://s.apache.org/bhQ > > [3] http://theapacheway.com/ > > > > Best, > > > > jzb > > -- > > Joe Brockmeier > > j...@zonker.net > > Twitter: @jzb > > http://www.dissociatedpress.net/ > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org >
signature.asc
Description: Digital signature
