Re: Ignite Enhancement Proposal process

[Denis Magda]

Sounds good to me. No more concerns.

—
Denis

> On Sep 22, 2017, at 1:11 AM, Vladimir Ozerov  wrote:
> 
> Guys,
> 
> I thought a bit more and looks like there is no conflict. Every IEP has a
> sponsor responsible for keeping it up to date. Let's agree that it is up to
> him how to organize tickets provided that they can be tracked from WIKI
> page easily. This way we will be able to use both approaches.
> 
> Makes sense?
> 
> I will start describing the process shortly, and then invite community to
> review it.
> 
> On Thu, Sep 21, 2017 at 1:51 AM, Nikita Ivanov  wrote:
> 
>> +1 on idea (long overdue) and +1 on using epics in JIRA for grouping IEPs.
>> 
>> --
>> Nikita Ivanov
>> 
>> 
>> On Wed, Sep 20, 2017 at 10:28 PM, Denis Magda  wrote:
>> 
>>> Vladimir,
>>> 
>>> I support your initiative because it sorts things out and brings more
>>> transparency to Ignite community.
>>> 
>>> The only moment that bothers me is how the tickets, falling into a
>>> specific IEP, are *grouped in JIRA*. Instead of labels I would advise us
>> to
>>> use umbrella tickets or epics. I prefer epics more because they are the
>>> same umbrella tickets but with special visibility and tracking support
>> from
>>> JIRA side.
>>> 
>>> So if we consider epics as the way we group the relevant tickets in JIRA
>>> and keep the rest content in the IEP form on Wiki than it should help us
>>> benefit from both approaches.
>>> 
>>> Thoughts?
>>> 
>>> —
>>> Denis
>>> 
 On Sep 19, 2017, at 2:50 AM, Vladimir Ozerov 
>>> wrote:
 
 Igniters,
 
 I'd like to discuss an idea of adding "Enhancement Proposal" concept to
>>> our
 process. Many other OSS vendors use it with great success ([1], [2],
>> [3],
 [4]), so I think we can also benefit from it.
 
 **Motivation**
 Ignite project lacks transparency. We have a lot of thoughts and plans
>> in
 our heads. Some of them are materialized to tickets and discussions,
>> some
 don't. And yet there is no single place where one can understand major
 features and challenges of the product for the nearest perspective. We
>> do
 not understand our own roadmap.
 
 Another problem is that our WIKI is full of trash - lots and lots of
 outdated design documents and discussions.
 
 With Ignite Enhancement Proposal (IEP) process we can move all major
 changes to a single place, thus increasing our understanding of the
>>> product
 and community involvement.
 
 **Proposal**
 1) Create separate page on WIKI [5] where process flow will be defined
 2) Create sections for active and inactive/rejected proposals
 3) Every proposal should have separate page with the following fields:
 - ID
 - Summary
 - Author
 - Sponsor/shepherd/etc - committer or PMC member who will help author
>>> drive
 the process
 - Status (DRAFT, ACTIVE, COMPLETED, REJECTED)
 - "Motivation" section
 - "Description" section where actual design will reside
 - "Risks and Assumptions" section
 - Links to external resources, dev-list discussions and JIRA tickets
 4) Sponsor is responsible for keeping the page up to date
 5) Discussions should happen outside of WIKI - on the dev-list or
>> inside
 JIRA tickets
 6) Relevant JIRA tickets will be tracked with special labels, e.g.
>>> "iep-N"
 [6]
 
 I created sample page for binary format improvements (still raw enough)
>>> [7].
 
 Please share your thoughts.
 
 Vladimir.
 
 [1] https://www.python.org/dev/peps/
 [2]
 https://hazelcast.atlassian.net/wiki/spaces/COM/pages/
>>> 27558010/Hazelcast+Enhancement+Proposals
 [3] https://github.com/Kotlin/KEEP
 [4] https://spark.apache.org/improvement-proposals.html
 [5]
 https://cwiki.apache.org/confluence/pages/viewpage.
>>> action?pageId=73638545
 [6] https://issues.apache.org/jira/browse/IGNITE-6057
 [7]
 https://cwiki.apache.org/confluence/display/IGNITE/IEP-
>>> 1%3A+Bulk+data+loading+performance+improvements
>>> 
>>> 
>> 

Re: Ignite Enhancement Proposal process

[Vladimir Ozerov]

Guys,

I thought a bit more and looks like there is no conflict. Every IEP has a
sponsor responsible for keeping it up to date. Let's agree that it is up to
him how to organize tickets provided that they can be tracked from WIKI
page easily. This way we will be able to use both approaches.

Makes sense?

I will start describing the process shortly, and then invite community to
review it.

On Thu, Sep 21, 2017 at 1:51 AM, Nikita Ivanov  wrote:

> +1 on idea (long overdue) and +1 on using epics in JIRA for grouping IEPs.
>
> --
> Nikita Ivanov
>
>
> On Wed, Sep 20, 2017 at 10:28 PM, Denis Magda  wrote:
>
> > Vladimir,
> >
> > I support your initiative because it sorts things out and brings more
> > transparency to Ignite community.
> >
> > The only moment that bothers me is how the tickets, falling into a
> > specific IEP, are *grouped in JIRA*. Instead of labels I would advise us
> to
> > use umbrella tickets or epics. I prefer epics more because they are the
> > same umbrella tickets but with special visibility and tracking support
> from
> > JIRA side.
> >
> > So if we consider epics as the way we group the relevant tickets in JIRA
> > and keep the rest content in the IEP form on Wiki than it should help us
> > benefit from both approaches.
> >
> > Thoughts?
> >
> > —
> > Denis
> >
> > > On Sep 19, 2017, at 2:50 AM, Vladimir Ozerov 
> > wrote:
> > >
> > > Igniters,
> > >
> > > I'd like to discuss an idea of adding "Enhancement Proposal" concept to
> > our
> > > process. Many other OSS vendors use it with great success ([1], [2],
> [3],
> > > [4]), so I think we can also benefit from it.
> > >
> > > **Motivation**
> > > Ignite project lacks transparency. We have a lot of thoughts and plans
> in
> > > our heads. Some of them are materialized to tickets and discussions,
> some
> > > don't. And yet there is no single place where one can understand major
> > > features and challenges of the product for the nearest perspective. We
> do
> > > not understand our own roadmap.
> > >
> > > Another problem is that our WIKI is full of trash - lots and lots of
> > > outdated design documents and discussions.
> > >
> > > With Ignite Enhancement Proposal (IEP) process we can move all major
> > > changes to a single place, thus increasing our understanding of the
> > product
> > > and community involvement.
> > >
> > > **Proposal**
> > > 1) Create separate page on WIKI [5] where process flow will be defined
> > > 2) Create sections for active and inactive/rejected proposals
> > > 3) Every proposal should have separate page with the following fields:
> > > - ID
> > > - Summary
> > > - Author
> > > - Sponsor/shepherd/etc - committer or PMC member who will help author
> > drive
> > > the process
> > > - Status (DRAFT, ACTIVE, COMPLETED, REJECTED)
> > > - "Motivation" section
> > > - "Description" section where actual design will reside
> > > - "Risks and Assumptions" section
> > > - Links to external resources, dev-list discussions and JIRA tickets
> > > 4) Sponsor is responsible for keeping the page up to date
> > > 5) Discussions should happen outside of WIKI - on the dev-list or
> inside
> > > JIRA tickets
> > > 6) Relevant JIRA tickets will be tracked with special labels, e.g.
> > "iep-N"
> > > [6]
> > >
> > > I created sample page for binary format improvements (still raw enough)
> > [7].
> > >
> > > Please share your thoughts.
> > >
> > > Vladimir.
> > >
> > > [1] https://www.python.org/dev/peps/
> > > [2]
> > > https://hazelcast.atlassian.net/wiki/spaces/COM/pages/
> > 27558010/Hazelcast+Enhancement+Proposals
> > > [3] https://github.com/Kotlin/KEEP
> > > [4] https://spark.apache.org/improvement-proposals.html
> > > [5]
> > > https://cwiki.apache.org/confluence/pages/viewpage.
> > action?pageId=73638545
> > > [6] https://issues.apache.org/jira/browse/IGNITE-6057
> > > [7]
> > > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> > 1%3A+Bulk+data+loading+performance+improvements
> >
> >
>

Re: Ignite Enhancement Proposal process

[Nikita Ivanov]

+1 on idea (long overdue) and +1 on using epics in JIRA for grouping IEPs.

--
Nikita Ivanov


On Wed, Sep 20, 2017 at 10:28 PM, Denis Magda  wrote:

> Vladimir,
>
> I support your initiative because it sorts things out and brings more
> transparency to Ignite community.
>
> The only moment that bothers me is how the tickets, falling into a
> specific IEP, are *grouped in JIRA*. Instead of labels I would advise us to
> use umbrella tickets or epics. I prefer epics more because they are the
> same umbrella tickets but with special visibility and tracking support from
> JIRA side.
>
> So if we consider epics as the way we group the relevant tickets in JIRA
> and keep the rest content in the IEP form on Wiki than it should help us
> benefit from both approaches.
>
> Thoughts?
>
> —
> Denis
>
> > On Sep 19, 2017, at 2:50 AM, Vladimir Ozerov 
> wrote:
> >
> > Igniters,
> >
> > I'd like to discuss an idea of adding "Enhancement Proposal" concept to
> our
> > process. Many other OSS vendors use it with great success ([1], [2], [3],
> > [4]), so I think we can also benefit from it.
> >
> > **Motivation**
> > Ignite project lacks transparency. We have a lot of thoughts and plans in
> > our heads. Some of them are materialized to tickets and discussions, some
> > don't. And yet there is no single place where one can understand major
> > features and challenges of the product for the nearest perspective. We do
> > not understand our own roadmap.
> >
> > Another problem is that our WIKI is full of trash - lots and lots of
> > outdated design documents and discussions.
> >
> > With Ignite Enhancement Proposal (IEP) process we can move all major
> > changes to a single place, thus increasing our understanding of the
> product
> > and community involvement.
> >
> > **Proposal**
> > 1) Create separate page on WIKI [5] where process flow will be defined
> > 2) Create sections for active and inactive/rejected proposals
> > 3) Every proposal should have separate page with the following fields:
> > - ID
> > - Summary
> > - Author
> > - Sponsor/shepherd/etc - committer or PMC member who will help author
> drive
> > the process
> > - Status (DRAFT, ACTIVE, COMPLETED, REJECTED)
> > - "Motivation" section
> > - "Description" section where actual design will reside
> > - "Risks and Assumptions" section
> > - Links to external resources, dev-list discussions and JIRA tickets
> > 4) Sponsor is responsible for keeping the page up to date
> > 5) Discussions should happen outside of WIKI - on the dev-list or inside
> > JIRA tickets
> > 6) Relevant JIRA tickets will be tracked with special labels, e.g.
> "iep-N"
> > [6]
> >
> > I created sample page for binary format improvements (still raw enough)
> [7].
> >
> > Please share your thoughts.
> >
> > Vladimir.
> >
> > [1] https://www.python.org/dev/peps/
> > [2]
> > https://hazelcast.atlassian.net/wiki/spaces/COM/pages/
> 27558010/Hazelcast+Enhancement+Proposals
> > [3] https://github.com/Kotlin/KEEP
> > [4] https://spark.apache.org/improvement-proposals.html
> > [5]
> > https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=73638545
> > [6] https://issues.apache.org/jira/browse/IGNITE-6057
> > [7]
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 1%3A+Bulk+data+loading+performance+improvements
>
>

Re: Ignite Enhancement Proposal process

[Denis Magda]

Vladimir,

My only concern is the tickets aggregation in JIRA. The labels approach is not 
generic and flexible, requires me to use specific filters and use some numeric 
form for labels. However, if all the tickets listed in an IEP were grouped 
under an umbrella ticket or epic this would make all the things crystal clear.

—
Denis
 

> On Sep 20, 2017, at 12:41 PM, Vladimir Ozerov  wrote:
> 
> Denis,
> 
> I do not very like that idea. If you look at other projects, you'll notice
> that in general they use either WIKIs (e.g. HZ), or JIRA (e.g. Spark), but
> not both. Only one reason - to avoid complication and keep the process as
> light as possible, which is important for community.
> 
> Choosing between WIKI and JIRA I prefer WIKI because it has rich editing
> inteface. JIRA is better in state transitions and reporting. But I do not
> think we will have so many initiatives. Normally there should be ~20-30
> active initiatives, I think, so WIKI benefits outweight JIRA for me.
> 
> Makes sense?
> 
> On Wed, Sep 20, 2017 at 10:28 PM, Denis Magda  wrote:
> 
>> Vladimir,
>> 
>> I support your initiative because it sorts things out and brings more
>> transparency to Ignite community.
>> 
>> The only moment that bothers me is how the tickets, falling into a
>> specific IEP, are *grouped in JIRA*. Instead of labels I would advise us to
>> use umbrella tickets or epics. I prefer epics more because they are the
>> same umbrella tickets but with special visibility and tracking support from
>> JIRA side.
>> 
>> So if we consider epics as the way we group the relevant tickets in JIRA
>> and keep the rest content in the IEP form on Wiki than it should help us
>> benefit from both approaches.
>> 
>> Thoughts?
>> 
>> —
>> Denis
>> 
>>> On Sep 19, 2017, at 2:50 AM, Vladimir Ozerov 
>> wrote:
>>> 
>>> Igniters,
>>> 
>>> I'd like to discuss an idea of adding "Enhancement Proposal" concept to
>> our
>>> process. Many other OSS vendors use it with great success ([1], [2], [3],
>>> [4]), so I think we can also benefit from it.
>>> 
>>> **Motivation**
>>> Ignite project lacks transparency. We have a lot of thoughts and plans in
>>> our heads. Some of them are materialized to tickets and discussions, some
>>> don't. And yet there is no single place where one can understand major
>>> features and challenges of the product for the nearest perspective. We do
>>> not understand our own roadmap.
>>> 
>>> Another problem is that our WIKI is full of trash - lots and lots of
>>> outdated design documents and discussions.
>>> 
>>> With Ignite Enhancement Proposal (IEP) process we can move all major
>>> changes to a single place, thus increasing our understanding of the
>> product
>>> and community involvement.
>>> 
>>> **Proposal**
>>> 1) Create separate page on WIKI [5] where process flow will be defined
>>> 2) Create sections for active and inactive/rejected proposals
>>> 3) Every proposal should have separate page with the following fields:
>>> - ID
>>> - Summary
>>> - Author
>>> - Sponsor/shepherd/etc - committer or PMC member who will help author
>> drive
>>> the process
>>> - Status (DRAFT, ACTIVE, COMPLETED, REJECTED)
>>> - "Motivation" section
>>> - "Description" section where actual design will reside
>>> - "Risks and Assumptions" section
>>> - Links to external resources, dev-list discussions and JIRA tickets
>>> 4) Sponsor is responsible for keeping the page up to date
>>> 5) Discussions should happen outside of WIKI - on the dev-list or inside
>>> JIRA tickets
>>> 6) Relevant JIRA tickets will be tracked with special labels, e.g.
>> "iep-N"
>>> [6]
>>> 
>>> I created sample page for binary format improvements (still raw enough)
>> [7].
>>> 
>>> Please share your thoughts.
>>> 
>>> Vladimir.
>>> 
>>> [1] https://www.python.org/dev/peps/
>>> [2]
>>> https://hazelcast.atlassian.net/wiki/spaces/COM/pages/
>> 27558010/Hazelcast+Enhancement+Proposals
>>> [3] https://github.com/Kotlin/KEEP
>>> [4] https://spark.apache.org/improvement-proposals.html
>>> [5]
>>> https://cwiki.apache.org/confluence/pages/viewpage.
>> action?pageId=73638545
>>> [6] https://issues.apache.org/jira/browse/IGNITE-6057
>>> [7]
>>> https://cwiki.apache.org/confluence/display/IGNITE/IEP-
>> 1%3A+Bulk+data+loading+performance+improvements
>> 
>> 

Re: Ignite Enhancement Proposal process

[Vladimir Ozerov]

Denis,

I do not very like that idea. If you look at other projects, you'll notice
that in general they use either WIKIs (e.g. HZ), or JIRA (e.g. Spark), but
not both. Only one reason - to avoid complication and keep the process as
light as possible, which is important for community.

Choosing between WIKI and JIRA I prefer WIKI because it has rich editing
inteface. JIRA is better in state transitions and reporting. But I do not
think we will have so many initiatives. Normally there should be ~20-30
active initiatives, I think, so WIKI benefits outweight JIRA for me.

Makes sense?

On Wed, Sep 20, 2017 at 10:28 PM, Denis Magda  wrote:

> Vladimir,
>
> I support your initiative because it sorts things out and brings more
> transparency to Ignite community.
>
> The only moment that bothers me is how the tickets, falling into a
> specific IEP, are *grouped in JIRA*. Instead of labels I would advise us to
> use umbrella tickets or epics. I prefer epics more because they are the
> same umbrella tickets but with special visibility and tracking support from
> JIRA side.
>
> So if we consider epics as the way we group the relevant tickets in JIRA
> and keep the rest content in the IEP form on Wiki than it should help us
> benefit from both approaches.
>
> Thoughts?
>
> —
> Denis
>
> > On Sep 19, 2017, at 2:50 AM, Vladimir Ozerov 
> wrote:
> >
> > Igniters,
> >
> > I'd like to discuss an idea of adding "Enhancement Proposal" concept to
> our
> > process. Many other OSS vendors use it with great success ([1], [2], [3],
> > [4]), so I think we can also benefit from it.
> >
> > **Motivation**
> > Ignite project lacks transparency. We have a lot of thoughts and plans in
> > our heads. Some of them are materialized to tickets and discussions, some
> > don't. And yet there is no single place where one can understand major
> > features and challenges of the product for the nearest perspective. We do
> > not understand our own roadmap.
> >
> > Another problem is that our WIKI is full of trash - lots and lots of
> > outdated design documents and discussions.
> >
> > With Ignite Enhancement Proposal (IEP) process we can move all major
> > changes to a single place, thus increasing our understanding of the
> product
> > and community involvement.
> >
> > **Proposal**
> > 1) Create separate page on WIKI [5] where process flow will be defined
> > 2) Create sections for active and inactive/rejected proposals
> > 3) Every proposal should have separate page with the following fields:
> > - ID
> > - Summary
> > - Author
> > - Sponsor/shepherd/etc - committer or PMC member who will help author
> drive
> > the process
> > - Status (DRAFT, ACTIVE, COMPLETED, REJECTED)
> > - "Motivation" section
> > - "Description" section where actual design will reside
> > - "Risks and Assumptions" section
> > - Links to external resources, dev-list discussions and JIRA tickets
> > 4) Sponsor is responsible for keeping the page up to date
> > 5) Discussions should happen outside of WIKI - on the dev-list or inside
> > JIRA tickets
> > 6) Relevant JIRA tickets will be tracked with special labels, e.g.
> "iep-N"
> > [6]
> >
> > I created sample page for binary format improvements (still raw enough)
> [7].
> >
> > Please share your thoughts.
> >
> > Vladimir.
> >
> > [1] https://www.python.org/dev/peps/
> > [2]
> > https://hazelcast.atlassian.net/wiki/spaces/COM/pages/
> 27558010/Hazelcast+Enhancement+Proposals
> > [3] https://github.com/Kotlin/KEEP
> > [4] https://spark.apache.org/improvement-proposals.html
> > [5]
> > https://cwiki.apache.org/confluence/pages/viewpage.
> action?pageId=73638545
> > [6] https://issues.apache.org/jira/browse/IGNITE-6057
> > [7]
> > https://cwiki.apache.org/confluence/display/IGNITE/IEP-
> 1%3A+Bulk+data+loading+performance+improvements
>
>

Re: Ignite Enhancement Proposal process

[Denis Magda]

Vladimir,

I support your initiative because it sorts things out and brings more 
transparency to Ignite community.

The only moment that bothers me is how the tickets, falling into a specific 
IEP, are *grouped in JIRA*. Instead of labels I would advise us to use umbrella 
tickets or epics. I prefer epics more because they are the same umbrella 
tickets but with special visibility and tracking support from JIRA side.

So if we consider epics as the way we group the relevant tickets in JIRA and 
keep the rest content in the IEP form on Wiki than it should help us benefit 
from both approaches.

Thoughts?

—
Denis 

> On Sep 19, 2017, at 2:50 AM, Vladimir Ozerov  wrote:
> 
> Igniters,
> 
> I'd like to discuss an idea of adding "Enhancement Proposal" concept to our
> process. Many other OSS vendors use it with great success ([1], [2], [3],
> [4]), so I think we can also benefit from it.
> 
> **Motivation**
> Ignite project lacks transparency. We have a lot of thoughts and plans in
> our heads. Some of them are materialized to tickets and discussions, some
> don't. And yet there is no single place where one can understand major
> features and challenges of the product for the nearest perspective. We do
> not understand our own roadmap.
> 
> Another problem is that our WIKI is full of trash - lots and lots of
> outdated design documents and discussions.
> 
> With Ignite Enhancement Proposal (IEP) process we can move all major
> changes to a single place, thus increasing our understanding of the product
> and community involvement.
> 
> **Proposal**
> 1) Create separate page on WIKI [5] where process flow will be defined
> 2) Create sections for active and inactive/rejected proposals
> 3) Every proposal should have separate page with the following fields:
> - ID
> - Summary
> - Author
> - Sponsor/shepherd/etc - committer or PMC member who will help author drive
> the process
> - Status (DRAFT, ACTIVE, COMPLETED, REJECTED)
> - "Motivation" section
> - "Description" section where actual design will reside
> - "Risks and Assumptions" section
> - Links to external resources, dev-list discussions and JIRA tickets
> 4) Sponsor is responsible for keeping the page up to date
> 5) Discussions should happen outside of WIKI - on the dev-list or inside
> JIRA tickets
> 6) Relevant JIRA tickets will be tracked with special labels, e.g. "iep-N"
> [6]
> 
> I created sample page for binary format improvements (still raw enough) [7].
> 
> Please share your thoughts.
> 
> Vladimir.
> 
> [1] https://www.python.org/dev/peps/
> [2]
> https://hazelcast.atlassian.net/wiki/spaces/COM/pages/27558010/Hazelcast+Enhancement+Proposals
> [3] https://github.com/Kotlin/KEEP
> [4] https://spark.apache.org/improvement-proposals.html
> [5]
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=73638545
> [6] https://issues.apache.org/jira/browse/IGNITE-6057
> [7]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-1%3A+Bulk+data+loading+performance+improvements

Re: Ignite Enhancement Proposal process

[Dmitriy Setrakyan]

Great idea. Either name is fine by me, but we badly need to add these Wiki
pages ASAP. Here are some candidates:

- Usability
- SQL
- MVCC
- Persistence
- Performance

D.

On Tue, Sep 19, 2017 at 6:00 AM, Vladimir Ozerov 
wrote:

> Both "improvement" and "enhancement" are OK as both are widely used in OSS
> projects. Ideally, the abbreviation itself should sound cool. Consider
> "Python Ehnacement Proposals" - PEPS! :-)
>
> On Tue, Sep 19, 2017 at 3:10 PM, Andrey Kuznetsov 
> wrote:
>
> > Really cool idea!
> >
> > It's not convenient to look for subtle details in devlist discussion
> > thread.
> >
> > But I'd prefer the word "improvement" rather than "enhancement": the
> stuff
> > being described is not always a sharp-cut functionality.
> >
> > 2017-09-19 14:56 GMT+03:00 ALEKSEY KUZNETSOV :
> >
> > > great suggestion
> > >
> > >
> >
> > --
> > Best regards,
> >   Andrey Kuznetsov.
> >
>

Re: Ignite Enhancement Proposal process

[Vladimir Ozerov]

Both "improvement" and "enhancement" are OK as both are widely used in OSS
projects. Ideally, the abbreviation itself should sound cool. Consider
"Python Ehnacement Proposals" - PEPS! :-)

On Tue, Sep 19, 2017 at 3:10 PM, Andrey Kuznetsov  wrote:

> Really cool idea!
>
> It's not convenient to look for subtle details in devlist discussion
> thread.
>
> But I'd prefer the word "improvement" rather than "enhancement": the stuff
> being described is not always a sharp-cut functionality.
>
> 2017-09-19 14:56 GMT+03:00 ALEKSEY KUZNETSOV :
>
> > great suggestion
> >
> >
>
> --
> Best regards,
>   Andrey Kuznetsov.
>

Re: Ignite Enhancement Proposal process

[Andrey Kuznetsov]

Really cool idea!

It's not convenient to look for subtle details in devlist discussion thread.

But I'd prefer the word "improvement" rather than "enhancement": the stuff
being described is not always a sharp-cut functionality.

2017-09-19 14:56 GMT+03:00 ALEKSEY KUZNETSOV :

> great suggestion
>
>

-- 
Best regards,
  Andrey Kuznetsov.

Re: Ignite Enhancement Proposal process

[ALEKSEY KUZNETSOV]

great suggestion

вт, 19 сент. 2017 г. в 14:31, Yakov Zhdanov :

> Vladimir, I like the suggestion. We should definitely try it.
>
> --Yakov
>
-- 

*Best Regards,*

*Kuznetsov Aleksey*

Re: Ignite Enhancement Proposal process

[Yakov Zhdanov]

Vladimir, I like the suggestion. We should definitely try it.

--Yakov

Ignite Enhancement Proposal process

[Vladimir Ozerov]

Igniters,

I'd like to discuss an idea of adding "Enhancement Proposal" concept to our
process. Many other OSS vendors use it with great success ([1], [2], [3],
[4]), so I think we can also benefit from it.

**Motivation**
Ignite project lacks transparency. We have a lot of thoughts and plans in
our heads. Some of them are materialized to tickets and discussions, some
don't. And yet there is no single place where one can understand major
features and challenges of the product for the nearest perspective. We do
not understand our own roadmap.

Another problem is that our WIKI is full of trash - lots and lots of
outdated design documents and discussions.

With Ignite Enhancement Proposal (IEP) process we can move all major
changes to a single place, thus increasing our understanding of the product
and community involvement.

**Proposal**
1) Create separate page on WIKI [5] where process flow will be defined
2) Create sections for active and inactive/rejected proposals
3) Every proposal should have separate page with the following fields:
- ID
- Summary
- Author
- Sponsor/shepherd/etc - committer or PMC member who will help author drive
the process
- Status (DRAFT, ACTIVE, COMPLETED, REJECTED)
- "Motivation" section
- "Description" section where actual design will reside
- "Risks and Assumptions" section
- Links to external resources, dev-list discussions and JIRA tickets
4) Sponsor is responsible for keeping the page up to date
5) Discussions should happen outside of WIKI - on the dev-list or inside
JIRA tickets
6) Relevant JIRA tickets will be tracked with special labels, e.g. "iep-N"
[6]

I created sample page for binary format improvements (still raw enough) [7].

Please share your thoughts.

Vladimir.

[1] https://www.python.org/dev/peps/
[2]
https://hazelcast.atlassian.net/wiki/spaces/COM/pages/27558010/Hazelcast+Enhancement+Proposals
[3] https://github.com/Kotlin/KEEP
[4] https://spark.apache.org/improvement-proposals.html
[5]
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=73638545
[6] https://issues.apache.org/jira/browse/IGNITE-6057
[7]
https://cwiki.apache.org/confluence/display/IGNITE/IEP-1%3A+Bulk+data+loading+performance+improvements