+1 We can do this ourselves. There is nothing stopping us from getting that documented. It really only formalises what we currently do in some of the threads marked as DISCUSS on this list. The status of the project is not important.
We also do not have to get it 100% correct this first time and can evolve it over time. Wilfred On Thu, 6 Jan 2022 at 11:35, Sunil Govindan <sun...@apache.org> 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 <yuchaoran2...@gmail.com> 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 <w...@apache.org> 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 <w...@apache.org> 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 <b...@apache.org> 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 > > > >> > > > > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@yunikorn.apache.org For additional commands, e-mail: dev-h...@yunikorn.apache.org
