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. >
