Dima, When ticket is assigned to a version and doesn't guarantee that anyone will look at it either. When it is time to release we usually have hundreds of unresolved tickets on current version and it doesn't help us anyhow. This is community, so there is little to no instruments for direct ticket management. But we have component maintainers [1]. I think they are the right people to track what is going on with their components.
[1[ https://cwiki.apache.org/confluence/display/IGNITE/How+to+Contribute#HowtoContribute-ReviewProcessandMaintainers On Thu, Nov 2, 2017 at 9:54 AM, Dmitriy Setrakyan <dsetrak...@apache.org> wrote: > Vladimir, > > In that case can you suggest a better process. I currently have a high > confidence that unless I assign the next release version to a ticket, it > will never be looked at. How do we fix it? > > D. > > On Wed, Nov 1, 2017 at 11:32 PM, Vladimir Ozerov <voze...@gridgain.com> > wrote: > > > -1 > > > > Ideally ticket should have a version only if we understand that it should > > go to certain release. All other tickets should not have versions, > because > > otherwise it is hard to see the scope of the next release, and we woulld > > need to move dozens of tickets from version to version constantly. > > > > On Thu, Nov 2, 2017 at 2:25 AM, Dmitriy Setrakyan <dsetrak...@apache.org > > > > wrote: > > > > > Igniters, > > > > > > Currently, most new Jira tickets do not get reviewed and often get lost > > > unless some user complains about it. > > > > > > In my view, the community must review all recently filed ticket and > make > > > sure that we address most critical or most useful ones. Often an issue > is > > > not critical from correctness standpoint, but is very useful from > > usability > > > stand point. > > > > > > What if we always assigned the next release version to all the newly > > filed > > > tickets. This will force someone to look at the tickets before every > > > release and move some of them to the next release. > > > > > > Thoughts? > > > > > > D. > > > > > >
