> On Nov 2, 2015, at 8: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. > > So, yeah, I'd consider your -1 vote on their graduation to be binding here, > and I'd consider you to be doing the right thing to prevent that vote > happening in the first place until this community process is straightened out. > >
I haven’t looked at what they are doing and don’t expect I will. However, I’m assuming that jira changes all get to the dev list, as in all other projects I’ve worked on. I don’t see the point in duplicating a proposal between a jira issue and a separate dev list post with the same information. And I don’t have a problem with people working quickly. I would like to see that the jira issue explains sufficiently what is proposed or implemented in enough detail that an interested party can see how it fits in with the code and the purpose of the project. So I’d be concerned if the jira descriptions were “fix bug” or “implement javaee7” but possibly not if there are reasonable explanations of what is being proposed or done. david jencks --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
