+1 The intention is really good. If we are free to do it as an incubating project, we should go for it.
On Wed, Jan 5, 2022 at 4:35 PM Sunil Govindan <[email protected]> wrote: > Thanks, Bowen for initiating this. > > As an incubating project, do we have permission to define such a process? > And will there be any change once we become a top-level project? > > Also, this adds more clarity to the by-laws as well in terms of defining > the structure and process moving forward. > +1 > > Thank You > Sunil > > On Wed, Jan 5, 2022 at 4:32 PM Chaoran Yu <[email protected]> wrote: > > > This will be a great initiative to introduce more structure to how we > > handle larger-scale features and improvements. > > So far we have been doing things in an ad-hoc way, which tends to get > less > > effective as the community grows. > > +1 from me. > > > > On Wed, Jan 5, 2022 at 4:26 PM Weiwei Yang <[email protected]> wrote: > > > > > Oops, got it wrong, you mean broader review, not ASF board. > > > Sorry, please ignore my last comment : ) > > > > > > On Wed, Jan 5, 2022 at 4:25 PM Weiwei Yang <[email protected]> wrote: > > > > > > > Hi Bowen > > > > > > > > +1 > > > > Having a formal process will definitely help the cross-org > > communication. > > > > Do we need the ASF board to review this? I am not sure, usually, each > > > > project committee is able to decide what is the best for the project. > > > > > > > > Thanks > > > > > > > > On Wed, Jan 5, 2022 at 4:07 PM Bowen Li <[email protected]> wrote: > > > > > > > >> Hi all, > > > >> > > > >> I'd like to start conversation of building a formal process of > > YuniKorn > > > >> Improvement Proposal (YIP). > > > >> > > > >> (X)IP is a common approach to propose, discuss, collaborate on and > > > tackle > > > >> major or important changes in open source projects and communities. > > > Within > > > >> Apache projects, there're successful examples and adoptions like > Spark > > > >> (SPIP), Flink (FLIP), Kafka (KIP). > > > >> > > > >> Similarly, a YIP will define the following parts, including but not > > > >> limited > > > >> to: > > > >> - what's considered a "major change" that needs a YIP > > > >> - what should be included in a YIP (e.g. motivation/business > > > >> justifications, use case requirements, proposed changes, API > changes, > > > >> migration/compatibility, rejected alternatives, etc) > > > >> - who should initiate or be involved in a YIP > > > >> - end-to-end process > > > >> > > > >> YK community has been growing, and we've seen cases where such a > > process > > > >> can help to better facilitate communications, understanding, and > > > >> collaborations within YK community. > > > >> > > > >> Please share your thoughts, or +1/-1. If we get a consensus this is > > > good, > > > >> I > > > >> will submit a draft for YIP for broader review. > > > >> > > > >> Thanks, > > > >> Bowen > > > >> > > > > > > > > > >
