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 <bill.burc...@gmail.com> Sent: Friday, May 28, 2021 10:48 To: dev@geode.apache.org <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 <hans...@vmware.com> 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 >
