+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 <dma...@apache.org> 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 <voze...@gridgain.com> > 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 > >
