On Mon, Nov 2, 2015 at 7:08 AM, Rich Bowen <rbo...@rcbowen.com> wrote:
> > On 11/02/2015 06:59 AM, Joe Brockmeier 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. >> > > No, I don't think you're outdated or out of line. This pattern - open > ticket, commit change, close ticket, without time for community input - > does indicate that decision making is not open and collaborative, but > rather that the decision is being made offline somewhere. > > Furthermore, if the mentors are in agreement that something is awry, and > the podling disagrees, that's an indication that the podling is out of > line, not the mentors. After all, it's the mentors' job to guide the > podling, not vice versa. > I'm wondering, though, how this varies from our preference for the 'scratch-your-own-itch' model? In this case, it might be one programmer, or might be a customer of that programmer who noted a bug, or might be a small collaborative team working at their day job. All of these have every right to scratch their specific itch. In any case, the ASF and the dev@ list never dictate 'Jira ticket A is more important than Jira ticket B', any of the committers are welcome to work on any features, any open Jira tickets, anything that they feel improves a given project's code. It does not matter if this is a volunteer or employee, everyone is given equal treatment. Where this goes full-stop is where a significant change is introduced (Jira or not) without some time for the dev@ community to react. What constitutes "significant" varies from project to project, and also varies by whether it is changed on a C-T-R or R-T-C branch. The community business of deciding which branches are C-T-R or R-T-C, what the "significant" threshold is, and agreeing to such changes does belong on the dev@ list (or Jira ticket, as ticket activity also hits the mailing list)... and at a pace that the community worldwide can react to. At the Apache APR and HTTP Server projects, we have set that threshold to about 72 hours, which means not missing people who have day jobs / leave town for the weekend, and not excluding one time zone or another from larger discussions. I hope this is the sort of feedback you were asking for, Joe.
