Re: Form a process of YuniKorn Improvement Proposal (YIP)
+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 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 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 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 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 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
Re: Form a process of YuniKorn Improvement Proposal (YIP)
+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 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 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 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 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 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 > > > >> > > > > > > > > > >
Re: Form a process of YuniKorn Improvement Proposal (YIP)
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 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 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 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 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 > > >> > > > > > >
Re: Form a process of YuniKorn Improvement Proposal (YIP)
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 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 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 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 > >> > > >
Re: Form a process of YuniKorn Improvement Proposal (YIP)
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 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 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 >> >
Re: Form a process of YuniKorn Improvement Proposal (YIP)
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 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 >
Form a process of YuniKorn Improvement Proposal (YIP)
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
