Re: [Discuss] New feature work approval state in Geode project?
> On May 28, 2021, at 3:45 PM, Kirk Lund wrote: > > Another thought I have is that if the "fix" for a bug will require any sort > of new User API or configuration properties (ie gemfire.properties), then > we should always treat that as a new feature that requires going through > our RFC process for a new feature. I think this is a good distinction of when a bug fix really becomes something different. -Jake
Re: [Discuss] New feature work approval state in Geode project?
Anil's thoughts parallel what I was trying to describe as well... On Fri, May 28, 2021 at 2:35 PM Anilkumar Gingade wrote: > My thoughts; I can't make distinction between feature or bug; it’s a > change to the codebase, if it has greater impact, is sensitive and takes > time to build; then it is a candidate to bring it up and talk about it > before implementation. Sometime its hard to determine/distinguish it, we > developer should make a good judgement of it and be open for any > suggestion. Currently we have a RFC process; adding more process/steps adds > additional onus; we can tweak RFC process or replace it with better option > but let's keep it simple/minimal. > > > On 5/28/21, 11:57 AM, "Jacob Barrett" wrote: > > > > > On May 28, 2021, at 11:24 AM, Mark Hanson > wrote: > > > > I think the key difference between what Bill and Jake are saying is > that Bill is saying a new feature needs approval in a more structured way. > I think Bill's process is open the jira, then it is "approved" or "won't > do" then work starts. I think what Jake is saying is a little less > structured. That may be my reading though. > > The difference is between bugs vs features. We have a process for > features, lazy consensus on RFCs. We have a process for minor > features/improvements/tasks, greedy concensus on PR approvals. > > -Jake > > >
Re: [Discuss] New feature work approval state in Geode project?
Another thought I have is that if the "fix" for a bug will require any sort of new User API or configuration properties (ie gemfire.properties), then we should always treat that as a new feature that requires going through our RFC process for a new feature. On Fri, May 28, 2021 at 2:42 PM Kirk Lund wrote: > I think the main problem this discussion thread could solve is when a > developer files a Jira ticket as a bug, assigns it to themselves, and > begins work on it. After some time (possibly even a month or something > significant like that), they submit a PR to fix the ticket, only to find > out from multiple reviewers that the community believes it is not a bug and > rejects the PR while declaring that the bug isn't even a bug. The ticket is > then closed as "will not fix" and the contributor is thoroughly demoralized > (I would be). > > This community does seem to be lacking any sort of process for reviewing > and triaging bugs unless the filer of the ticket were to discuss it on the > dev-list after filing it but before coding starts. > > So, for bugs, this community could recommend optional discussion of > newly filed bugs on the dev-list before beginning work on it to ensure that > the majority don’t later disagree that it’s a bug during PR review. This > would save the contributor a lot of wasted effort, or they might even be > able to convince others that it is indeed a bug before starting work on it. > > -Kirk > > On Fri, May 28, 2021 at 11:14 AM Jacob Barrett > wrote: > >> >> >> > On May 28, 2021, at 10:48 AM, Bill Burcham >> wrote: >> > >> > A google search for "most successful open source project" lists Apache >> > Cassandra at the top. When a bug is submitted to the Cassandra Jira it >> > starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to >> the >> > OPEN state which is described as: >> > >> > | "the issue is open and ready for the assignee to start work on it." >> > >> > I think introducing a starting state like TRIAGE NEEDED in the Geode >> Jira >> > system, and instituting a (gating) triage process would be a good way to >> > keep the Geode architecture cohesive and also to maximize the impact of >> our >> > contributor's efforts. >> >> >> I think this is very different from what this thread was initially asking >> for. An “approved” state is very different in my book than a bug needing >> more info, “triage” state. I would definitely agree with this change to add >> a “needs info”/“triage” state to bugs. It fits my previous statement that a >> ticket is opened when there is reasonable belief work needs to be done. In >> this case the initial work is to fully understand the issue. The next step >> is to progress to fixing or closed. >> >> -Jake >> >>
Re: [Discuss] New feature work approval state in Geode project?
I think the main problem this discussion thread could solve is when a developer files a Jira ticket as a bug, assigns it to themselves, and begins work on it. After some time (possibly even a month or something significant like that), they submit a PR to fix the ticket, only to find out from multiple reviewers that the community believes it is not a bug and rejects the PR while declaring that the bug isn't even a bug. The ticket is then closed as "will not fix" and the contributor is thoroughly demoralized (I would be). This community does seem to be lacking any sort of process for reviewing and triaging bugs unless the filer of the ticket were to discuss it on the dev-list after filing it but before coding starts. So, for bugs, this community could recommend optional discussion of newly filed bugs on the dev-list before beginning work on it to ensure that the majority don’t later disagree that it’s a bug during PR review. This would save the contributor a lot of wasted effort, or they might even be able to convince others that it is indeed a bug before starting work on it. -Kirk On Fri, May 28, 2021 at 11:14 AM Jacob Barrett wrote: > > > > On May 28, 2021, at 10:48 AM, Bill Burcham > wrote: > > > > A google search for "most successful open source project" lists Apache > > Cassandra at the top. When a bug is submitted to the Cassandra Jira it > > starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to > the > > OPEN state which is described as: > > > > | "the issue is open and ready for the assignee to start work on it." > > > > I think introducing a starting state like TRIAGE NEEDED in the Geode Jira > > system, and instituting a (gating) triage process would be a good way to > > keep the Geode architecture cohesive and also to maximize the impact of > our > > contributor's efforts. > > > I think this is very different from what this thread was initially asking > for. An “approved” state is very different in my book than a bug needing > more info, “triage” state. I would definitely agree with this change to add > a “needs info”/“triage” state to bugs. It fits my previous statement that a > ticket is opened when there is reasonable belief work needs to be done. In > this case the initial work is to fully understand the issue. The next step > is to progress to fixing or closed. > > -Jake > >
Re: [Discuss] New feature work approval state in Geode project?
My thoughts; I can't make distinction between feature or bug; it’s a change to the codebase, if it has greater impact, is sensitive and takes time to build; then it is a candidate to bring it up and talk about it before implementation. Sometime its hard to determine/distinguish it, we developer should make a good judgement of it and be open for any suggestion. Currently we have a RFC process; adding more process/steps adds additional onus; we can tweak RFC process or replace it with better option but let's keep it simple/minimal. On 5/28/21, 11:57 AM, "Jacob Barrett" wrote: > On May 28, 2021, at 11:24 AM, Mark Hanson wrote: > > I think the key difference between what Bill and Jake are saying is that Bill is saying a new feature needs approval in a more structured way. I think Bill's process is open the jira, then it is "approved" or "won't do" then work starts. I think what Jake is saying is a little less structured. That may be my reading though. The difference is between bugs vs features. We have a process for features, lazy consensus on RFCs. We have a process for minor features/improvements/tasks, greedy concensus on PR approvals. -Jake
Re: [Discuss] New feature work approval state in Geode project?
> On May 28, 2021, at 11:24 AM, Mark Hanson wrote: > > I think the key difference between what Bill and Jake are saying is that Bill > is saying a new feature needs approval in a more structured way. I think > Bill's process is open the jira, then it is "approved" or "won't do" then > work starts. I think what Jake is saying is a little less structured. That > may be my reading though. The difference is between bugs vs features. We have a process for features, lazy consensus on RFCs. We have a process for minor features/improvements/tasks, greedy concensus on PR approvals. -Jake
Re: [Discuss] New feature work approval state in Geode project?
I think the key difference between what Bill and Jake are saying is that Bill is saying a new feature needs approval in a more structured way. I think Bill's process is open the jira, then it is "approved" or "won't do" then work starts. I think what Jake is saying is a little less structured. That may be my reading though. On 5/28/21, 11:14 AM, "Jacob Barrett" wrote: > On May 28, 2021, at 10:48 AM, Bill Burcham wrote: > > A google search for "most successful open source project" lists Apache > Cassandra at the top. When a bug is submitted to the Cassandra Jira it > starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the > OPEN state which is described as: > > | "the issue is open and ready for the assignee to start work on it." > > I think introducing a starting state like TRIAGE NEEDED in the Geode Jira > system, and instituting a (gating) triage process would be a good way to > keep the Geode architecture cohesive and also to maximize the impact of our > contributor's efforts. I think this is very different from what this thread was initially asking for. An “approved” state is very different in my book than a bug needing more info, “triage” state. I would definitely agree with this change to add a “needs info”/“triage” state to bugs. It fits my previous statement that a ticket is opened when there is reasonable belief work needs to be done. In this case the initial work is to fully understand the issue. The next step is to progress to fixing or closed. -Jake
Re: [Discuss] New feature work approval state in Geode project?
> On May 28, 2021, at 10:48 AM, Bill Burcham wrote: > > A google search for "most successful open source project" lists Apache > Cassandra at the top. When a bug is submitted to the Cassandra Jira it > starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the > OPEN state which is described as: > > | "the issue is open and ready for the assignee to start work on it." > > I think introducing a starting state like TRIAGE NEEDED in the Geode Jira > system, and instituting a (gating) triage process would be a good way to > keep the Geode architecture cohesive and also to maximize the impact of our > contributor's efforts. I think this is very different from what this thread was initially asking for. An “approved” state is very different in my book than a bug needing more info, “triage” state. I would definitely agree with this change to add a “needs info”/“triage” state to bugs. It fits my previous statement that a ticket is opened when there is reasonable belief work needs to be done. In this case the initial work is to fully understand the issue. The next step is to progress to fixing or closed. -Jake
Re: [Discuss] New feature work approval state in Geode project?
I've also seen this on other projects where sometimes an issue gets substantial support, but ultimately gets rejected because it doesn't match the project's direction. Making this clear before work happens makes sense to me in general. However, I wonder if the additional process in our case is more expensive than the problem we are solving. How often does it happen on Geode that we reject a smaller effort, that wouldn't warrant a RFC, after the work has been done? From: Bill Burcham Sent: Friday, May 28, 2021 10:48 To: dev@geode.apache.org Subject: Re: [Discuss] New feature work approval state in Geode project? We have an RFC process "to get to consensus faster and ultimately get to execution faster". But I think in general folks tend to only do an RFC for a "big" change. Bug tickets, and particularly feature tickets are left as a gray area. A google search for "most successful open source project" lists Apache Cassandra at the top. When a bug is submitted to the Cassandra Jira it starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the OPEN state which is described as: | "the issue is open and ready for the assignee to start work on it." I think introducing a starting state like TRIAGE NEEDED in the Geode Jira system, and instituting a (gating) triage process would be a good way to keep the Geode architecture cohesive and also to maximize the impact of our contributor's efforts. Perhaps that triage process would be run by code owners in the area(s) affected by the ticket (bug or feature). -Bill On Fri, May 28, 2021 at 10:36 AM Mark Hanson wrote: > Hi All, > > There has been some discussion about adding a new state of approved to > Geode Jira for features or something like it, to help prevent work being > done that doesn’t make it into the project. What to people think? > > Thanks, > Mark >
Re: [Discuss] New feature work approval state in Geode project?
We have an RFC process "to get to consensus faster and ultimately get to execution faster". But I think in general folks tend to only do an RFC for a "big" change. Bug tickets, and particularly feature tickets are left as a gray area. A google search for "most successful open source project" lists Apache Cassandra at the top. When a bug is submitted to the Cassandra Jira it starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the OPEN state which is described as: | "the issue is open and ready for the assignee to start work on it." I think introducing a starting state like TRIAGE NEEDED in the Geode Jira system, and instituting a (gating) triage process would be a good way to keep the Geode architecture cohesive and also to maximize the impact of our contributor's efforts. Perhaps that triage process would be run by code owners in the area(s) affected by the ticket (bug or feature). -Bill On Fri, May 28, 2021 at 10:36 AM Mark Hanson wrote: > Hi All, > > There has been some discussion about adding a new state of approved to > Geode Jira for features or something like it, to help prevent work being > done that doesn’t make it into the project. What to people think? > > Thanks, > Mark >
Re: [Discuss] New feature work approval state in Geode project?
Hi All, I am just starting the chain to get it into the dev list. Bill and Donal had more concrete ideas to share. For the record, I am happy with the RFC process, but I am flexible. Thanks, Mark On 5/28/21, 10:43 AM, "Anilkumar Gingade" wrote: Can you be more elaborate on this... Are we saying; if I (geode dev) find a bug or feature that I need for my application, I need to get approval to create a ticket and work on it? We already have RFC process, won't that suffice... -Anil. On 5/28/21, 10:36 AM, "Mark Hanson" wrote: Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
Re: [Discuss] New feature work approval state in Geode project?
Can you be more elaborate on this... Are we saying; if I (geode dev) find a bug or feature that I need for my application, I need to get approval to create a ticket and work on it? We already have RFC process, won't that suffice... -Anil. On 5/28/21, 10:36 AM, "Mark Hanson" wrote: Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
Re: [Discuss] New feature work approval state in Geode project?
Does this mean that a Jira would have to be approved before assigned? Dale From: Mark Hanson Date: Friday, May 28, 2021 at 10:36 AM To: dev@geode.apache.org Subject: [Discuss] New feature work approval state in Geode project? Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
Re: [Discuss] New feature work approval state in Geode project?
Oh, I see now. Yes, +1 to what Jake said. From: Jacob Barrett Date: Friday, May 28, 2021 at 10:41 AM To: dev@geode.apache.org Subject: Re: [Discuss] New feature work approval state in Geode project? Can you provide a more concrete example? I don’t understand why there would be a JIRA written without a reasonable belief it would be executed on. A JIRA that is later determined to not be worth the effort, not a bug, or whatever, should just closed as “won’t fix”. > On May 28, 2021, at 10:36 AM, Mark Hanson wrote: > > Hi All, > > There has been some discussion about adding a new state of approved to Geode > Jira for features or something like it, to help prevent work being done that > doesn’t make it into the project. What to people think? > > Thanks, > Mark
Re: [Discuss] New feature work approval state in Geode project?
Can you provide a more concrete example? I don’t understand why there would be a JIRA written without a reasonable belief it would be executed on. A JIRA that is later determined to not be worth the effort, not a bug, or whatever, should just closed as “won’t fix”. > On May 28, 2021, at 10:36 AM, Mark Hanson wrote: > > Hi All, > > There has been some discussion about adding a new state of approved to Geode > Jira for features or something like it, to help prevent work being done that > doesn’t make it into the project. What to people think? > > Thanks, > Mark
Re: [Discuss] New feature work approval state in Geode project?
Hi Mark, Could you explain that a bit more – I’m not clear what you mean by: “to help prevent work being done that doesn’t make it into the project”. Does that mean work that isn’t somehow related to a (new) feature. --Jens From: Mark Hanson Date: Friday, May 28, 2021 at 10:36 AM To: dev@geode.apache.org Subject: [Discuss] New feature work approval state in Geode project? Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
[Discuss] New feature work approval state in Geode project?
Hi All, There has been some discussion about adding a new state of approved to Geode Jira for features or something like it, to help prevent work being done that doesn’t make it into the project. What to people think? Thanks, Mark
