Re: PSA: JIRA resolutions and meanings
That's awesome Sean, very clear. One minor thing, noncommiters can't change assigned field as far as I know. On Oct 9, 2016 3:40 AM, "Sean Owen"wrote: I added a variant on this text to https://cwiki.apache.org/ confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark- ContributingtoJIRAMaintenance On Sat, Oct 8, 2016 at 10:09 AM Sean Owen wrote: > That flood of emails means several people (Xiao, Holden mostly AFAICT) > have been updating the status of old JIRAs. Thank you, I think that really > does help. > > I have a suggested set of conventions I've been using, just to bring some > order to the resolutions. It helps because JIRA functions as a huge archive > of decisions and the more accurately we can record that the better. What do > people think of this? > > - Resolve as Fixed if there's a change you can point to that resolved the > issue > - If the issue is a proper subset of another issue, mark it a Duplicate of > that issue (rather than the other way around) > - If it's probably resolved, but not obvious what fixed it or when, then > Cannot Reproduce or Not a Problem > - Obsolete issue? Not a Problem > - If it's a coherent issue but does not seem like there is support or > interest in acting on it, then Won't Fix > - If the issue doesn't make sense (non-Spark issue, etc) then Invalid > - I tend to mark Umbrellas as "Done" when done if they're just containers > - Try to set Fix version > - Try to set Assignee to the person who most contributed to the > resolution. Usually the person who opened the PR. Strong preference for > ties going to the more 'junior' contributor > > The only ones I think are sort of important are getting the Duplicate > pointers right, and possibly making sure that Fixed issues have a clear > path to finding what change fixed it and when. The rest doesn't matter much. > >
Re: PSA: JIRA resolutions and meanings
I added a variant on this text to https://cwiki.apache.org/confluence/display/SPARK/Contributing+to+Spark#ContributingtoSpark-ContributingtoJIRAMaintenance On Sat, Oct 8, 2016 at 10:09 AM Sean Owenwrote: > That flood of emails means several people (Xiao, Holden mostly AFAICT) > have been updating the status of old JIRAs. Thank you, I think that really > does help. > > I have a suggested set of conventions I've been using, just to bring some > order to the resolutions. It helps because JIRA functions as a huge archive > of decisions and the more accurately we can record that the better. What do > people think of this? > > - Resolve as Fixed if there's a change you can point to that resolved the > issue > - If the issue is a proper subset of another issue, mark it a Duplicate of > that issue (rather than the other way around) > - If it's probably resolved, but not obvious what fixed it or when, then > Cannot Reproduce or Not a Problem > - Obsolete issue? Not a Problem > - If it's a coherent issue but does not seem like there is support or > interest in acting on it, then Won't Fix > - If the issue doesn't make sense (non-Spark issue, etc) then Invalid > - I tend to mark Umbrellas as "Done" when done if they're just containers > - Try to set Fix version > - Try to set Assignee to the person who most contributed to the > resolution. Usually the person who opened the PR. Strong preference for > ties going to the more 'junior' contributor > > The only ones I think are sort of important are getting the Duplicate > pointers right, and possibly making sure that Fixed issues have a clear > path to finding what change fixed it and when. The rest doesn't matter much. > >
Re: PSA: JIRA resolutions and meanings
Cool, I'll start going through stuff as I have time. Already closed one, if anyone sees a problem let me know. Still think it would be nice to have some way to make it obvious to the people who have the will and knowledge to do it that it's ok for them to do it :) On Sat, Oct 8, 2016 at 2:19 PM, Reynold Xinwrote: > I think so (at least I think it is socially acceptable). Of course, use good > judgement here :) > > > > On Sat, Oct 8, 2016 at 12:06 PM, Cody Koeninger wrote: >> >> So to be clear, can I go clean up the Kafka cruft? >> >> On Sat, Oct 8, 2016 at 1:41 PM, Reynold Xin wrote: >> > >> > On Sat, Oct 8, 2016 at 2:09 AM, Sean Owen wrote: >> >> >> >> >> >> - Resolve as Fixed if there's a change you can point to that resolved >> >> the >> >> issue >> >> - If the issue is a proper subset of another issue, mark it a Duplicate >> >> of >> >> that issue (rather than the other way around) >> >> - If it's probably resolved, but not obvious what fixed it or when, >> >> then >> >> Cannot Reproduce or Not a Problem >> >> - Obsolete issue? Not a Problem >> >> - If it's a coherent issue but does not seem like there is support or >> >> interest in acting on it, then Won't Fix >> >> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid >> >> - I tend to mark Umbrellas as "Done" when done if they're just >> >> containers >> >> - Try to set Fix version >> >> - Try to set Assignee to the person who most contributed to the >> >> resolution. Usually the person who opened the PR. Strong preference for >> >> ties >> >> going to the more 'junior' contributor >> > >> > >> > +1 >> > >> > This is consistent with my understanding. It would be good to document >> > these >> > on JIRA. And I second "The only ones I think are sort of important are >> > getting the Duplicate pointers right, and possibly making sure that >> > Fixed >> > issues have a clear path to finding what change fixed it and when. The >> > rest >> > doesn't matter much." >> > >> > I also think it is a good idea to give people rights to close tickets to >> > help with JIRA maintenance. We can always revoke that if we see a >> > malicious >> > actor (or somebody with extremely bad judgement), but we are pretty far >> > away >> > from that right now. >> > >> > >> > > > - To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
Re: PSA: JIRA resolutions and meanings
I think so (at least I think it is socially acceptable). Of course, use good judgement here :) On Sat, Oct 8, 2016 at 12:06 PM, Cody Koeningerwrote: > So to be clear, can I go clean up the Kafka cruft? > > On Sat, Oct 8, 2016 at 1:41 PM, Reynold Xin wrote: > > > > On Sat, Oct 8, 2016 at 2:09 AM, Sean Owen wrote: > >> > >> > >> - Resolve as Fixed if there's a change you can point to that resolved > the > >> issue > >> - If the issue is a proper subset of another issue, mark it a Duplicate > of > >> that issue (rather than the other way around) > >> - If it's probably resolved, but not obvious what fixed it or when, then > >> Cannot Reproduce or Not a Problem > >> - Obsolete issue? Not a Problem > >> - If it's a coherent issue but does not seem like there is support or > >> interest in acting on it, then Won't Fix > >> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid > >> - I tend to mark Umbrellas as "Done" when done if they're just > containers > >> - Try to set Fix version > >> - Try to set Assignee to the person who most contributed to the > >> resolution. Usually the person who opened the PR. Strong preference for > ties > >> going to the more 'junior' contributor > > > > > > +1 > > > > This is consistent with my understanding. It would be good to document > these > > on JIRA. And I second "The only ones I think are sort of important are > > getting the Duplicate pointers right, and possibly making sure that Fixed > > issues have a clear path to finding what change fixed it and when. The > rest > > doesn't matter much." > > > > I also think it is a good idea to give people rights to close tickets to > > help with JIRA maintenance. We can always revoke that if we see a > malicious > > actor (or somebody with extremely bad judgement), but we are pretty far > away > > from that right now. > > > > > > >
Re: PSA: JIRA resolutions and meanings
So to be clear, can I go clean up the Kafka cruft? On Sat, Oct 8, 2016 at 1:41 PM, Reynold Xinwrote: > > On Sat, Oct 8, 2016 at 2:09 AM, Sean Owen wrote: >> >> >> - Resolve as Fixed if there's a change you can point to that resolved the >> issue >> - If the issue is a proper subset of another issue, mark it a Duplicate of >> that issue (rather than the other way around) >> - If it's probably resolved, but not obvious what fixed it or when, then >> Cannot Reproduce or Not a Problem >> - Obsolete issue? Not a Problem >> - If it's a coherent issue but does not seem like there is support or >> interest in acting on it, then Won't Fix >> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid >> - I tend to mark Umbrellas as "Done" when done if they're just containers >> - Try to set Fix version >> - Try to set Assignee to the person who most contributed to the >> resolution. Usually the person who opened the PR. Strong preference for ties >> going to the more 'junior' contributor > > > +1 > > This is consistent with my understanding. It would be good to document these > on JIRA. And I second "The only ones I think are sort of important are > getting the Duplicate pointers right, and possibly making sure that Fixed > issues have a clear path to finding what change fixed it and when. The rest > doesn't matter much." > > I also think it is a good idea to give people rights to close tickets to > help with JIRA maintenance. We can always revoke that if we see a malicious > actor (or somebody with extremely bad judgement), but we are pretty far away > from that right now. > > > - To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
Re: PSA: JIRA resolutions and meanings
On Sat, Oct 8, 2016 at 2:09 AM, Sean Owenwrote: > > - Resolve as Fixed if there's a change you can point to that resolved the > issue > - If the issue is a proper subset of another issue, mark it a Duplicate of > that issue (rather than the other way around) > - If it's probably resolved, but not obvious what fixed it or when, then > Cannot Reproduce or Not a Problem > - Obsolete issue? Not a Problem > - If it's a coherent issue but does not seem like there is support or > interest in acting on it, then Won't Fix > - If the issue doesn't make sense (non-Spark issue, etc) then Invalid > - I tend to mark Umbrellas as "Done" when done if they're just containers > - Try to set Fix version > - Try to set Assignee to the person who most contributed to the > resolution. Usually the person who opened the PR. Strong preference for > ties going to the more 'junior' contributor > +1 This is consistent with my understanding. It would be good to document these on JIRA. And I second "The only ones I think are sort of important are getting the Duplicate pointers right, and possibly making sure that Fixed issues have a clear path to finding what change fixed it and when. The rest doesn't matter much." I also think it is a good idea to give people rights to close tickets to help with JIRA maintenance. We can always revoke that if we see a malicious actor (or somebody with extremely bad judgement), but we are pretty far away from that right now.
Re: PSA: JIRA resolutions and meanings
+1 on this proposal and everyone can contribute to updates and discussions on JIRAs Will be great if this could be put on the Spark wiki. On Sat, Oct 8, 2016 at 9:05 AM -0700, "Ted Yu"> wrote: Makes sense. I trust Hyukjin, Holden and Cody's judgement in respective areas. I just wish to see more participation from the committers. Thanks > On Oct 8, 2016, at 8:27 AM, Sean Owen wrote: > > Hyukjin - To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
Re: PSA: JIRA resolutions and meanings
Makes sense. I trust Hyukjin, Holden and Cody's judgement in respective areas. I just wish to see more participation from the committers. Thanks > On Oct 8, 2016, at 8:27 AM, Sean Owenwrote: > > Hyukjin - To unsubscribe e-mail: dev-unsubscr...@spark.apache.org
Re: PSA: JIRA resolutions and meanings
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 Karauwrote: > 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 wrote: > > I think only committers should resolve JIRAs which were not created by > himself / herself. > > >
Re: PSA: JIRA resolutions and meanings
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 Yuwrote: > I think only committers should resolve JIRAs which were not created by > himself / herself. > > On Oct 8, 2016, at 6:53 AM, Hyukjin Kwon wrote: > > I am uncertain too. It'd be great if these are documented too. > > FWIW, in my case, I privately asked and told Sean first that I am going to > look though the JIRAs > and resolve some via the suggested conventions from Sean. > (Definitely all blames should be on me if I have done something terribly > wrong). > > > > 2016-10-08 22:37 GMT+09:00 Cody Koeninger : > >> That makes sense, thanks. >> >> One thing I've never been clear on is who should be allowed to resolve >> Jiras. Can I go clean up the backlog of Kafka Jiras that weren't created >> by me? >> >> If there's an informal policy here, can we update the wiki to reflect >> it? Maybe it's there already, but I didn't see it last time I looked. >> >> On Oct 8, 2016 4:10 AM, "Sean Owen" wrote: >> >> That flood of emails means several people (Xiao, Holden mostly AFAICT) >> have been updating the status of old JIRAs. Thank you, I think that really >> does help. >> >> I have a suggested set of conventions I've been using, just to bring some >> order to the resolutions. It helps because JIRA functions as a huge archive >> of decisions and the more accurately we can record that the better. What do >> people think of this? >> >> - Resolve as Fixed if there's a change you can point to that resolved the >> issue >> - If the issue is a proper subset of another issue, mark it a Duplicate >> of that issue (rather than the other way around) >> - If it's probably resolved, but not obvious what fixed it or when, then >> Cannot Reproduce or Not a Problem >> - Obsolete issue? Not a Problem >> - If it's a coherent issue but does not seem like there is support or >> interest in acting on it, then Won't Fix >> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid >> - I tend to mark Umbrellas as "Done" when done if they're just containers >> - Try to set Fix version >> - Try to set Assignee to the person who most contributed to the >> resolution. Usually the person who opened the PR. Strong preference for >> ties going to the more 'junior' contributor >> >> The only ones I think are sort of important are getting the Duplicate >> pointers right, and possibly making sure that Fixed issues have a clear >> path to finding what change fixed it and when. The rest doesn't matter much. >> >> >> > -- Cell : 425-233-8271 Twitter: https://twitter.com/holdenkarau
Re: PSA: JIRA resolutions and meanings
I think only committers should resolve JIRAs which were not created by himself / herself. > On Oct 8, 2016, at 6:53 AM, Hyukjin Kwonwrote: > > I am uncertain too. It'd be great if these are documented too. > > FWIW, in my case, I privately asked and told Sean first that I am going to > look though the JIRAs > and resolve some via the suggested conventions from Sean. > (Definitely all blames should be on me if I have done something terribly > wrong). > > > > 2016-10-08 22:37 GMT+09:00 Cody Koeninger : >> That makes sense, thanks. >> >> One thing I've never been clear on is who should be allowed to resolve >> Jiras. Can I go clean up the backlog of Kafka Jiras that weren't created by >> me? >> >> If there's an informal policy here, can we update the wiki to reflect it? >> Maybe it's there already, but I didn't see it last time I looked. >> >> >> On Oct 8, 2016 4:10 AM, "Sean Owen" wrote: >> That flood of emails means several people (Xiao, Holden mostly AFAICT) have >> been updating the status of old JIRAs. Thank you, I think that really does >> help. >> >> I have a suggested set of conventions I've been using, just to bring some >> order to the resolutions. It helps because JIRA functions as a huge archive >> of decisions and the more accurately we can record that the better. What do >> people think of this? >> >> - Resolve as Fixed if there's a change you can point to that resolved the >> issue >> - If the issue is a proper subset of another issue, mark it a Duplicate of >> that issue (rather than the other way around) >> - If it's probably resolved, but not obvious what fixed it or when, then >> Cannot Reproduce or Not a Problem >> - Obsolete issue? Not a Problem >> - If it's a coherent issue but does not seem like there is support or >> interest in acting on it, then Won't Fix >> - If the issue doesn't make sense (non-Spark issue, etc) then Invalid >> - I tend to mark Umbrellas as "Done" when done if they're just containers >> - Try to set Fix version >> - Try to set Assignee to the person who most contributed to the resolution. >> Usually the person who opened the PR. Strong preference for ties going to >> the more 'junior' contributor >> >> The only ones I think are sort of important are getting the Duplicate >> pointers right, and possibly making sure that Fixed issues have a clear path >> to finding what change fixed it and when. The rest doesn't matter much. >
Re: PSA: JIRA resolutions and meanings
I am uncertain too. It'd be great if these are documented too. FWIW, in my case, I privately asked and told Sean first that I am going to look though the JIRAs and resolve some via the suggested conventions from Sean. (Definitely all blames should be on me if I have done something terribly wrong). 2016-10-08 22:37 GMT+09:00 Cody Koeninger: > That makes sense, thanks. > > One thing I've never been clear on is who should be allowed to resolve > Jiras. Can I go clean up the backlog of Kafka Jiras that weren't created > by me? > > If there's an informal policy here, can we update the wiki to reflect it? > Maybe it's there already, but I didn't see it last time I looked. > > On Oct 8, 2016 4:10 AM, "Sean Owen" wrote: > > That flood of emails means several people (Xiao, Holden mostly AFAICT) > have been updating the status of old JIRAs. Thank you, I think that really > does help. > > I have a suggested set of conventions I've been using, just to bring some > order to the resolutions. It helps because JIRA functions as a huge archive > of decisions and the more accurately we can record that the better. What do > people think of this? > > - Resolve as Fixed if there's a change you can point to that resolved the > issue > - If the issue is a proper subset of another issue, mark it a Duplicate of > that issue (rather than the other way around) > - If it's probably resolved, but not obvious what fixed it or when, then > Cannot Reproduce or Not a Problem > - Obsolete issue? Not a Problem > - If it's a coherent issue but does not seem like there is support or > interest in acting on it, then Won't Fix > - If the issue doesn't make sense (non-Spark issue, etc) then Invalid > - I tend to mark Umbrellas as "Done" when done if they're just containers > - Try to set Fix version > - Try to set Assignee to the person who most contributed to the > resolution. Usually the person who opened the PR. Strong preference for > ties going to the more 'junior' contributor > > The only ones I think are sort of important are getting the Duplicate > pointers right, and possibly making sure that Fixed issues have a clear > path to finding what change fixed it and when. The rest doesn't matter much. > > >
Re: PSA: JIRA resolutions and meanings
That makes sense, thanks. One thing I've never been clear on is who should be allowed to resolve Jiras. Can I go clean up the backlog of Kafka Jiras that weren't created by me? If there's an informal policy here, can we update the wiki to reflect it? Maybe it's there already, but I didn't see it last time I looked. On Oct 8, 2016 4:10 AM, "Sean Owen"wrote: That flood of emails means several people (Xiao, Holden mostly AFAICT) have been updating the status of old JIRAs. Thank you, I think that really does help. I have a suggested set of conventions I've been using, just to bring some order to the resolutions. It helps because JIRA functions as a huge archive of decisions and the more accurately we can record that the better. What do people think of this? - Resolve as Fixed if there's a change you can point to that resolved the issue - If the issue is a proper subset of another issue, mark it a Duplicate of that issue (rather than the other way around) - If it's probably resolved, but not obvious what fixed it or when, then Cannot Reproduce or Not a Problem - Obsolete issue? Not a Problem - If it's a coherent issue but does not seem like there is support or interest in acting on it, then Won't Fix - If the issue doesn't make sense (non-Spark issue, etc) then Invalid - I tend to mark Umbrellas as "Done" when done if they're just containers - Try to set Fix version - Try to set Assignee to the person who most contributed to the resolution. Usually the person who opened the PR. Strong preference for ties going to the more 'junior' contributor The only ones I think are sort of important are getting the Duplicate pointers right, and possibly making sure that Fixed issues have a clear path to finding what change fixed it and when. The rest doesn't matter much.