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 <kl...@apache.org> 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 <jabarr...@vmware.com> > wrote: > >> >> >> > On May 28, 2021, at 10:48 AM, Bill Burcham <bill.burc...@gmail.com> >> 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 >> >>
