Re: [DISCUSS] assignee practice on committers+ (possible issue on preemption)
I agree, Assignee has been used primarily to give recognition to the contributor who ended up submitting the patch which got merged. Typically jira's remain unassigned - even if it were to be assigned, it conveys no meaning or ownership or ongoing work : IMO it is equivalent to an unassigned jira. There could ofcourse be discussions on dev@ or comments in the jira or design docs or WIP PR"s - but if a better approach comes along, or previous work stalls - contributors can (and please, must !) contribute to the jira. Ofcourse, if there is active work going on as a PR under review or SPIP/proposal being discussed - taking part in that process would help imo. Regards, Mridul On Thu, Feb 18, 2021 at 11:00 PM Sean Owen wrote: > I don't believe Assignee has ever been used for anything except to give a > bit of informal credit to the person who drove most of the work on the > issue, when it's resolved. > If that's the question - does Assignee mean only that person can work on > the issue? then no, it has never meant that. > > You say you have an example, one that was resolved. Is this a single case > or systemic? I don't think I recall seeing problems of this form. > > We _have_ had multiple incompatible PRs for a JIRA before, occasionally. > We have also definitely had people file huge umbrella JIRAs, parts of > which _nobody_ ever completes, but, for lack of any interest from the filer > or anyone else. > > I think it's fair to give a person a reasonable shot at producing a > solution if they propose a problem or feature. > We have had instances where a new contributor files a relatively simple > issue, and finds another contributor opened the obvious PR before they had > a chance (maybe they needed a day to get the PR together). That seemed a > bit discourteous. > > If you need a solution as well, and one isn't forthcoming, just open a PR > and propose your own? I don't hear that anyone told you not to, but I also > don't know what this is about. You can always propose a PR as an > alternative to compare with, to facilitate collaboration. Nothing wrong > with that. > > On Thu, Feb 18, 2021 at 10:45 PM Jungtaek Lim < > kabhwan.opensou...@gmail.com> wrote: > >> (Actually the real world case was fixed somehow and I wouldn't like to >> point out a fixed one. I just would like to make sure what I think is >> correct and is considered as "consensus".) >> >> Just consider the case as simple - someone files two different JIRA >> issues for new features and assigns to him/herself altogether, without >> sharing anything about the ongoing efforts someone has made. (So you have >> no idea even someone just files two different JIRA issues without "any" >> progress and has them in a backlog.) The new features are not new and are >> likely something others could work in parallel. >> >> That said, committers can explicitly represent "I'm working on this so >> please refrain from making redundant efforts." via assigning the issue, >> which is actually similar to the comment "I'm working on this". >> Unfortunately, this works only when the feature is something one who filed >> a JIRA issue works uniquely. Occasional opposite cases aren't always a >> notion of ignoring the signal of "I'm working on this". There're also >> coincidences two different individuals/teams are working on exactly the >> same at the same time. >> >> My concern is that "assignment" might be considered pretty much stronger >> than just commenting "I'm working on this" - it's like "Regardless of your >> current progress, I started working on this so don't consider your effort >> to be proposable. You should have filed the JIRA issue before I file one." >> Is it possible for contributors to do the same? I guess not. >> >> The other problem is the multiple assignments in parallel. I wouldn't >> like to guess someone over-uses the power of assignments, but technically >> it's simply possible that someone can file JIRA issues on his/her backlog >> which can be done in a couple of months or so with assigning to >> him/herself, which effectively blocks others from working or proposing the >> same. I consider this as preemptive which sounds bad and even unfair. >> >> On Fri, Feb 19, 2021 at 12:14 AM Sean Owen wrote: >> >>> I think it's OK to raise particular instances. It's hard for me to >>> evaluate further in the abstract. >>> >>> I don't think we use Assignee much at all, except to kinda give credit >>> when something is done. No piece of code or work can be solely owned by one >>> person; this is just ASF policy. >>> >>> I think we've seen the occasional opposite case too: someone starts >>> working on an issue, and then someone else also starts working on it with a >>> competing fix or change. >>> >>> These are ultimately issues of communication. If an issue is pretty >>> stalled, and you have a proposal, nothing wrong with just going ahead with >>> a proposal. There may be no disagreement. It might result in the >>> other person joining your PR. As
Re: [DISCUSS] assignee practice on committers+ (possible issue on preemption)
I don't believe Assignee has ever been used for anything except to give a bit of informal credit to the person who drove most of the work on the issue, when it's resolved. If that's the question - does Assignee mean only that person can work on the issue? then no, it has never meant that. You say you have an example, one that was resolved. Is this a single case or systemic? I don't think I recall seeing problems of this form. We _have_ had multiple incompatible PRs for a JIRA before, occasionally. We have also definitely had people file huge umbrella JIRAs, parts of which _nobody_ ever completes, but, for lack of any interest from the filer or anyone else. I think it's fair to give a person a reasonable shot at producing a solution if they propose a problem or feature. We have had instances where a new contributor files a relatively simple issue, and finds another contributor opened the obvious PR before they had a chance (maybe they needed a day to get the PR together). That seemed a bit discourteous. If you need a solution as well, and one isn't forthcoming, just open a PR and propose your own? I don't hear that anyone told you not to, but I also don't know what this is about. You can always propose a PR as an alternative to compare with, to facilitate collaboration. Nothing wrong with that. On Thu, Feb 18, 2021 at 10:45 PM Jungtaek Lim wrote: > (Actually the real world case was fixed somehow and I wouldn't like to > point out a fixed one. I just would like to make sure what I think is > correct and is considered as "consensus".) > > Just consider the case as simple - someone files two different JIRA issues > for new features and assigns to him/herself altogether, without sharing > anything about the ongoing efforts someone has made. (So you have no idea > even someone just files two different JIRA issues without "any" progress > and has them in a backlog.) The new features are not new and are likely > something others could work in parallel. > > That said, committers can explicitly represent "I'm working on this so > please refrain from making redundant efforts." via assigning the issue, > which is actually similar to the comment "I'm working on this". > Unfortunately, this works only when the feature is something one who filed > a JIRA issue works uniquely. Occasional opposite cases aren't always a > notion of ignoring the signal of "I'm working on this". There're also > coincidences two different individuals/teams are working on exactly the > same at the same time. > > My concern is that "assignment" might be considered pretty much stronger > than just commenting "I'm working on this" - it's like "Regardless of your > current progress, I started working on this so don't consider your effort > to be proposable. You should have filed the JIRA issue before I file one." > Is it possible for contributors to do the same? I guess not. > > The other problem is the multiple assignments in parallel. I wouldn't like > to guess someone over-uses the power of assignments, but technically it's > simply possible that someone can file JIRA issues on his/her backlog which > can be done in a couple of months or so with assigning to him/herself, > which effectively blocks others from working or proposing the same. I > consider this as preemptive which sounds bad and even unfair. > > On Fri, Feb 19, 2021 at 12:14 AM Sean Owen wrote: > >> I think it's OK to raise particular instances. It's hard for me to >> evaluate further in the abstract. >> >> I don't think we use Assignee much at all, except to kinda give credit >> when something is done. No piece of code or work can be solely owned by one >> person; this is just ASF policy. >> >> I think we've seen the occasional opposite case too: someone starts >> working on an issue, and then someone else also starts working on it with a >> competing fix or change. >> >> These are ultimately issues of communication. If an issue is pretty >> stalled, and you have a proposal, nothing wrong with just going ahead with >> a proposal. There may be no disagreement. It might result in the >> other person joining your PR. As I say, not sure if there's a deeper issue >> than that if even this hasn't been tried? >> >> On Mon, Feb 15, 2021 at 8:35 PM Jungtaek Lim < >> kabhwan.opensou...@gmail.com> wrote: >> >>> Thanks for the input, Hyukjin! >>> >>> I have been keeping my own policy among all discussions I have raised - >>> I would provide the hypothetical example closer to the actual one and avoid >>> pointing out directly. The main purpose of the discussion is to ensure our >>> policy / consensus makes sense, no more. I can provide a more detailed >>> explanation if someone feels the explanation wasn't sufficient to >>> understand. >>> >>> Probably this discussion could play as a "reminder" to every committers >>> if similar discussion was raised before and it succeeded to build >>> consensus. If there's some point we don't build consensus yet, it'd be a >>> good time to discuss fu
Re: [DISCUSS] assignee practice on committers+ (possible issue on preemption)
(Actually the real world case was fixed somehow and I wouldn't like to point out a fixed one. I just would like to make sure what I think is correct and is considered as "consensus".) Just consider the case as simple - someone files two different JIRA issues for new features and assigns to him/herself altogether, without sharing anything about the ongoing efforts someone has made. (So you have no idea even someone just files two different JIRA issues without "any" progress and has them in a backlog.) The new features are not new and are likely something others could work in parallel. That said, committers can explicitly represent "I'm working on this so please refrain from making redundant efforts." via assigning the issue, which is actually similar to the comment "I'm working on this". Unfortunately, this works only when the feature is something one who filed a JIRA issue works uniquely. Occasional opposite cases aren't always a notion of ignoring the signal of "I'm working on this". There're also coincidences two different individuals/teams are working on exactly the same at the same time. My concern is that "assignment" might be considered pretty much stronger than just commenting "I'm working on this" - it's like "Regardless of your current progress, I started working on this so don't consider your effort to be proposable. You should have filed the JIRA issue before I file one." Is it possible for contributors to do the same? I guess not. The other problem is the multiple assignments in parallel. I wouldn't like to guess someone over-uses the power of assignments, but technically it's simply possible that someone can file JIRA issues on his/her backlog which can be done in a couple of months or so with assigning to him/herself, which effectively blocks others from working or proposing the same. I consider this as preemptive which sounds bad and even unfair. On Fri, Feb 19, 2021 at 12:14 AM Sean Owen wrote: > I think it's OK to raise particular instances. It's hard for me to > evaluate further in the abstract. > > I don't think we use Assignee much at all, except to kinda give credit > when something is done. No piece of code or work can be solely owned by one > person; this is just ASF policy. > > I think we've seen the occasional opposite case too: someone starts > working on an issue, and then someone else also starts working on it with a > competing fix or change. > > These are ultimately issues of communication. If an issue is pretty > stalled, and you have a proposal, nothing wrong with just going ahead with > a proposal. There may be no disagreement. It might result in the > other person joining your PR. As I say, not sure if there's a deeper issue > than that if even this hasn't been tried? > > On Mon, Feb 15, 2021 at 8:35 PM Jungtaek Lim > wrote: > >> Thanks for the input, Hyukjin! >> >> I have been keeping my own policy among all discussions I have raised - I >> would provide the hypothetical example closer to the actual one and avoid >> pointing out directly. The main purpose of the discussion is to ensure our >> policy / consensus makes sense, no more. I can provide a more detailed >> explanation if someone feels the explanation wasn't sufficient to >> understand. >> >> Probably this discussion could play as a "reminder" to every committers >> if similar discussion was raised before and it succeeded to build >> consensus. If there's some point we don't build consensus yet, it'd be a >> good time to discuss further. I don't know what exactly was the discussion >> and the result so what is new here, but I guess this might be a duplicated >> one as you say similar issue. >> >> >> >> On Tue, Feb 16, 2021 at 11:09 AM Hyukjin Kwon >> wrote: >> >>> I remember I raised a similar issue a long time ago in the dev mailing >>> list. I agree that setting no assignee makes sense in most of the cases, >>> and also think we share similar thoughts about the assignee on >>> umbrella JIRAs, followup tasks, the case when it's clear with a design doc, >>> etc. >>> It makes me think that the actual issue by setting an assignee happens >>> rarely, and it is an issue to several specific cases that would need a look >>> case-by-case. >>> Were there specific cases that made you concerned? >>> >>> >>> 2021년 2월 15일 (월) 오전 8:58, Jungtaek Lim 님이 >>> 작성: >>> Hi devs, I'd like to raise a discussion and hear voices on the "assignee" practice on committers which may lead issues on preemption. I feel this is the one of major unfairnesses between contributors and committers if used improperly, especially when someone assigns themselves with multiple JIRA issues. Let's say there're features A and B, which may take a month for each (or require design doc) - both are individual major features, not subtasks or some sort of "follow-up". Technically, committers can file two JIRA issues and assign both of issues, "without actually doing no progress",
Re: [DISCUSS] assignee practice on committers+ (possible issue on preemption)
I think it's OK to raise particular instances. It's hard for me to evaluate further in the abstract. I don't think we use Assignee much at all, except to kinda give credit when something is done. No piece of code or work can be solely owned by one person; this is just ASF policy. I think we've seen the occasional opposite case too: someone starts working on an issue, and then someone else also starts working on it with a competing fix or change. These are ultimately issues of communication. If an issue is pretty stalled, and you have a proposal, nothing wrong with just going ahead with a proposal. There may be no disagreement. It might result in the other person joining your PR. As I say, not sure if there's a deeper issue than that if even this hasn't been tried? On Mon, Feb 15, 2021 at 8:35 PM Jungtaek Lim wrote: > Thanks for the input, Hyukjin! > > I have been keeping my own policy among all discussions I have raised - I > would provide the hypothetical example closer to the actual one and avoid > pointing out directly. The main purpose of the discussion is to ensure our > policy / consensus makes sense, no more. I can provide a more detailed > explanation if someone feels the explanation wasn't sufficient to > understand. > > Probably this discussion could play as a "reminder" to every committers if > similar discussion was raised before and it succeeded to build consensus. > If there's some point we don't build consensus yet, it'd be a good time to > discuss further. I don't know what exactly was the discussion and the > result so what is new here, but I guess this might be a duplicated one as > you say similar issue. > > > > On Tue, Feb 16, 2021 at 11:09 AM Hyukjin Kwon wrote: > >> I remember I raised a similar issue a long time ago in the dev mailing >> list. I agree that setting no assignee makes sense in most of the cases, >> and also think we share similar thoughts about the assignee on >> umbrella JIRAs, followup tasks, the case when it's clear with a design doc, >> etc. >> It makes me think that the actual issue by setting an assignee happens >> rarely, and it is an issue to several specific cases that would need a look >> case-by-case. >> Were there specific cases that made you concerned? >> >> >> 2021년 2월 15일 (월) 오전 8:58, Jungtaek Lim 님이 >> 작성: >> >>> Hi devs, >>> >>> I'd like to raise a discussion and hear voices on the "assignee" >>> practice on committers which may lead issues on preemption. >>> >>> I feel this is the one of major unfairnesses between contributors and >>> committers if used improperly, especially when someone assigns themselves >>> with multiple JIRA issues. >>> >>> Let's say there're features A and B, which may take a month for each (or >>> require design doc) - both are individual major features, not subtasks or >>> some sort of "follow-up". >>> >>> Technically, committers can file two JIRA issues and assign both of >>> issues, "without actually doing no progress", and implicitly ensure no one >>> works on these issues for a couple of months. Even just a plan on backlog >>> can prevent others from taking up. >>> >>> I don't think this is fair with contributors, because contributors don't >>> tend to file an JIRA issue unless they made a lot of progress. (I'd like to >>> remind you, competition from contributor's position is quite tense and >>> stressful.) Say they already spent a month working on it and testing it in >>> production. They feel ready and visit JIRA, and realize the JIRA issue was >>> made and assigned to someone, while there's no progress on the JIRA issue. >>> No idea how much progress "someone" makes. They "might" ask about the >>> progress, but nothing will change if "someone" simply says "I'm still >>> working on this" (with even 1% of progress). Isn't this actually against >>> the reason we don't allow setting assignee to contributor? >>> >>> For sure, assigning the issue would make sense if the issue is a subtask >>> or follow-up, or the issue made explicit progress like design doc is being >>> put. In other cases I don't see any reason assigning the issue explicitly. >>> Someone may say to contributors, just leave a comment "I'm working on it", >>> but isn't it also something committers can also do when they are "actually" >>> working? >>> >>> I think committers should have no advantage on the possible competition >>> on contribution, and setting assignee without explicit progress makes me >>> worried. >>> To make it fair, either we should allow contributors to assign them or >>> don't allow committers to assign them unless extreme cases - they can still >>> use the approach contributors do. >>> (Again I'd feel OK to assign if there's a design doc proving that they >>> really spent non-trivial effort already. My point is preempting JIRA issues >>> with only sketched ideas or even just rationalizations.) >>> >>> Would like to hear everyone's voices. >>> >>> Thanks, >>> Jungtaek Lim (HeartSaVioR) >>> >>> ps. better yet, probably it's better the
Re: [DISCUSS] assignee practice on committers+ (possible issue on preemption)
Thanks for the input, Hyukjin! I have been keeping my own policy among all discussions I have raised - I would provide the hypothetical example closer to the actual one and avoid pointing out directly. The main purpose of the discussion is to ensure our policy / consensus makes sense, no more. I can provide a more detailed explanation if someone feels the explanation wasn't sufficient to understand. Probably this discussion could play as a "reminder" to every committers if similar discussion was raised before and it succeeded to build consensus. If there's some point we don't build consensus yet, it'd be a good time to discuss further. I don't know what exactly was the discussion and the result so what is new here, but I guess this might be a duplicated one as you say similar issue. On Tue, Feb 16, 2021 at 11:09 AM Hyukjin Kwon wrote: > I remember I raised a similar issue a long time ago in the dev mailing > list. I agree that setting no assignee makes sense in most of the cases, > and also think we share similar thoughts about the assignee on > umbrella JIRAs, followup tasks, the case when it's clear with a design doc, > etc. > It makes me think that the actual issue by setting an assignee happens > rarely, and it is an issue to several specific cases that would need a look > case-by-case. > Were there specific cases that made you concerned? > > > 2021년 2월 15일 (월) 오전 8:58, Jungtaek Lim 님이 > 작성: > >> Hi devs, >> >> I'd like to raise a discussion and hear voices on the "assignee" practice >> on committers which may lead issues on preemption. >> >> I feel this is the one of major unfairnesses between contributors and >> committers if used improperly, especially when someone assigns themselves >> with multiple JIRA issues. >> >> Let's say there're features A and B, which may take a month for each (or >> require design doc) - both are individual major features, not subtasks or >> some sort of "follow-up". >> >> Technically, committers can file two JIRA issues and assign both of >> issues, "without actually doing no progress", and implicitly ensure no one >> works on these issues for a couple of months. Even just a plan on backlog >> can prevent others from taking up. >> >> I don't think this is fair with contributors, because contributors don't >> tend to file an JIRA issue unless they made a lot of progress. (I'd like to >> remind you, competition from contributor's position is quite tense and >> stressful.) Say they already spent a month working on it and testing it in >> production. They feel ready and visit JIRA, and realize the JIRA issue was >> made and assigned to someone, while there's no progress on the JIRA issue. >> No idea how much progress "someone" makes. They "might" ask about the >> progress, but nothing will change if "someone" simply says "I'm still >> working on this" (with even 1% of progress). Isn't this actually against >> the reason we don't allow setting assignee to contributor? >> >> For sure, assigning the issue would make sense if the issue is a subtask >> or follow-up, or the issue made explicit progress like design doc is being >> put. In other cases I don't see any reason assigning the issue explicitly. >> Someone may say to contributors, just leave a comment "I'm working on it", >> but isn't it also something committers can also do when they are "actually" >> working? >> >> I think committers should have no advantage on the possible competition >> on contribution, and setting assignee without explicit progress makes me >> worried. >> To make it fair, either we should allow contributors to assign them or >> don't allow committers to assign them unless extreme cases - they can still >> use the approach contributors do. >> (Again I'd feel OK to assign if there's a design doc proving that they >> really spent non-trivial effort already. My point is preempting JIRA issues >> with only sketched ideas or even just rationalizations.) >> >> Would like to hear everyone's voices. >> >> Thanks, >> Jungtaek Lim (HeartSaVioR) >> >> ps. better yet, probably it's better then to restrict something >> explicitly if we sincerely respect the underlying culture on the statement >> "In case several people contributed, prefer to assign to the more ‘junior’, >> non-committer contributor". >> >> >>
Re: [DISCUSS] assignee practice on committers+ (possible issue on preemption)
I remember I raised a similar issue a long time ago in the dev mailing list. I agree that setting no assignee makes sense in most of the cases, and also think we share similar thoughts about the assignee on umbrella JIRAs, followup tasks, the case when it's clear with a design doc, etc. It makes me think that the actual issue by setting an assignee happens rarely, and it is an issue to several specific cases that would need a look case-by-case. Were there specific cases that made you concerned? 2021년 2월 15일 (월) 오전 8:58, Jungtaek Lim 님이 작성: > Hi devs, > > I'd like to raise a discussion and hear voices on the "assignee" practice > on committers which may lead issues on preemption. > > I feel this is the one of major unfairnesses between contributors and > committers if used improperly, especially when someone assigns themselves > with multiple JIRA issues. > > Let's say there're features A and B, which may take a month for each (or > require design doc) - both are individual major features, not subtasks or > some sort of "follow-up". > > Technically, committers can file two JIRA issues and assign both of > issues, "without actually doing no progress", and implicitly ensure no one > works on these issues for a couple of months. Even just a plan on backlog > can prevent others from taking up. > > I don't think this is fair with contributors, because contributors don't > tend to file an JIRA issue unless they made a lot of progress. (I'd like to > remind you, competition from contributor's position is quite tense and > stressful.) Say they already spent a month working on it and testing it in > production. They feel ready and visit JIRA, and realize the JIRA issue was > made and assigned to someone, while there's no progress on the JIRA issue. > No idea how much progress "someone" makes. They "might" ask about the > progress, but nothing will change if "someone" simply says "I'm still > working on this" (with even 1% of progress). Isn't this actually against > the reason we don't allow setting assignee to contributor? > > For sure, assigning the issue would make sense if the issue is a subtask > or follow-up, or the issue made explicit progress like design doc is being > put. In other cases I don't see any reason assigning the issue explicitly. > Someone may say to contributors, just leave a comment "I'm working on it", > but isn't it also something committers can also do when they are "actually" > working? > > I think committers should have no advantage on the possible competition on > contribution, and setting assignee without explicit progress makes me > worried. > To make it fair, either we should allow contributors to assign them or > don't allow committers to assign them unless extreme cases - they can still > use the approach contributors do. > (Again I'd feel OK to assign if there's a design doc proving that they > really spent non-trivial effort already. My point is preempting JIRA issues > with only sketched ideas or even just rationalizations.) > > Would like to hear everyone's voices. > > Thanks, > Jungtaek Lim (HeartSaVioR) > > ps. better yet, probably it's better then to restrict something explicitly > if we sincerely respect the underlying culture on the statement "In case > several people contributed, prefer to assign to the more ‘junior’, > non-committer contributor". > > >
[DISCUSS] assignee practice on committers+ (possible issue on preemption)
Hi devs, I'd like to raise a discussion and hear voices on the "assignee" practice on committers which may lead issues on preemption. I feel this is the one of major unfairnesses between contributors and committers if used improperly, especially when someone assigns themselves with multiple JIRA issues. Let's say there're features A and B, which may take a month for each (or require design doc) - both are individual major features, not subtasks or some sort of "follow-up". Technically, committers can file two JIRA issues and assign both of issues, "without actually doing no progress", and implicitly ensure no one works on these issues for a couple of months. Even just a plan on backlog can prevent others from taking up. I don't think this is fair with contributors, because contributors don't tend to file an JIRA issue unless they made a lot of progress. (I'd like to remind you, competition from contributor's position is quite tense and stressful.) Say they already spent a month working on it and testing it in production. They feel ready and visit JIRA, and realize the JIRA issue was made and assigned to someone, while there's no progress on the JIRA issue. No idea how much progress "someone" makes. They "might" ask about the progress, but nothing will change if "someone" simply says "I'm still working on this" (with even 1% of progress). Isn't this actually against the reason we don't allow setting assignee to contributor? For sure, assigning the issue would make sense if the issue is a subtask or follow-up, or the issue made explicit progress like design doc is being put. In other cases I don't see any reason assigning the issue explicitly. Someone may say to contributors, just leave a comment "I'm working on it", but isn't it also something committers can also do when they are "actually" working? I think committers should have no advantage on the possible competition on contribution, and setting assignee without explicit progress makes me worried. To make it fair, either we should allow contributors to assign them or don't allow committers to assign them unless extreme cases - they can still use the approach contributors do. (Again I'd feel OK to assign if there's a design doc proving that they really spent non-trivial effort already. My point is preempting JIRA issues with only sketched ideas or even just rationalizations.) Would like to hear everyone's voices. Thanks, Jungtaek Lim (HeartSaVioR) ps. better yet, probably it's better then to restrict something explicitly if we sincerely respect the underlying culture on the statement "In case several people contributed, prefer to assign to the more ‘junior’, non-committer contributor".
