That would be just fine. The proposal's acceptance doesn't mean it becomes set in stone; we can modify it as we go.
On Mar 5, 2023 at 20:40:50, Ahmed Eldawy <[email protected]> wrote: > I think the proposal is good but it might get some feedback when developers > start adopting it. > > On Sun, Mar 5, 2023 at 8:00 PM Mike Carey <[email protected]> wrote: > > I’d say a)! I think it can help a lot with info sharing across subprojects > > involving different components of the project. > > > On Sun, Mar 5, 2023 at 7:36 PM Till Westmann <[email protected]> > > wrote: > > > > Hi, > > > > > > there were no comments on this proposal so far and I’m wondering why > > > that is. > > > > > > Do you think that the proposal is > > > a) obviously great or > > > b) obviously useless or > > > c) you didn’t have time to read it or > > > c) it needs some improvement or > > > d) it just adds overhead or > > > e) ... > > > > > > Please let us know what you think about the proposal. > > > > > > Cheers, > > > Till > > > > > > On 21 Feb 2023, at 11:14, Ian Maxon wrote: > > > > > > > Hi everyone. On one of our quarterly reports to the ASF board we got > > > > some > > > > comments about how dev@ is a ghost town. It would be very hard to > > > > discern > > > > the direction of the project from it at this point. So, Mike, Till and > > > > I > > > > discussed and came up with something that hopefully should remedy that > > > > and > > > > breathe some life back into the list. > > > > > > > > The general idea is to discuss major new features or improvements on > > > > the > > > > list, and to have a vote and some sort of PMC involvement with them. > > > > That > > > > way hopefully knowledge of them will be more distributed among all the > > > > committers. > > > > Please discuss the proposal. It's not set in stone of course, we can > > > > change > > > > things. This was mostly gleaned from similar processes in other > > > > projects, > > > > ASF and otherwise. > > > > > > > > --------- > > > > Rationale > > > > --------- > > > > > > > > AsterixDB, being a database system, is designed to be a user-facing > > > > system, > > > > but also to be a foundation for other applications. Therefore any > > > > changes, > > > > improvements, or alterations made can be of great consequence to those > > > > dependent applications. Given this, these types of changes need to be > > > > considered closely and clearly in public, to give the greatest insight > > > > as > > > > to what the consequences of them might be. Many of these processes > > > > already > > > > exist informally within the project, and this document is in part an > > > > attempt to codify them. > > > > > > > > ------------------ > > > > When is it needed? > > > > ------------------ > > > > > > > > If the change is: > > > > - adding a new feature > > > > - changing the interface (internal or otherwise) of an existing > > > > feature or > > > > otherwise fundamentally modifying its behavior > > > > - introducing any kind of potential backwards incompatibility to the > > > > persistent artifacts produced by AsterixDB > > > > > > > > --------------------------- > > > > Components and Requirements > > > > --------------------------- > > > > > > > > An APE should consist of: > > > > > > > > - A Confluence document describing the proposed design of the > > > > enhancement, > > > > it's risks and rewards, and possible alternatives (if applicable) > > > > - A JIRA issue to track the improvement, linking to the aforementioned > > > > document > > > > - A designated PMC member (who can be the proposer) to shepherd the > > > > enhancement > > > > - A list of the Committers and Contributors who will work on the > > > > enhancement > > > > > > > > By default all APEs should go to the latest development branch, but if > > > > it > > > > is intended for an older stabilization branch this should be > > > > explicitly > > > > mentioned as it is an important consideration. > > > > > > > > All of this information should be posted to [email protected] > > > > in a > > > > [DISCUSS] thread. After the discussion seems to come to a conclusion > > > > of > > > > some sort, then a [VOTE] should be issued and kept open for 72 hours. > > > > The > > > > vote is analogous to the process for releases. > > > > > >
