I know what you mean Ted, and I think actually what's happening here is fine, but I'll explain my theory.
There are a range of actions in the project where someone makes a decision, from answering an email to creating a release. We already accept that only some of these require a formal status; anyone can answer emails, but only the PMC can bless a release, for example. The reason commits and releases require a certain status is not _entirely_ to block most people from participating in these activities. It's in part because things the ASF's liability protections for releases depend on the existence of well-defined governance models, that wouldn't quite be compatible with anyone adding software at will. Issue management isn't in this category, and, of course, we let anyone make JIRAs and PRs. This causes problems occasionally but is on the whole powerfully good. So, it seems reasonable to let people close JIRAs if, in good faith, they have clear reason to do so. These things are reversible, too. I also think there's a cost to not getting this triage work done, just as there would be a cost to blocking people from creating issues. I've reviewed the cleanup in the past 24 hours and agree with virtually every action, so I have confidence that in practice this is a big positive. That said, I have suggested in the past that perhaps only committers should set "Blocker" and "Target Version", because this communicates something specific about what will be committed and in what release, and acting on those requires commit access. Although by the theory above we should let anyone set these -- and actually, we do -- I have found it usually set incorrectly, and so, argue that these fields should be treated differently as a matter of convention. Sean On Sat, Oct 8, 2016 at 3:54 PM Holden Karau <hol...@pigscanfly.ca> wrote: > We could certainly do that system - but given the current somewhat small > set of active committers its clearly not scaling very well. There are many > developers in Spark like Hyukjin, Cody, and myself who care about specific > areas and can verify if an issue is still present in mainline. > > That being said if the general view is that only committers should resolve > JIRAs I'm happy to back off and leave that to the current committers (or we > could try ping them to close issues which I think are resolved instead of > closing them myself but given how many pings I sometimes have to make to > get an issue looked at I'm hesitant to suggest this system). > > I'll hold off on my JIRA review for a bit while we get this sorted :) > > On Sat, Oct 8, 2016 at 7:47 AM, Ted Yu <yuzhih...@gmail.com> wrote: > > I think only committers should resolve JIRAs which were not created by > himself / herself. > > >
