You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@spark.apache.org by Cody Koeninger <co...@koeninger.org> on 2016/10/07 20:48:11 UTC
Improving volunteer management / JIRAs (split from Spark Improvement
Proposals thread)
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: dev-unsubscribe@spark.apache.org
Re: Improving volunteer management / JIRAs (split from Spark
Improvement Proposals thread)
Posted by vaquar khan <va...@gmail.com>.
Matei ,
I like your idea automatically email However it wont solve then problem.
Last few years i saw many enthusiastic sent mail and want to be Apache
Spark contributor ,Our response most welcome here is Jira , go and start
work on issues.
After few days /months struggle they have lost interest because not able to
understand where to start.
1) We should assign mentor to enthusiastic to understand issues and help to
start as contributor.
2) For high priority old Jira we should create separate group , who give
complete analysis in Jira so other can go and fix issue.
Reagrds,
Vaquar khan
On Sat, Oct 8, 2016 at 3:49 PM, Matei Zaharia <ma...@gmail.com>
wrote:
> I like this idea of asking them. BTW, one other thing we can do *provided
> the JIRAs are eventually under control* is to create a filter for old JIRAs
> that have not received a response in X amount of time and have the system
> automatically email the dev list with this report every month. Then
> everyone can see the list of items and maybe be reminded to take care to
> clean it up. This only works if the list is manageable and you actually
> want to read all of it.
>
> Matei
>
> On Oct 8, 2016, at 9:01 AM, Cody Koeninger <co...@koeninger.org> wrote:
>
> 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 <as...@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+[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 <http://nabble.com>.
>>
>
>
--
Regards,
Vaquar Khan
+1 -224-436-0783
IT Architect / Lead Consultant
Greater Chicago
Re: Improving volunteer management / JIRAs (split from Spark Improvement Proposals thread)
Posted by Matei Zaharia <ma...@gmail.com>.
I like this idea of asking them. BTW, one other thing we can do *provided the JIRAs are eventually under control* is to create a filter for old JIRAs that have not received a response in X amount of time and have the system automatically email the dev list with this report every month. Then everyone can see the list of items and maybe be reminded to take care to clean it up. This only works if the list is manageable and you actually want to read all of it.
Matei
> On Oct 8, 2016, at 9:01 AM, Cody Koeninger <co...@koeninger.org> wrote:
>
> 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.mendelson@rsa.com <ma...@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 <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.
Re: Improving volunteer management / JIRAs (split from Spark
Improvement Proposals thread)
Posted by Cody Koeninger <co...@koeninger.org>.
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 <as...@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.
>
RE: Improving volunteer management / JIRAs (split from Spark
Improvement Proposals thread)
Posted by "assaf.mendelson" <as...@rsa.com>.
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+s1001551n19310h99@n3.nabble.com]
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]</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]</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 ml-node+s1001551n1h20@n3.nabble.com<ma...@n3.nabble.com>
To unsubscribe from Apache Spark Developers List, click here<http://apache-spark-developers-list.1001551.n3.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1&code=YXNzYWYubWVuZGVsc29uQHJzYS5jb218MXwtMTI4OTkxNTg1Mg==>.
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: 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 at Nabble.com.
Re: Improving volunteer management / JIRAs (split from Spark
Improvement Proposals thread)
Posted by Nicholas Chammas <ni...@gmail.com>.
Ah yes, on a given JIRA issue the number of watchers is often a better
indicator of community interest than votes.
But yeah, it could be any metric or formula we want, as long as it yielded
a "reasonable" bar to cross for unsolicited contributions to get committer
review--or at the very least a comment from them saying yes/no/later.
On Fri, Oct 7, 2016 at 5:59 PM Cody Koeninger <co...@koeninger.org> wrote:
> I really like the idea of using jira votes (and/or watchers?) as a filter!
>
> On Fri, Oct 7, 2016 at 4:41 PM, Nicholas Chammas
> <ni...@gmail.com> wrote:
> > 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:
> >
> > 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).
> > 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 against Spark as of this moment).
> >
> > Nick
> >
> >
> > On Fri, Oct 7, 2016 at 4:48 PM Cody Koeninger <co...@koeninger.org>
> 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: dev-unsubscribe@spark.apache.org
> >>
> >
>
Re: Improving volunteer management / JIRAs (split from Spark
Improvement Proposals thread)
Posted by Cody Koeninger <co...@koeninger.org>.
I really like the idea of using jira votes (and/or watchers?) as a filter!
On Fri, Oct 7, 2016 at 4:41 PM, Nicholas Chammas
<ni...@gmail.com> wrote:
> 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:
>
> 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).
> 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 against Spark as of this moment).
>
> Nick
>
>
> On Fri, Oct 7, 2016 at 4:48 PM Cody Koeninger <co...@koeninger.org> 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: dev-unsubscribe@spark.apache.org
>>
>
---------------------------------------------------------------------
To unsubscribe e-mail: dev-unsubscribe@spark.apache.org
Re: Improving volunteer management / JIRAs (split from Spark
Improvement Proposals thread)
Posted by Nicholas Chammas <ni...@gmail.com>.
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 <co...@koeninger.org> 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: dev-unsubscribe@spark.apache.org
>
>