Yeah, I've interacted with other projects that used that system and it was pleasant.
1. "this is getting closed cause its stale, let us know if thats a problem" 2. "actually that matters to us" 3. "ok well leave it open" I'd be fine with totally automating step 1 as long as a human was involved at step 2 and 3 On Saturday, October 8, 2016, assaf.mendelson <assaf.mendel...@rsa.com> wrote: > I don’t really have much experience with large open source projects but I > have some experience with having lots of issues with no one handling them. > Automation proved a good solution in my experience, but one thing that I > found which was really important is giving people a chance to say “don’t > close this please”. > > Basically, because closing you can send an email to the reporter (and > probably people who are watching the issue) and tell them this is going to > be closed. Allow them an option to ping back saying “don’t close this > please” which would ping committers for input (as if there were 5+ votes as > described by Nick). > > The main reason for this is that many times people fine solutions and the > issue does become stale but at other times, the issue is still important, > it is just that no one noticed it because of the noise of other issues. > > Thanks, > > Assaf. > > > > > > > > *From:* Nicholas Chammas [via Apache Spark Developers List] [mailto: > ml-node+ <javascript:_e(%7B%7D,'cvml','ml-node%2B');>[hidden email] > <http:///user/SendEmail.jtp?type=node&node=19322&i=0>] > *Sent:* Saturday, October 08, 2016 12:42 AM > *To:* Mendelson, Assaf > *Subject:* Re: Improving volunteer management / JIRAs (split from Spark > Improvement Proposals thread) > > > > I agree with Cody and others that we need some automation — or at least an > adjusted process — to help us manage organic contributions better. > > The objections about automated closing being potentially abrasive are > understood, but I wouldn’t accept that as a defeat for automation. Instead, > it seems like a constraint we should impose on any proposed solution: Make > sure it doesn’t turn contributors off. Rolling as we have been won’t cut > it, and I don’t think adding committers will ever be a sufficient solution > to this particular problem. > > To me, it seems like we need a way to filter out viable contributions with > community support from other contributions when it comes to deciding that > automated action is appropriate. Our current tooling isn’t perfect, but > perhaps we can leverage it to create such a filter. > > For example, consider the following strawman proposal for how to cut down > on the number of pending but unviable proposals, and simultaneously help > contributors organize to promote viable proposals and get the attention of > committers: > > 1. Have a bot scan for *stale* JIRA issues and PRs—i.e. they haven’t > been updated in 20+ days (or D+ days, if you prefer). > > 2. Depending on the level of community support, either close the > item or ping specific people for action. Specifically: > a. If the JIRA/PR has no input from a committer and the JIRA/PR has 5+ > votes (or V+ votes), ping committers for input. (For PRs, you could count > comments from different people, or thumbs up on the initial PR post.) > b. If the JIRA/PR has no input from a committer and the JIRA/PR has less > than V votes, close it with a gentle message asking the contributor to > solicit support from either the community or a committer, and try again > later. > c. If the JIRA/PR has input from a committer or committers, ping them for > an update. > > This is just a rough idea. The point is that when contributors have stale > proposals that they don’t close, committers need to take action. A little > automation to selectively bring contributions to the attention of > committers can perhaps help them manage the backlog of stale contributions. > The “selective” part is implemented in this strawman proposal by using JIRA > votes as a crude proxy for when the community is interested in something, > but it could be anything. > > Also, this doesn’t have to be used just to clear out stale proposals. Once > the initial backlog is trimmed down, you could set D to 5 days and use > this as a regular way to bring contributions to the attention of committers. > > I dunno if people think this is perhaps too complex, but at our scale I > feel we need some kind of loose but automated system for funneling > contributions through some kind of lifecycle. The status quo is just not > that good (e.g. 474 open PRs <https://github.com/apache/spark/pulls> > against Spark as of this moment). > > Nick > > > > > > On Fri, Oct 7, 2016 at 4:48 PM Cody Koeninger <[hidden email] > <http:///user/SendEmail.jtp?type=node&node=19310&i=0>> wrote: > > Matei asked: > > > > I agree about empowering people interested here to contribute, but I'm > wondering, do you think there are technical things that people don't want > to work on, or is it a matter of what there's been time to do? > > > It's a matter of mismanagement and miscommunication. > > The structured streaming kafka jira sat with multiple unanswered > requests for someone who was a committer to communicate whether they > were working on it and what the plan was. I could have done that > implementation and had it in users' hands months ago. I didn't > pre-emptively do it because I didn't want to then have to argue with > committers about why my code did or did not meet their uncommunicated > expectations. > > > I don't want to re-hash that particular circumstance, I just want to > make sure it never happens again. > > > Hopefully the SIP thread results in clearer expectations, but there > are still some ideas on the table regarding management of volunteer > contributions: > > > - Closing stale jiras. I hear the bots are impersonal argument, but > the alternative of "someone cleans it up" is not sufficient right now > (with apologies to Sean and all the other janitors). > > - Clear rejection of jiras. This isn't mean, it's respectful. > > - Clear "I'm working on this", with clear removal and reassignment if > they go radio silent. This could be keyed to automated check for > staleness. > > - Clear expectation that if someone is working on a jira, you can work > on your own alternative, but you need to communicate. > > > I'm sure I've missed some. > > --------------------------------------------------------------------- > To unsubscribe e-mail: [hidden email] > <http:///user/SendEmail.jtp?type=node&node=19310&i=1> > > > ------------------------------ > > *If you reply to this email, your message will be added to the discussion > below:* > > http://apache-spark-developers-list.1001551.n3.nabble.com/Improving- > volunteer-management-JIRAs-split-from-Spark-Improvement-Proposals-thread- > tp19305p19310.html > > To start a new topic under Apache Spark Developers List, email [hidden > email] <http:///user/SendEmail.jtp?type=node&node=19322&i=1> > To unsubscribe from Apache Spark Developers List, click here. > NAML > <http://apache-spark-developers-list.1001551.n3.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > > ------------------------------ > View this message in context: RE: Improving volunteer management / JIRAs > (split from Spark Improvement Proposals thread) > <http://apache-spark-developers-list.1001551.n3.nabble.com/Improving-volunteer-management-JIRAs-split-from-Spark-Improvement-Proposals-thread-tp19305p19322.html> > Sent from the Apache Spark Developers List mailing list archive > <http://apache-spark-developers-list.1001551.n3.nabble.com/> at > Nabble.com. >
