Re: Should we let everyone set Assignee?
I like that idea (having a new-issues list instead of directly forwarding them to dev). On Fri, Apr 24, 2015 at 11:08 AM, Patrick Wendell pwend...@gmail.com wrote: It's a bit of a digression - but Steve's suggestion that we have a mailing list for new issues is a great idea and we can do it easily. We could nave new-issues@s.a.o or something (we already have issues@s.a.o). - Patrick On Fri, Apr 24, 2015 at 9:50 AM, Ted Yu yuzhih...@gmail.com wrote: bq. get newly created JIRAs posted onto a list (dev?) +1 On Fri, Apr 24, 2015 at 3:02 AM, Steve Loughran ste...@hortonworks.com wrote: I actually think the assignee JIRA issue is a minor detail; what really matters is do things get in and how. So far, in the bits I've worked on, I've not encountered any problems. And as I've stated in the hadoop-dev lists, my main concern there is long-standing patches that languish because nobody invests the time to look at other people's patches unless/until they are on the critical path or part of a late-night-emergency-patch event (e.g. HADOOP-11730). I'm as guilty there as everyone else -and I know that a reason is that a lot of those external patches come without good test coverage; getting something in usually involves dealing with that. So far, so good -and I'd like to praise Sean Owen here, as not only has he put in effort, being in the same TZ means I get feedback faster. Sean, I owe you beer the next time you are in Bristol. If some JIRA has someone say I'm working on it and then nothing happens, it's moot whether its in a drop-down list or a comment on the bottom. If someone else wants to take it up, unless they like duplicating effort, starting off other people's work -collaborating- is the best way to produce quality code. The only thing I would change is somehow get newly created JIRAs posted onto a list (dev?) that doesn't have the firehose of every other JIRA; issues@ is too noisy. -Steve On 23 Apr 2015, at 23:31, Sean Owen so...@cloudera.com wrote: The merge script automatically updates the linked JIRA after merging the PR (why it is important to put the JIRA in the title). It can't auto assign the JIRA since usernames dont match up but it is an easy reminder to set the Assignee. I do right after and I think other committers do too. I'll search later for Fixed and Unassigned JIRAs in case there are any. Feel free to flag any. In practice I think it is pretty rare that 2 people work on one JIRA accidentally and can't remember a case where there was disagreement about how to proceed. So I dont think a 'lock' is necessary in practice and don't think even signaling has been a problem. On Apr 23, 2015 6:14 PM, Ulanov, Alexander alexander.ula...@hp.com wrote: My thinking is that current way of assigning a contributor after the patch is done (or almost done) is OK. Parallel efforts are also OK until they are discussed in the issue's thread. Ilya Ganelin made a good point that it is about moving the project forward. It also adds means of competition who make it faster/better which is also good for the project and community. My only concern is about the throughput of Databricks folks who monitor issues, check patches and assign a contributor. Monitoring should be done on a constant basis (weekly?). - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: Should we let everyone set Assignee?
It's a bit of a digression - but Steve's suggestion that we have a mailing list for new issues is a great idea and we can do it easily. We could nave new-issues@s.a.o or something (we already have issues@s.a.o). - Patrick On Fri, Apr 24, 2015 at 9:50 AM, Ted Yu yuzhih...@gmail.com wrote: bq. get newly created JIRAs posted onto a list (dev?) +1 On Fri, Apr 24, 2015 at 3:02 AM, Steve Loughran ste...@hortonworks.com wrote: I actually think the assignee JIRA issue is a minor detail; what really matters is do things get in and how. So far, in the bits I've worked on, I've not encountered any problems. And as I've stated in the hadoop-dev lists, my main concern there is long-standing patches that languish because nobody invests the time to look at other people's patches unless/until they are on the critical path or part of a late-night-emergency-patch event (e.g. HADOOP-11730). I'm as guilty there as everyone else -and I know that a reason is that a lot of those external patches come without good test coverage; getting something in usually involves dealing with that. So far, so good -and I'd like to praise Sean Owen here, as not only has he put in effort, being in the same TZ means I get feedback faster. Sean, I owe you beer the next time you are in Bristol. If some JIRA has someone say I'm working on it and then nothing happens, it's moot whether its in a drop-down list or a comment on the bottom. If someone else wants to take it up, unless they like duplicating effort, starting off other people's work -collaborating- is the best way to produce quality code. The only thing I would change is somehow get newly created JIRAs posted onto a list (dev?) that doesn't have the firehose of every other JIRA; issues@ is too noisy. -Steve On 23 Apr 2015, at 23:31, Sean Owen so...@cloudera.com wrote: The merge script automatically updates the linked JIRA after merging the PR (why it is important to put the JIRA in the title). It can't auto assign the JIRA since usernames dont match up but it is an easy reminder to set the Assignee. I do right after and I think other committers do too. I'll search later for Fixed and Unassigned JIRAs in case there are any. Feel free to flag any. In practice I think it is pretty rare that 2 people work on one JIRA accidentally and can't remember a case where there was disagreement about how to proceed. So I dont think a 'lock' is necessary in practice and don't think even signaling has been a problem. On Apr 23, 2015 6:14 PM, Ulanov, Alexander alexander.ula...@hp.com wrote: My thinking is that current way of assigning a contributor after the patch is done (or almost done) is OK. Parallel efforts are also OK until they are discussed in the issue's thread. Ilya Ganelin made a good point that it is about moving the project forward. It also adds means of competition who make it faster/better which is also good for the project and community. My only concern is about the throughput of Databricks folks who monitor issues, check patches and assign a contributor. Monitoring should be done on a constant basis (weekly?). - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: Should we let everyone set Assignee?
+1 for new issues in dev list Отправлено с iPhone 24 апр. 2015 г., в 11:13, Reynold Xin r...@databricks.com написал(а): I like that idea (having a new-issues list instead of directly forwarding them to dev). On Fri, Apr 24, 2015 at 11:08 AM, Patrick Wendell pwend...@gmail.com wrote: It's a bit of a digression - but Steve's suggestion that we have a mailing list for new issues is a great idea and we can do it easily. We could nave new-issues@s.a.o or something (we already have issues@s.a.o). - Patrick On Fri, Apr 24, 2015 at 9:50 AM, Ted Yu yuzhih...@gmail.com wrote: bq. get newly created JIRAs posted onto a list (dev?) +1 On Fri, Apr 24, 2015 at 3:02 AM, Steve Loughran ste...@hortonworks.com wrote: I actually think the assignee JIRA issue is a minor detail; what really matters is do things get in and how. So far, in the bits I've worked on, I've not encountered any problems. And as I've stated in the hadoop-dev lists, my main concern there is long-standing patches that languish because nobody invests the time to look at other people's patches unless/until they are on the critical path or part of a late-night-emergency-patch event (e.g. HADOOP-11730). I'm as guilty there as everyone else -and I know that a reason is that a lot of those external patches come without good test coverage; getting something in usually involves dealing with that. So far, so good -and I'd like to praise Sean Owen here, as not only has he put in effort, being in the same TZ means I get feedback faster. Sean, I owe you beer the next time you are in Bristol. If some JIRA has someone say I'm working on it and then nothing happens, it's moot whether its in a drop-down list or a comment on the bottom. If someone else wants to take it up, unless they like duplicating effort, starting off other people's work -collaborating- is the best way to produce quality code. The only thing I would change is somehow get newly created JIRAs posted onto a list (dev?) that doesn't have the firehose of every other JIRA; issues@ is too noisy. -Steve On 23 Apr 2015, at 23:31, Sean Owen so...@cloudera.com wrote: The merge script automatically updates the linked JIRA after merging the PR (why it is important to put the JIRA in the title). It can't auto assign the JIRA since usernames dont match up but it is an easy reminder to set the Assignee. I do right after and I think other committers do too. I'll search later for Fixed and Unassigned JIRAs in case there are any. Feel free to flag any. In practice I think it is pretty rare that 2 people work on one JIRA accidentally and can't remember a case where there was disagreement about how to proceed. So I dont think a 'lock' is necessary in practice and don't think even signaling has been a problem. On Apr 23, 2015 6:14 PM, Ulanov, Alexander alexander.ula...@hp.com wrote: My thinking is that current way of assigning a contributor after the patch is done (or almost done) is OK. Parallel efforts are also OK until they are discussed in the issue's thread. Ilya Ganelin made a good point that it is about moving the project forward. It also adds means of competition who make it faster/better which is also good for the project and community. My only concern is about the throughput of Databricks folks who monitor issues, check patches and assign a contributor. Monitoring should be done on a constant basis (weekly?). - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: Should we let everyone set Assignee?
This is a great suggestion - definitely makes sense to have it. Regards, Mridul On Fri, Apr 24, 2015 at 11:08 AM, Patrick Wendell pwend...@gmail.com wrote: It's a bit of a digression - but Steve's suggestion that we have a mailing list for new issues is a great idea and we can do it easily. We could nave new-issues@s.a.o or something (we already have issues@s.a.o). - Patrick On Fri, Apr 24, 2015 at 9:50 AM, Ted Yu yuzhih...@gmail.com wrote: bq. get newly created JIRAs posted onto a list (dev?) +1 On Fri, Apr 24, 2015 at 3:02 AM, Steve Loughran ste...@hortonworks.com wrote: I actually think the assignee JIRA issue is a minor detail; what really matters is do things get in and how. So far, in the bits I've worked on, I've not encountered any problems. And as I've stated in the hadoop-dev lists, my main concern there is long-standing patches that languish because nobody invests the time to look at other people's patches unless/until they are on the critical path or part of a late-night-emergency-patch event (e.g. HADOOP-11730). I'm as guilty there as everyone else -and I know that a reason is that a lot of those external patches come without good test coverage; getting something in usually involves dealing with that. So far, so good -and I'd like to praise Sean Owen here, as not only has he put in effort, being in the same TZ means I get feedback faster. Sean, I owe you beer the next time you are in Bristol. If some JIRA has someone say I'm working on it and then nothing happens, it's moot whether its in a drop-down list or a comment on the bottom. If someone else wants to take it up, unless they like duplicating effort, starting off other people's work -collaborating- is the best way to produce quality code. The only thing I would change is somehow get newly created JIRAs posted onto a list (dev?) that doesn't have the firehose of every other JIRA; issues@ is too noisy. -Steve On 23 Apr 2015, at 23:31, Sean Owen so...@cloudera.com wrote: The merge script automatically updates the linked JIRA after merging the PR (why it is important to put the JIRA in the title). It can't auto assign the JIRA since usernames dont match up but it is an easy reminder to set the Assignee. I do right after and I think other committers do too. I'll search later for Fixed and Unassigned JIRAs in case there are any. Feel free to flag any. In practice I think it is pretty rare that 2 people work on one JIRA accidentally and can't remember a case where there was disagreement about how to proceed. So I dont think a 'lock' is necessary in practice and don't think even signaling has been a problem. On Apr 23, 2015 6:14 PM, Ulanov, Alexander alexander.ula...@hp.com wrote: My thinking is that current way of assigning a contributor after the patch is done (or almost done) is OK. Parallel efforts are also OK until they are discussed in the issue's thread. Ilya Ganelin made a good point that it is about moving the project forward. It also adds means of competition who make it faster/better which is also good for the project and community. My only concern is about the throughput of Databricks folks who monitor issues, check patches and assign a contributor. Monitoring should be done on a constant basis (weekly?). - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
RE: Should we let everyone set Assignee?
My thinking is that current way of assigning a contributor after the patch is done (or almost done) is OK. Parallel efforts are also OK until they are discussed in the issue's thread. Ilya Ganelin made a good point that it is about moving the project forward. It also adds means of competition who make it faster/better which is also good for the project and community. My only concern is about the throughput of Databricks folks who monitor issues, check patches and assign a contributor. Monitoring should be done on a constant basis (weekly?). Best regards, Alexander -Original Message- From: Vinod Kumar Vavilapalli [mailto:vino...@hortonworks.com] Sent: Wednesday, April 22, 2015 2:59 PM To: Patrick Wendell Cc: Nicholas Chammas; Ganelin, Ilya; Mark Hamstra; Sean Owen; dev Subject: Re: Should we let everyone set Assignee? Last one for the day. Everyone, as I said clearly, I was not alluding to anything fishy in practice, I was describing how things go wrong in such an environment. Sandy's email lays down some of these problems. Assigning a JIRA in other projects is not a reservation. It is a clear intention of working on design or code. You don't need a new convention of signaling. In almost all other projects, it is assigning tickets - that's how it is used. +Vinod On Apr 22, 2015, at 2:37 PM, Patrick Wendell pwend...@gmail.com wrote: Sandy - I definitely agree with that. We should have a convention of signaling someone intends to work - for instance by commenting on the JIRA and we should document this on the contribution guide. The nice thing about having that convention is that multiple people can say they are going to work on something, whereas only one person can be given the assignee slot on a JIRA. On Wed, Apr 22, 2015 at 2:33 PM, Nicholas Chammas nicholas.cham...@gmail.com wrote: To repeat what Patrick said (literally): If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. No-one in the Spark community dictates who gets to do work. When an issue is assigned to someone in JIRA, it's either because a) they did the work and the issue is now resolved, or b) they are signaling to others that they are working on it. In the case of b), nothing stops other people from working on the issue and it's quite normal for other people to complete issues that were technically assigned to someone else. There is no land grabbing or stalling. Anyone who has contributed to Spark for any amount of time knows this. Vinod, I want to take this opportunity to call out the approach to communication you took here. As a random contributor to Spark and active participant on this list, my reaction when I read your email was this: You do not know how the Spark community actually works. You read a thread that contains some trigger phrases. You wrote a lengthy response as a knee-jerk reaction. I'm not trying to mock, but I want to be direct and honest about how you came off in this thread to me and probably many others. Why not ask questions first--many questions? Why not make doubly sure that you understand the situation correctly before responding? In many ways this is much like filing a bug report. I'm seeing this. It seems wrong to me. Is this expected? I think we all know from experience that this kind of bug report is polite and will likely lead to a productive discussion. On the other hand: You're returning a -1 here? This is obviously wrong! And, boy, lemme tell you how wrong you are!!! No-one likes to deal with bug reports like this. More importantly, they get in the way of fixing the actual problem, if there is one. This is not about the Apache Way or not. It's about basic etiquette and effective communication. I understand that there are legitimate potential concerns here, and it's important that, as an Apache project, Spark work according to Apache principles. But when some person who has never participated on this list pops up out of nowhere with a lengthy lecture on the Apache Way and whatnot, I have to say that that is not an effective way to communicate. Pretty much the same thing happened with Greg Stein on an earlier thread some months ago about designating maintainers for components. The concerns are legitimate, I'm sure, and we want to keep Spark in line with the Apache Way. And certainly, there have been many times when a project veered off course and needed to corrected. But when we want to make things right, I hope we can do it in a way that respectfully and tactfully engages the community. These lectures delivered from above -- which is how they come off -- are not helpful. Nick On Wed, Apr 22, 2015 at 4:31 PM Ganelin, Ilya
RE: Should we let everyone set Assignee?
The merge script automatically updates the linked JIRA after merging the PR (why it is important to put the JIRA in the title). It can't auto assign the JIRA since usernames dont match up but it is an easy reminder to set the Assignee. I do right after and I think other committers do too. I'll search later for Fixed and Unassigned JIRAs in case there are any. Feel free to flag any. In practice I think it is pretty rare that 2 people work on one JIRA accidentally and can't remember a case where there was disagreement about how to proceed. So I dont think a 'lock' is necessary in practice and don't think even signaling has been a problem. On Apr 23, 2015 6:14 PM, Ulanov, Alexander alexander.ula...@hp.com wrote: My thinking is that current way of assigning a contributor after the patch is done (or almost done) is OK. Parallel efforts are also OK until they are discussed in the issue's thread. Ilya Ganelin made a good point that it is about moving the project forward. It also adds means of competition who make it faster/better which is also good for the project and community. My only concern is about the throughput of Databricks folks who monitor issues, check patches and assign a contributor. Monitoring should be done on a constant basis (weekly?). Best regards, Alexander -Original Message- From: Vinod Kumar Vavilapalli [mailto:vino...@hortonworks.com] Sent: Wednesday, April 22, 2015 2:59 PM To: Patrick Wendell Cc: Nicholas Chammas; Ganelin, Ilya; Mark Hamstra; Sean Owen; dev Subject: Re: Should we let everyone set Assignee? Last one for the day. Everyone, as I said clearly, I was not alluding to anything fishy in practice, I was describing how things go wrong in such an environment. Sandy's email lays down some of these problems. Assigning a JIRA in other projects is not a reservation. It is a clear intention of working on design or code. You don't need a new convention of signaling. In almost all other projects, it is assigning tickets - that's how it is used. +Vinod On Apr 22, 2015, at 2:37 PM, Patrick Wendell pwend...@gmail.com wrote: Sandy - I definitely agree with that. We should have a convention of signaling someone intends to work - for instance by commenting on the JIRA and we should document this on the contribution guide. The nice thing about having that convention is that multiple people can say they are going to work on something, whereas only one person can be given the assignee slot on a JIRA. On Wed, Apr 22, 2015 at 2:33 PM, Nicholas Chammas nicholas.cham...@gmail.com wrote: To repeat what Patrick said (literally): If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. No-one in the Spark community dictates who gets to do work. When an issue is assigned to someone in JIRA, it's either because a) they did the work and the issue is now resolved, or b) they are signaling to others that they are working on it. In the case of b), nothing stops other people from working on the issue and it's quite normal for other people to complete issues that were technically assigned to someone else. There is no land grabbing or stalling. Anyone who has contributed to Spark for any amount of time knows this. Vinod, I want to take this opportunity to call out the approach to communication you took here. As a random contributor to Spark and active participant on this list, my reaction when I read your email was this: You do not know how the Spark community actually works. You read a thread that contains some trigger phrases. You wrote a lengthy response as a knee-jerk reaction. I'm not trying to mock, but I want to be direct and honest about how you came off in this thread to me and probably many others. Why not ask questions first--many questions? Why not make doubly sure that you understand the situation correctly before responding? In many ways this is much like filing a bug report. I'm seeing this. It seems wrong to me. Is this expected? I think we all know from experience that this kind of bug report is polite and will likely lead to a productive discussion. On the other hand: You're returning a -1 here? This is obviously wrong! And, boy, lemme tell you how wrong you are!!! No-one likes to deal with bug reports like this. More importantly, they get in the way of fixing the actual problem, if there is one. This is not about the Apache Way or not. It's about basic etiquette and effective communication. I understand that there are legitimate potential concerns here, and it's important that, as an Apache project, Spark work according to Apache principles. But when some person who has never participated on this list pops up out
Re: Should we let everyone set Assignee?
One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches for something, provided everyone comments on JIRA saying they are intending to submit a patch, and everyone understands there is duplicate effort. So commenting with an intention to submit a patch, IMO seems like the healthiest workflow since it is non exclusive. To me the main benefit of assigning something ahead of time is if you have a committer that really wants to see someone specific work on a patch, it just acts as a strong signal that there is someone endorsed to work on that patch. That doesn't mean no one else can submit a patch, but it is IMO more of a warning that there may be existing work which is likely to be high quality, to avoid duplicated effort. When it was really easy to assign features to themselves, I saw a lot of anti-patterns in the community that seemed unhealthy, specifically: - It was really unclear what it means semantically if someone is assigned to a JIRA. - People assign JIRA's to themselves that aren't a good fit, given the authors level of experience. - People expect if they assign JIRA's to themselves that others won't submit patches, and become upset if they do. - People are discouraged from working on a patch because someone else was officially assigned. - Patrick On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen so...@cloudera.com wrote: Anecdotally, there are a number of people asking to set the Assignee field. This is currently restricted to Committers in JIRA. I know the logic was to prevent people from Assigning a JIRA and then leaving it; it also matters a bit for questions of credit. Still I wonder if it's best to just let people go ahead and set it, as the lesser evil. People can already do a lot like resolve JIRAs and set shepherd and critical priority and all that. I think the intent was to let Developers set this, but maybe due to an error, that's not how the current JIRA permission is implemented. I ask because I'm about to ping INFRA to update our scheme. - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: Should we let everyone set Assignee?
To repeat what Patrick said (literally): If an issue is “assigned” to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. No-one in the Spark community dictates who gets to do work. When an issue is assigned to someone in JIRA, it’s either because a) they did the work and the issue is now resolved, or b) they are signaling to others that they are working on it. In the case of b), nothing stops other people from working on the issue and it’s quite normal for other people to complete issues that were technically assigned to someone else. There is no land grabbing or stalling. Anyone who has contributed to Spark for any amount of time knows this. Vinod, I want to take this opportunity to call out the approach to communication you took here. As a random contributor to Spark and active participant on this list, my reaction when I read your email was this: - You do not know how the Spark community actually works. - You read a thread that contains some trigger phrases. - You wrote a lengthy response as a knee-jerk reaction. I’m not trying to mock, but I want to be direct and honest about how you came off in this thread to me and probably many others. Why not ask questions first—many questions? Why not make doubly sure that you understand the situation correctly before responding? In many ways this is much like filing a bug report. “I’m seeing this. It seems wrong to me. Is this expected?” I think we all know from experience that this kind of bug report is polite and will likely lead to a productive discussion. On the other hand: “You’re returning a -1 here? This is obviously wrong! And, boy, lemme tell you how wrong you are!!!” No-one likes to deal with bug reports like this. More importantly, they get in the way of fixing the actual problem, if there is one. This is not about the Apache Way or not. It’s about basic etiquette and effective communication. I understand that there are legitimate potential concerns here, and it’s important that, as an Apache project, Spark work according to Apache principles. But when some person who has never participated on this list pops up out of nowhere with a lengthy lecture on the Apache Way and whatnot, I have to say that that is not an effective way to communicate. Pretty much the same thing happened with Greg Stein on an earlier thread some months ago about designating maintainers for components. The concerns are legitimate, I’m sure, and we want to keep Spark in line with the Apache Way. And certainly, there have been many times when a project veered off course and needed to corrected. But when we want to make things right, I hope we can do it in a way that respectfully and tactfully engages the community. These “lectures delivered from above” — which is how they come off — are not helpful. Nick On Wed, Apr 22, 2015 at 4:31 PM Ganelin, Ilya ilya.gane...@capitalone.com wrote: As a contributor, I¹ve never felt shut out from the Spark community, nor have I seen any examples of territorial behavior. A few times I¹ve expressed interest in more challenging work and the response I received was generally ³go ahead and give it a shot, just understand that this is sensitive code so we may end up modifying the PR substantially.² Honestly, that seems fine, and in general, I think it¹s completely fair to go with the PR model - e.g. If a JIRA has an open PR then it¹s an active effort, otherwise it¹s fair game unless otherwise stated. At the end of the day, it¹s about moving the project forward and the only way to do that is to have actual code in the pipes -speculation and intent don¹t really help, and there¹s nothing preventing an interested party from submitting a PR against an issue. Thank you, Ilya Ganelin On 4/22/15, 1:25 PM, Mark Hamstra m...@clearstorydata.com wrote: Agreed. The Spark project and community that Vinod describes do not resemble the ones with which I am familiar. On Wed, Apr 22, 2015 at 1:20 PM, Patrick Wendell pwend...@gmail.com wrote: Hi Vinod, Thanks for you thoughts - However, I do not agree with your sentiment and implications. Spark is broadly quite an inclusive project and we spend a lot of effort culturally to help make newcomers feel welcome. - Patrick On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: Actually what this community got away with is pretty much an anti-pattern compared to every other Apache project I have seen. And may I say in a not so Apache way. Waiting for a committer to assign a patch to someone leaves it as a privilege to a committer. Not alluding to anything fishy in practice, but this also leaves a lot of open ground for self-interest. Committers defining notions of good fit / level of experience do not work,
Re: Should we let everyone set Assignee?
Last one for the day. Everyone, as I said clearly, I was not alluding to anything fishy in practice, I was describing how things go wrong in such an environment. Sandy's email lays down some of these problems. Assigning a JIRA in other projects is not a reservation. It is a clear intention of working on design or code. You don't need a new convention of signaling. In almost all other projects, it is assigning tickets - that's how it is used. +Vinod On Apr 22, 2015, at 2:37 PM, Patrick Wendell pwend...@gmail.com wrote: Sandy - I definitely agree with that. We should have a convention of signaling someone intends to work - for instance by commenting on the JIRA and we should document this on the contribution guide. The nice thing about having that convention is that multiple people can say they are going to work on something, whereas only one person can be given the assignee slot on a JIRA. On Wed, Apr 22, 2015 at 2:33 PM, Nicholas Chammas nicholas.cham...@gmail.com wrote: To repeat what Patrick said (literally): If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. No-one in the Spark community dictates who gets to do work. When an issue is assigned to someone in JIRA, it's either because a) they did the work and the issue is now resolved, or b) they are signaling to others that they are working on it. In the case of b), nothing stops other people from working on the issue and it's quite normal for other people to complete issues that were technically assigned to someone else. There is no land grabbing or stalling. Anyone who has contributed to Spark for any amount of time knows this. Vinod, I want to take this opportunity to call out the approach to communication you took here. As a random contributor to Spark and active participant on this list, my reaction when I read your email was this: You do not know how the Spark community actually works. You read a thread that contains some trigger phrases. You wrote a lengthy response as a knee-jerk reaction. I'm not trying to mock, but I want to be direct and honest about how you came off in this thread to me and probably many others. Why not ask questions first--many questions? Why not make doubly sure that you understand the situation correctly before responding? In many ways this is much like filing a bug report. I'm seeing this. It seems wrong to me. Is this expected? I think we all know from experience that this kind of bug report is polite and will likely lead to a productive discussion. On the other hand: You're returning a -1 here? This is obviously wrong! And, boy, lemme tell you how wrong you are!!! No-one likes to deal with bug reports like this. More importantly, they get in the way of fixing the actual problem, if there is one. This is not about the Apache Way or not. It's about basic etiquette and effective communication. I understand that there are legitimate potential concerns here, and it's important that, as an Apache project, Spark work according to Apache principles. But when some person who has never participated on this list pops up out of nowhere with a lengthy lecture on the Apache Way and whatnot, I have to say that that is not an effective way to communicate. Pretty much the same thing happened with Greg Stein on an earlier thread some months ago about designating maintainers for components. The concerns are legitimate, I'm sure, and we want to keep Spark in line with the Apache Way. And certainly, there have been many times when a project veered off course and needed to corrected. But when we want to make things right, I hope we can do it in a way that respectfully and tactfully engages the community. These lectures delivered from above -- which is how they come off -- are not helpful. Nick On Wed, Apr 22, 2015 at 4:31 PM Ganelin, Ilya ilya.gane...@capitalone.com wrote: As a contributor, I¹ve never felt shut out from the Spark community, nor have I seen any examples of territorial behavior. A few times I¹ve expressed interest in more challenging work and the response I received was generally ³go ahead and give it a shot, just understand that this is sensitive code so we may end up modifying the PR substantially.² Honestly, that seems fine, and in general, I think it¹s completely fair to go with the PR model - e.g. If a JIRA has an open PR then it¹s an active effort, otherwise it¹s fair game unless otherwise stated. At the end of the day, it¹s about moving the project forward and the only way to do that is to have actual code in the pipes -speculation and intent don¹t really help, and there¹s nothing preventing an interested party from submitting a PR against an issue. Thank you, Ilya Ganelin
Re: Should we let everyone set Assignee?
I watch these lists, so I have a fair understanding of how things work around here. I don't give direct input in the day to day activities though, like Greg Stein on the other thread, so I can understand if it looks like it came from up above. Apache Members come around and give opinions time to time, you don't need to take it as somebody up above forcing things down. Thanks +Vinod On Apr 22, 2015, at 2:33 PM, Nicholas Chammas nicholas.cham...@gmail.commailto:nicholas.cham...@gmail.com wrote: I want to take this opportunity to call out the approach to communication you took here. As a random contributor to Spark and active participant on this list, my reaction when I read your email was this: * You do not know how the Spark community actually works. * You read a thread that contains some trigger phrases. * You wrote a lengthy response as a knee-jerk reaction. I’m not trying to mock, but I want to be direct and honest about how you came off in this thread to me and probably many others. Why not ask questions first—many questions? Why not make doubly sure that you understand the situation correctly before responding? In many ways this is much like filing a bug report. “I’m seeing this. It seems wrong to me. Is this expected?” I think we all know from experience that this kind of bug report is polite and will likely lead to a productive discussion. On the other hand: “You’re returning a -1 here? This is obviously wrong! And, boy, lemme tell you how wrong you are!!!” No-one likes to deal with bug reports like this. More importantly, they get in the way of fixing the actual problem, if there is one. This is not about the Apache Way or not. It’s about basic etiquette and effective communication. I understand that there are legitimate potential concerns here, and it’s important that, as an Apache project, Spark work according to Apache principles. But when some person who has never participated on this list pops up out of nowhere with a lengthy lecture on the Apache Way and whatnot, I have to say that that is not an effective way to communicate. Pretty much the same thing happened with Greg Stein on an earlier thread some months ago about designating maintainers for components. The concerns are legitimate, I’m sure, and we want to keep Spark in line with the Apache Way. And certainly, there have been many times when a project veered off course and needed to corrected. But when we want to make things right, I hope we can do it in a way that respectfully and tactfully engages the community. These “lectures delivered from above” — which is how they come off — are not helpful. Nick
Re: Should we let everyone set Assignee?
Sandy - I definitely agree with that. We should have a convention of signaling someone intends to work - for instance by commenting on the JIRA and we should document this on the contribution guide. The nice thing about having that convention is that multiple people can say they are going to work on something, whereas only one person can be given the assignee slot on a JIRA. On Wed, Apr 22, 2015 at 2:33 PM, Nicholas Chammas nicholas.cham...@gmail.com wrote: To repeat what Patrick said (literally): If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. No-one in the Spark community dictates who gets to do work. When an issue is assigned to someone in JIRA, it's either because a) they did the work and the issue is now resolved, or b) they are signaling to others that they are working on it. In the case of b), nothing stops other people from working on the issue and it's quite normal for other people to complete issues that were technically assigned to someone else. There is no land grabbing or stalling. Anyone who has contributed to Spark for any amount of time knows this. Vinod, I want to take this opportunity to call out the approach to communication you took here. As a random contributor to Spark and active participant on this list, my reaction when I read your email was this: You do not know how the Spark community actually works. You read a thread that contains some trigger phrases. You wrote a lengthy response as a knee-jerk reaction. I'm not trying to mock, but I want to be direct and honest about how you came off in this thread to me and probably many others. Why not ask questions first--many questions? Why not make doubly sure that you understand the situation correctly before responding? In many ways this is much like filing a bug report. I'm seeing this. It seems wrong to me. Is this expected? I think we all know from experience that this kind of bug report is polite and will likely lead to a productive discussion. On the other hand: You're returning a -1 here? This is obviously wrong! And, boy, lemme tell you how wrong you are!!! No-one likes to deal with bug reports like this. More importantly, they get in the way of fixing the actual problem, if there is one. This is not about the Apache Way or not. It's about basic etiquette and effective communication. I understand that there are legitimate potential concerns here, and it's important that, as an Apache project, Spark work according to Apache principles. But when some person who has never participated on this list pops up out of nowhere with a lengthy lecture on the Apache Way and whatnot, I have to say that that is not an effective way to communicate. Pretty much the same thing happened with Greg Stein on an earlier thread some months ago about designating maintainers for components. The concerns are legitimate, I'm sure, and we want to keep Spark in line with the Apache Way. And certainly, there have been many times when a project veered off course and needed to corrected. But when we want to make things right, I hope we can do it in a way that respectfully and tactfully engages the community. These lectures delivered from above -- which is how they come off -- are not helpful. Nick On Wed, Apr 22, 2015 at 4:31 PM Ganelin, Ilya ilya.gane...@capitalone.com wrote: As a contributor, I¹ve never felt shut out from the Spark community, nor have I seen any examples of territorial behavior. A few times I¹ve expressed interest in more challenging work and the response I received was generally ³go ahead and give it a shot, just understand that this is sensitive code so we may end up modifying the PR substantially.² Honestly, that seems fine, and in general, I think it¹s completely fair to go with the PR model - e.g. If a JIRA has an open PR then it¹s an active effort, otherwise it¹s fair game unless otherwise stated. At the end of the day, it¹s about moving the project forward and the only way to do that is to have actual code in the pipes -speculation and intent don¹t really help, and there¹s nothing preventing an interested party from submitting a PR against an issue. Thank you, Ilya Ganelin On 4/22/15, 1:25 PM, Mark Hamstra m...@clearstorydata.com wrote: Agreed. The Spark project and community that Vinod describes do not resemble the ones with which I am familiar. On Wed, Apr 22, 2015 at 1:20 PM, Patrick Wendell pwend...@gmail.com wrote: Hi Vinod, Thanks for you thoughts - However, I do not agree with your sentiment and implications. Spark is broadly quite an inclusive project and we spend a lot of effort culturally to help make newcomers feel welcome. - Patrick On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar
Re: Should we let everyone set Assignee?
I think one of the benefits of assignee fields that I've seen in other projects is their potential to coordinate and prevent duplicate work. It's really frustrating to put a lot of work into a patch and then find out that someone has been doing the same. It's helpful for the project etiquette to include a way to signal to others that you are working or intend to work on a patch. Obviously there are limits to how long someone should be able to hold on to a JIRA without making progress on it, but a signal is still useful. Historically, in other projects, the assignee field serves as this signal. If we don't want to use the assignee field for this, I think it's important to have some alternative, even if it's just encouraging contributors to comment I'm planning to work on this on JIRA. -Sandy On Wed, Apr 22, 2015 at 1:30 PM, Ganelin, Ilya ilya.gane...@capitalone.com wrote: As a contributor, I¹ve never felt shut out from the Spark community, nor have I seen any examples of territorial behavior. A few times I¹ve expressed interest in more challenging work and the response I received was generally ³go ahead and give it a shot, just understand that this is sensitive code so we may end up modifying the PR substantially.² Honestly, that seems fine, and in general, I think it¹s completely fair to go with the PR model - e.g. If a JIRA has an open PR then it¹s an active effort, otherwise it¹s fair game unless otherwise stated. At the end of the day, it¹s about moving the project forward and the only way to do that is to have actual code in the pipes -speculation and intent don¹t really help, and there¹s nothing preventing an interested party from submitting a PR against an issue. Thank you, Ilya Ganelin On 4/22/15, 1:25 PM, Mark Hamstra m...@clearstorydata.com wrote: Agreed. The Spark project and community that Vinod describes do not resemble the ones with which I am familiar. On Wed, Apr 22, 2015 at 1:20 PM, Patrick Wendell pwend...@gmail.com wrote: Hi Vinod, Thanks for you thoughts - However, I do not agree with your sentiment and implications. Spark is broadly quite an inclusive project and we spend a lot of effort culturally to help make newcomers feel welcome. - Patrick On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: Actually what this community got away with is pretty much an anti-pattern compared to every other Apache project I have seen. And may I say in a not so Apache way. Waiting for a committer to assign a patch to someone leaves it as a privilege to a committer. Not alluding to anything fishy in practice, but this also leaves a lot of open ground for self-interest. Committers defining notions of good fit / level of experience do not work, highly subjective and lead to group control. In terms of semantics, here is what most other projects (dare I say every Apache project?) that I have seen do - A new contributor comes in who is not yet added to the JIRA project. He/she requests one of the project's JIRA admins to add him/her. - After that, he or she is free to assign tickets to themselves. - What this means -- Assigning a ticket to oneself is a signal to the rest of the community that he/she is actively working on the said patch. -- If multiple contributors want to work on the same patch, it needs to resolved amicably through open communication. On JIRA, or on mailing lists. Not by the whim of a committer. - Common issues -- Land grabbing: Other contributors can nudge him/her in case of inactivity and take them over. Again, amicably instead of a committer making subjective decisions. -- Progress stalling: One contributor assigns the ticket to himself/herself is actively debating but with no real code/docs contribution or with any real intention of making progress. Here workable, reviewable code for review usually wins. Assigning patches is not a privilege. Contributors at Apache are a bunch of volunteers, the PMC should let volunteers contribute as they see fit. We do not assign work at Apache. +Vinod On Apr 22, 2015, at 12:32 PM, Patrick Wendell pwend...@gmail.com wrote: One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches
Re: Should we let everyone set Assignee?
I can get behind that point of view too. That's what I've told people who expect Assignee is a necessary part of workflow. The existence of a PR link is a signal someone's working on it. In that case we need not do anything. On Wed, Apr 22, 2015 at 8:32 PM, Patrick Wendell pwend...@gmail.com wrote: One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches for something, provided everyone comments on JIRA saying they are intending to submit a patch, and everyone understands there is duplicate effort. So commenting with an intention to submit a patch, IMO seems like the healthiest workflow since it is non exclusive. To me the main benefit of assigning something ahead of time is if you have a committer that really wants to see someone specific work on a patch, it just acts as a strong signal that there is someone endorsed to work on that patch. That doesn't mean no one else can submit a patch, but it is IMO more of a warning that there may be existing work which is likely to be high quality, to avoid duplicated effort. When it was really easy to assign features to themselves, I saw a lot of anti-patterns in the community that seemed unhealthy, specifically: - It was really unclear what it means semantically if someone is assigned to a JIRA. - People assign JIRA's to themselves that aren't a good fit, given the authors level of experience. - People expect if they assign JIRA's to themselves that others won't submit patches, and become upset if they do. - People are discouraged from working on a patch because someone else was officially assigned. - Patrick On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen so...@cloudera.com wrote: Anecdotally, there are a number of people asking to set the Assignee field. This is currently restricted to Committers in JIRA. I know the logic was to prevent people from Assigning a JIRA and then leaving it; it also matters a bit for questions of credit. Still I wonder if it's best to just let people go ahead and set it, as the lesser evil. People can already do a lot like resolve JIRAs and set shepherd and critical priority and all that. I think the intent was to let Developers set this, but maybe due to an error, that's not how the current JIRA permission is implemented. I ask because I'm about to ping INFRA to update our scheme. - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org
Re: Should we let everyone set Assignee?
Actually what this community got away with is pretty much an anti-pattern compared to every other Apache project I have seen. And may I say in a not so Apache way. Waiting for a committer to assign a patch to someone leaves it as a privilege to a committer. Not alluding to anything fishy in practice, but this also leaves a lot of open ground for self-interest. Committers defining notions of good fit / level of experience do not work, highly subjective and lead to group control. In terms of semantics, here is what most other projects (dare I say every Apache project?) that I have seen do - A new contributor comes in who is not yet added to the JIRA project. He/she requests one of the project's JIRA admins to add him/her. - After that, he or she is free to assign tickets to themselves. - What this means -- Assigning a ticket to oneself is a signal to the rest of the community that he/she is actively working on the said patch. -- If multiple contributors want to work on the same patch, it needs to resolved amicably through open communication. On JIRA, or on mailing lists. Not by the whim of a committer. - Common issues -- Land grabbing: Other contributors can nudge him/her in case of inactivity and take them over. Again, amicably instead of a committer making subjective decisions. -- Progress stalling: One contributor assigns the ticket to himself/herself is actively debating but with no real code/docs contribution or with any real intention of making progress. Here workable, reviewable code for review usually wins. Assigning patches is not a privilege. Contributors at Apache are a bunch of volunteers, the PMC should let volunteers contribute as they see fit. We do not assign work at Apache. +Vinod On Apr 22, 2015, at 12:32 PM, Patrick Wendell pwend...@gmail.com wrote: One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches for something, provided everyone comments on JIRA saying they are intending to submit a patch, and everyone understands there is duplicate effort. So commenting with an intention to submit a patch, IMO seems like the healthiest workflow since it is non exclusive. To me the main benefit of assigning something ahead of time is if you have a committer that really wants to see someone specific work on a patch, it just acts as a strong signal that there is someone endorsed to work on that patch. That doesn't mean no one else can submit a patch, but it is IMO more of a warning that there may be existing work which is likely to be high quality, to avoid duplicated effort. When it was really easy to assign features to themselves, I saw a lot of anti-patterns in the community that seemed unhealthy, specifically: - It was really unclear what it means semantically if someone is assigned to a JIRA. - People assign JIRA's to themselves that aren't a good fit, given the authors level of experience. - People expect if they assign JIRA's to themselves that others won't submit patches, and become upset if they do. - People are discouraged from working on a patch because someone else was officially assigned. - Patrick On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen so...@cloudera.com wrote: Anecdotally, there are a number of people asking to set the Assignee field. This is currently restricted to Committers in JIRA. I know the logic was to prevent people from Assigning a JIRA and then leaving it; it also matters a bit for questions of credit. Still I wonder if it's best to just let people go ahead and set it, as the lesser evil. People can already do a lot like resolve JIRAs and set shepherd and critical priority and all that. I think the intent was to let Developers set this, but maybe due to an error, that's not how the current JIRA permission is implemented. I ask because I'm about to ping INFRA to update our scheme. - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For additional commands, e-mail: dev-h...@spark.apache.org - To unsubscribe,
Re: Should we let everyone set Assignee?
Woh hold on a minute. Spark has been among the projects that are the most welcoming to new contributors. And thanks to this, the sheer number of activities in Spark is much larger than other projects, and our workflow has to accommodate this fact. In practice, people just create pull requests on github, which is a newer friendlier better model given the constraints. We even have tools that automatically tags a ticket with a link to the pull requests. On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: Actually what this community got away with is pretty much an anti-pattern compared to every other Apache project I have seen. And may I say in a not so Apache way. Waiting for a committer to assign a patch to someone leaves it as a privilege to a committer. Not alluding to anything fishy in practice, but this also leaves a lot of open ground for self-interest. Committers defining notions of good fit / level of experience do not work, highly subjective and lead to group control. In terms of semantics, here is what most other projects (dare I say every Apache project?) that I have seen do - A new contributor comes in who is not yet added to the JIRA project. He/she requests one of the project's JIRA admins to add him/her. - After that, he or she is free to assign tickets to themselves. - What this means -- Assigning a ticket to oneself is a signal to the rest of the community that he/she is actively working on the said patch. -- If multiple contributors want to work on the same patch, it needs to resolved amicably through open communication. On JIRA, or on mailing lists. Not by the whim of a committer. - Common issues -- Land grabbing: Other contributors can nudge him/her in case of inactivity and take them over. Again, amicably instead of a committer making subjective decisions. -- Progress stalling: One contributor assigns the ticket to himself/herself is actively debating but with no real code/docs contribution or with any real intention of making progress. Here workable, reviewable code for review usually wins. Assigning patches is not a privilege. Contributors at Apache are a bunch of volunteers, the PMC should let volunteers contribute as they see fit. We do not assign work at Apache. +Vinod On Apr 22, 2015, at 12:32 PM, Patrick Wendell pwend...@gmail.com wrote: One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches for something, provided everyone comments on JIRA saying they are intending to submit a patch, and everyone understands there is duplicate effort. So commenting with an intention to submit a patch, IMO seems like the healthiest workflow since it is non exclusive. To me the main benefit of assigning something ahead of time is if you have a committer that really wants to see someone specific work on a patch, it just acts as a strong signal that there is someone endorsed to work on that patch. That doesn't mean no one else can submit a patch, but it is IMO more of a warning that there may be existing work which is likely to be high quality, to avoid duplicated effort. When it was really easy to assign features to themselves, I saw a lot of anti-patterns in the community that seemed unhealthy, specifically: - It was really unclear what it means semantically if someone is assigned to a JIRA. - People assign JIRA's to themselves that aren't a good fit, given the authors level of experience. - People expect if they assign JIRA's to themselves that others won't submit patches, and become upset if they do. - People are discouraged from working on a patch because someone else was officially assigned. - Patrick On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen so...@cloudera.com wrote: Anecdotally, there are a number of people asking to set the Assignee field. This is currently restricted to Committers in JIRA. I know the logic was to prevent people from Assigning a JIRA and then leaving it; it also matters a bit for questions of credit. Still I wonder if it's best to just let people go ahead and set it, as the lesser evil. People can already do a lot like resolve JIRAs and set shepherd and critical priority and all that. I think the intent was to let Developers set this, but maybe due to an
Re: Should we let everyone set Assignee?
Hi Vinod, Thanks for you thoughts - However, I do not agree with your sentiment and implications. Spark is broadly quite an inclusive project and we spend a lot of effort culturally to help make newcomers feel welcome. - Patrick On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: Actually what this community got away with is pretty much an anti-pattern compared to every other Apache project I have seen. And may I say in a not so Apache way. Waiting for a committer to assign a patch to someone leaves it as a privilege to a committer. Not alluding to anything fishy in practice, but this also leaves a lot of open ground for self-interest. Committers defining notions of good fit / level of experience do not work, highly subjective and lead to group control. In terms of semantics, here is what most other projects (dare I say every Apache project?) that I have seen do - A new contributor comes in who is not yet added to the JIRA project. He/she requests one of the project's JIRA admins to add him/her. - After that, he or she is free to assign tickets to themselves. - What this means -- Assigning a ticket to oneself is a signal to the rest of the community that he/she is actively working on the said patch. -- If multiple contributors want to work on the same patch, it needs to resolved amicably through open communication. On JIRA, or on mailing lists. Not by the whim of a committer. - Common issues -- Land grabbing: Other contributors can nudge him/her in case of inactivity and take them over. Again, amicably instead of a committer making subjective decisions. -- Progress stalling: One contributor assigns the ticket to himself/herself is actively debating but with no real code/docs contribution or with any real intention of making progress. Here workable, reviewable code for review usually wins. Assigning patches is not a privilege. Contributors at Apache are a bunch of volunteers, the PMC should let volunteers contribute as they see fit. We do not assign work at Apache. +Vinod On Apr 22, 2015, at 12:32 PM, Patrick Wendell pwend...@gmail.com wrote: One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches for something, provided everyone comments on JIRA saying they are intending to submit a patch, and everyone understands there is duplicate effort. So commenting with an intention to submit a patch, IMO seems like the healthiest workflow since it is non exclusive. To me the main benefit of assigning something ahead of time is if you have a committer that really wants to see someone specific work on a patch, it just acts as a strong signal that there is someone endorsed to work on that patch. That doesn't mean no one else can submit a patch, but it is IMO more of a warning that there may be existing work which is likely to be high quality, to avoid duplicated effort. When it was really easy to assign features to themselves, I saw a lot of anti-patterns in the community that seemed unhealthy, specifically: - It was really unclear what it means semantically if someone is assigned to a JIRA. - People assign JIRA's to themselves that aren't a good fit, given the authors level of experience. - People expect if they assign JIRA's to themselves that others won't submit patches, and become upset if they do. - People are discouraged from working on a patch because someone else was officially assigned. - Patrick On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen so...@cloudera.com wrote: Anecdotally, there are a number of people asking to set the Assignee field. This is currently restricted to Committers in JIRA. I know the logic was to prevent people from Assigning a JIRA and then leaving it; it also matters a bit for questions of credit. Still I wonder if it's best to just let people go ahead and set it, as the lesser evil. People can already do a lot like resolve JIRAs and set shepherd and critical priority and all that. I think the intent was to let Developers set this, but maybe due to an error, that's not how the current JIRA permission is implemented. I ask because I'm about to ping INFRA to update our scheme. - To unsubscribe, e-mail: dev-unsubscr...@spark.apache.org For
Re: Should we let everyone set Assignee?
Agreed. The Spark project and community that Vinod describes do not resemble the ones with which I am familiar. On Wed, Apr 22, 2015 at 1:20 PM, Patrick Wendell pwend...@gmail.com wrote: Hi Vinod, Thanks for you thoughts - However, I do not agree with your sentiment and implications. Spark is broadly quite an inclusive project and we spend a lot of effort culturally to help make newcomers feel welcome. - Patrick On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: Actually what this community got away with is pretty much an anti-pattern compared to every other Apache project I have seen. And may I say in a not so Apache way. Waiting for a committer to assign a patch to someone leaves it as a privilege to a committer. Not alluding to anything fishy in practice, but this also leaves a lot of open ground for self-interest. Committers defining notions of good fit / level of experience do not work, highly subjective and lead to group control. In terms of semantics, here is what most other projects (dare I say every Apache project?) that I have seen do - A new contributor comes in who is not yet added to the JIRA project. He/she requests one of the project's JIRA admins to add him/her. - After that, he or she is free to assign tickets to themselves. - What this means -- Assigning a ticket to oneself is a signal to the rest of the community that he/she is actively working on the said patch. -- If multiple contributors want to work on the same patch, it needs to resolved amicably through open communication. On JIRA, or on mailing lists. Not by the whim of a committer. - Common issues -- Land grabbing: Other contributors can nudge him/her in case of inactivity and take them over. Again, amicably instead of a committer making subjective decisions. -- Progress stalling: One contributor assigns the ticket to himself/herself is actively debating but with no real code/docs contribution or with any real intention of making progress. Here workable, reviewable code for review usually wins. Assigning patches is not a privilege. Contributors at Apache are a bunch of volunteers, the PMC should let volunteers contribute as they see fit. We do not assign work at Apache. +Vinod On Apr 22, 2015, at 12:32 PM, Patrick Wendell pwend...@gmail.com wrote: One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches for something, provided everyone comments on JIRA saying they are intending to submit a patch, and everyone understands there is duplicate effort. So commenting with an intention to submit a patch, IMO seems like the healthiest workflow since it is non exclusive. To me the main benefit of assigning something ahead of time is if you have a committer that really wants to see someone specific work on a patch, it just acts as a strong signal that there is someone endorsed to work on that patch. That doesn't mean no one else can submit a patch, but it is IMO more of a warning that there may be existing work which is likely to be high quality, to avoid duplicated effort. When it was really easy to assign features to themselves, I saw a lot of anti-patterns in the community that seemed unhealthy, specifically: - It was really unclear what it means semantically if someone is assigned to a JIRA. - People assign JIRA's to themselves that aren't a good fit, given the authors level of experience. - People expect if they assign JIRA's to themselves that others won't submit patches, and become upset if they do. - People are discouraged from working on a patch because someone else was officially assigned. - Patrick On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen so...@cloudera.com wrote: Anecdotally, there are a number of people asking to set the Assignee field. This is currently restricted to Committers in JIRA. I know the logic was to prevent people from Assigning a JIRA and then leaving it; it also matters a bit for questions of credit. Still I wonder if it's best to just let people go ahead and set it, as the lesser evil. People can already do a lot like resolve JIRAs and set shepherd and critical priority and all that. I think the intent was to let Developers set this, but maybe due to an error, that's
Re: Should we let everyone set Assignee?
I think you misread the thread, since that's the opposite of what Patrick suggested. He's suggesting that *nobody ever waits* to be assigned a JIRA to work on it; that anyone may work on a JIRA without waiting for it to be assigned. The point is: assigning JIRAs discourages others from doing work and we don't want to do that. So the pattern so far has been to not use it (except retroactively to credit the major contributor to the resolution.) The cost of this policy is -- oops, maybe you work on something that's already being worked on. That isn't a problem in practice. We already have a way to signal that you're working on a patch: you open a PR. It automatically links to JIRA. Or you can just comment. I suppose you could also use Assignee as a strong signal that your'e working on it, and some people want to do that, and so I was floating the idea of just letting people use it as they like. But I also back the idea of not having a notion of owner of working on a JIRA. On Wed, Apr 22, 2015 at 9:11 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: Actually what this community got away with is pretty much an anti-pattern compared to every other Apache project I have seen. And may I say in a not so Apache way. Waiting for a committer to assign a patch to someone leaves it as a privilege to a committer. Not alluding to anything fishy in practice, but this also leaves a lot of open ground for self-interest. Committers defining notions of good fit / level of experience do not work, highly subjective and lead to group control. In terms of semantics, here is what most other projects (dare I say every Apache project?) that I have seen do - A new contributor comes in who is not yet added to the JIRA project. He/she requests one of the project's JIRA admins to add him/her. - After that, he or she is free to assign tickets to themselves. - What this means -- Assigning a ticket to oneself is a signal to the rest of the community that he/she is actively working on the said patch. -- If multiple contributors want to work on the same patch, it needs to resolved amicably through open communication. On JIRA, or on mailing lists. Not by the whim of a committer. - Common issues -- Land grabbing: Other contributors can nudge him/her in case of inactivity and take them over. Again, amicably instead of a committer making subjective decisions. -- Progress stalling: One contributor assigns the ticket to himself/herself is actively debating but with no real code/docs contribution or with any real intention of making progress. Here workable, reviewable code for review usually wins. Assigning patches is not a privilege. Contributors at Apache are a bunch of volunteers, the PMC should let volunteers contribute as they see fit. We do not assign work at Apache. +Vinod On Apr 22, 2015, at 12:32 PM, Patrick Wendell pwend...@gmail.com wrote: One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches for something, provided everyone comments on JIRA saying they are intending to submit a patch, and everyone understands there is duplicate effort. So commenting with an intention to submit a patch, IMO seems like the healthiest workflow since it is non exclusive. To me the main benefit of assigning something ahead of time is if you have a committer that really wants to see someone specific work on a patch, it just acts as a strong signal that there is someone endorsed to work on that patch. That doesn't mean no one else can submit a patch, but it is IMO more of a warning that there may be existing work which is likely to be high quality, to avoid duplicated effort. When it was really easy to assign features to themselves, I saw a lot of anti-patterns in the community that seemed unhealthy, specifically: - It was really unclear what it means semantically if someone is assigned to a JIRA. - People assign JIRA's to themselves that aren't a good fit, given the authors level of experience. - People expect if they assign JIRA's to themselves that others won't submit patches, and become upset if they do. - People are discouraged from working on a patch because someone else was officially assigned. - Patrick On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen so...@cloudera.com wrote: Anecdotally, there are a number of
Re: Should we let everyone set Assignee?
If it is true what you say, what is the reason for this committer-only-assigns-JIRA tickets policy? If anyone can send a pull request, anyone should be able to assign tickets to himself/herself too. +Vinod On Apr 22, 2015, at 1:18 PM, Reynold Xin r...@databricks.commailto:r...@databricks.com wrote: Woh hold on a minute. Spark has been among the projects that are the most welcoming to new contributors. And thanks to this, the sheer number of activities in Spark is much larger than other projects, and our workflow has to accommodate this fact. In practice, people just create pull requests on github, which is a newer friendlier better model given the constraints. We even have tools that automatically tags a ticket with a link to the pull requests. On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar Vavilapalli vino...@hortonworks.commailto:vino...@hortonworks.com wrote: Actually what this community got away with is pretty much an anti-pattern compared to every other Apache project I have seen. And may I say in a not so Apache way. Waiting for a committer to assign a patch to someone leaves it as a privilege to a committer. Not alluding to anything fishy in practice, but this also leaves a lot of open ground for self-interest. Committers defining notions of good fit / level of experience do not work, highly subjective and lead to group control. In terms of semantics, here is what most other projects (dare I say every Apache project?) that I have seen do - A new contributor comes in who is not yet added to the JIRA project. He/she requests one of the project's JIRA admins to add him/her. - After that, he or she is free to assign tickets to themselves. - What this means -- Assigning a ticket to oneself is a signal to the rest of the community that he/she is actively working on the said patch. -- If multiple contributors want to work on the same patch, it needs to resolved amicably through open communication. On JIRA, or on mailing lists. Not by the whim of a committer. - Common issues -- Land grabbing: Other contributors can nudge him/her in case of inactivity and take them over. Again, amicably instead of a committer making subjective decisions. -- Progress stalling: One contributor assigns the ticket to himself/herself is actively debating but with no real code/docs contribution or with any real intention of making progress. Here workable, reviewable code for review usually wins. Assigning patches is not a privilege. Contributors at Apache are a bunch of volunteers, the PMC should let volunteers contribute as they see fit. We do not assign work at Apache. +Vinod On Apr 22, 2015, at 12:32 PM, Patrick Wendell pwend...@gmail.commailto:pwend...@gmail.com wrote: One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches for something, provided everyone comments on JIRA saying they are intending to submit a patch, and everyone understands there is duplicate effort. So commenting with an intention to submit a patch, IMO seems like the healthiest workflow since it is non exclusive. To me the main benefit of assigning something ahead of time is if you have a committer that really wants to see someone specific work on a patch, it just acts as a strong signal that there is someone endorsed to work on that patch. That doesn't mean no one else can submit a patch, but it is IMO more of a warning that there may be existing work which is likely to be high quality, to avoid duplicated effort. When it was really easy to assign features to themselves, I saw a lot of anti-patterns in the community that seemed unhealthy, specifically: - It was really unclear what it means semantically if someone is assigned to a JIRA. - People assign JIRA's to themselves that aren't a good fit, given the authors level of experience. - People expect if they assign JIRA's to themselves that others won't submit patches, and become upset if they do. - People are discouraged from working on a patch because someone else was officially assigned. - Patrick On Wed, Apr 22, 2015 at 11:13 AM, Sean Owen so...@cloudera.commailto:so...@cloudera.com wrote: Anecdotally, there are a number of people asking to set the Assignee field. This is currently restricted to Committers in JIRA. I know the logic was to prevent people from Assigning a JIRA and
Re: Should we let everyone set Assignee?
As a contributor, I¹ve never felt shut out from the Spark community, nor have I seen any examples of territorial behavior. A few times I¹ve expressed interest in more challenging work and the response I received was generally ³go ahead and give it a shot, just understand that this is sensitive code so we may end up modifying the PR substantially.² Honestly, that seems fine, and in general, I think it¹s completely fair to go with the PR model - e.g. If a JIRA has an open PR then it¹s an active effort, otherwise it¹s fair game unless otherwise stated. At the end of the day, it¹s about moving the project forward and the only way to do that is to have actual code in the pipes -speculation and intent don¹t really help, and there¹s nothing preventing an interested party from submitting a PR against an issue. Thank you, Ilya Ganelin On 4/22/15, 1:25 PM, Mark Hamstra m...@clearstorydata.com wrote: Agreed. The Spark project and community that Vinod describes do not resemble the ones with which I am familiar. On Wed, Apr 22, 2015 at 1:20 PM, Patrick Wendell pwend...@gmail.com wrote: Hi Vinod, Thanks for you thoughts - However, I do not agree with your sentiment and implications. Spark is broadly quite an inclusive project and we spend a lot of effort culturally to help make newcomers feel welcome. - Patrick On Wed, Apr 22, 2015 at 1:11 PM, Vinod Kumar Vavilapalli vino...@hortonworks.com wrote: Actually what this community got away with is pretty much an anti-pattern compared to every other Apache project I have seen. And may I say in a not so Apache way. Waiting for a committer to assign a patch to someone leaves it as a privilege to a committer. Not alluding to anything fishy in practice, but this also leaves a lot of open ground for self-interest. Committers defining notions of good fit / level of experience do not work, highly subjective and lead to group control. In terms of semantics, here is what most other projects (dare I say every Apache project?) that I have seen do - A new contributor comes in who is not yet added to the JIRA project. He/she requests one of the project's JIRA admins to add him/her. - After that, he or she is free to assign tickets to themselves. - What this means -- Assigning a ticket to oneself is a signal to the rest of the community that he/she is actively working on the said patch. -- If multiple contributors want to work on the same patch, it needs to resolved amicably through open communication. On JIRA, or on mailing lists. Not by the whim of a committer. - Common issues -- Land grabbing: Other contributors can nudge him/her in case of inactivity and take them over. Again, amicably instead of a committer making subjective decisions. -- Progress stalling: One contributor assigns the ticket to himself/herself is actively debating but with no real code/docs contribution or with any real intention of making progress. Here workable, reviewable code for review usually wins. Assigning patches is not a privilege. Contributors at Apache are a bunch of volunteers, the PMC should let volunteers contribute as they see fit. We do not assign work at Apache. +Vinod On Apr 22, 2015, at 12:32 PM, Patrick Wendell pwend...@gmail.com wrote: One over arching issue is that it's pretty unclear what Assigned to X in JIAR means from a process perspective. Personally I actually feel it's better for this to be more historical - i.e. who ended up submitting a patch for this feature that was merged - rather than creating an exclusive reservation for a particular user to work on something. If an issue is assigned to person X, but some other person Y submits a great patch for it, I think we have some obligation to Spark users and to the community to merge the better patch. So the idea of reserving the right to add a feature, it just seems overall off to me. IMO, its fine if multiple people want to submit competing patches for something, provided everyone comments on JIRA saying they are intending to submit a patch, and everyone understands there is duplicate effort. So commenting with an intention to submit a patch, IMO seems like the healthiest workflow since it is non exclusive. To me the main benefit of assigning something ahead of time is if you have a committer that really wants to see someone specific work on a patch, it just acts as a strong signal that there is someone endorsed to work on that patch. That doesn't mean no one else can submit a patch, but it is IMO more of a warning that there may be existing work which is likely to be high quality, to avoid duplicated effort. When it was really easy to assign features to themselves, I saw a lot of anti-patterns in the community that seemed unhealthy, specifically: - It was really unclear what it means semantically if someone is assigned to a JIRA. - People assign JIRA's to themselves that
