[DISUCSS] Ticket filing process

[dsetrakyan]

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.

[Vladimir Ozerov]

-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 <[hidden email]>
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.
>

[dsetrakyan]

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 <[hidden email]>
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 <[hidden email]>
> 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.
> >
>

[Vladimir Ozerov]

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 <[hidden email]>
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 <[hidden email]>
> 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 <[hidden email]
> >
> > 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.
> > >
> >
>

[dsetrakyan]

On Tue, Nov 7, 2017 at 7:16 PM, Vladimir Ozerov <[hidden email]>
wrote:

> 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.


Why it does not help? At that point, people would at least look at the
tickets before moving to the next release, and maybe fix some of them.

If you do not like what I am proposing, can you suggest something
different?

D.

[Vladimir Ozerov]

Dima,

As I already mentioned, the whole community more or less followed this
process for years already with no success. My suggestion is to ask
component maintainers to perform regular review of relevant tickets.

On Wed, Nov 8, 2017 at 12:15 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Tue, Nov 7, 2017 at 7:16 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > 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.
>
>
> Why it does not help? At that point, people would at least look at the
> tickets before moving to the next release, and maybe fix some of them.
>
> If you do not like what I am proposing, can you suggest something
> different?
>
> D.
>

[dsetrakyan]

On Wed, Nov 8, 2017 at 6:06 AM, Vladimir Ozerov <[hidden email]>
wrote:

> Dima,
>
> As I already mentioned, the whole community more or less followed this
> process for years already with no success. My suggestion is to ask
> component maintainers to perform regular review of relevant tickets.
>

Your suggestion will not work, because we cannot force anyone to do the
tickets review. However, if the release version was assigned properly, the
release manager or component owners would have no choice but to do the
review.

To counter your point, I think we had much more success reviewing the
tickets before, when we had mainly assigned all the tickets to the upcoming
release, than now.

D.

[dmagda]

> However, if the release version was assigned properly, the
> release manager or component owners would have no choice but to do the
> review.

There is actually an alternative the release managers tend to follow. They simply move all the unresolved tickets to the next version blindly. This happens around a release day and I get a dozen of JIRA notifications saying that a ticket assigned to version X was rescheduled to version Y.

Anyway, we cannot force a single contributor such as the release manager to be responsible for this. This should be a collaborative process established between Ignite committers.

However, regardless of the chosen process those who are going to asses new tickets have to look them up first. And here is a rule of “setting a ticket to the latest version” might be one of the best options.

—
Denis
 

> On Nov 7, 2017, at 2:57 PM, Dmitriy Setrakyan <[hidden email]> wrote:
>
> On Wed, Nov 8, 2017 at 6:06 AM, Vladimir Ozerov <[hidden email]>
> wrote:
>
>> Dima,
>>
>> As I already mentioned, the whole community more or less followed this
>> process for years already with no success. My suggestion is to ask
>> component maintainers to perform regular review of relevant tickets.
>>
>
> Your suggestion will not work, because we cannot force anyone to do the
> tickets review. However, if the release version was assigned properly, the
> release manager or component owners would have no choice but to do the
> review.
>
> To counter your point, I think we had much more success reviewing the
> tickets before, when we had mainly assigned all the tickets to the upcoming
> release, than now.
>
> D.

[dsetrakyan]

On Wed, Nov 8, 2017 at 8:08 AM, Denis Magda <[hidden email]> wrote:

> > However, if the release version was assigned properly, the
> > release manager or component owners would have no choice but to do the
> > review.
>
> There is actually an alternative the release managers tend to follow. They
> simply move all the unresolved tickets to the next version blindly. This
> happens around a release day and I get a dozen of JIRA notifications saying
> that a ticket assigned to version X was rescheduled to version Y.
>

I do not believe this happens "blindly". These tickets get looked at before
they get reassigned. Some of them get closed as duplicates, others are
closed because they are not an issue anymore, others get reassigned to the
next release. It is still better than what we have right now.

However, even if you are right, and the tickets are not looked at, we are
exactly at the same place we are today, when tickets just get ignored
altogether, so no harm done.


>
> Anyway, we cannot force a single contributor such as the release manager
> to be responsible for this. This should be a collaborative process
> established between Ignite committers.
>

I keep hearing the word "process", but so far I have not seen anything
workable proposed.



> However, regardless of the chosen process those who are going to asses new
> tickets have to look them up first. And here is a rule of “setting a ticket
> to the latest version” might be one of the best options.
>

Exactly, it is the best of the worst options, and there is no better
alternative so far. My suggestion would be to start assigning the next
release version to all the tickets until the community comes up with a
better process.

D.

[Vladimir Ozerov]

Dima,

What is the problem you are trying to solve? I am not sure I understand.
You cannot force maintainers to do a review. And you cannot force release
manager to do this either. Because this role is only about following
mandatory ASF steps to make release happen, nothing more.

ср, 8 нояб. 2017 г. в 3:28, Dmitriy Setrakyan <[hidden email]>:

> On Wed, Nov 8, 2017 at 8:08 AM, Denis Magda <[hidden email]> wrote:
>
> > > However, if the release version was assigned properly, the
> > > release manager or component owners would have no choice but to do the
> > > review.
> >
> > There is actually an alternative the release managers tend to follow.
> They
> > simply move all the unresolved tickets to the next version blindly. This
> > happens around a release day and I get a dozen of JIRA notifications
> saying
> > that a ticket assigned to version X was rescheduled to version Y.
> >
>
> I do not believe this happens "blindly". These tickets get looked at before
> they get reassigned. Some of them get closed as duplicates, others are
> closed because they are not an issue anymore, others get reassigned to the
> next release. It is still better than what we have right now.
>
> However, even if you are right, and the tickets are not looked at, we are
> exactly at the same place we are today, when tickets just get ignored
> altogether, so no harm done.
>
>
> >
> > Anyway, we cannot force a single contributor such as the release manager
> > to be responsible for this. This should be a collaborative process
> > established between Ignite committers.
> >
>
> I keep hearing the word "process", but so far I have not seen anything
> workable proposed.
>
>
>
> > However, regardless of the chosen process those who are going to asses
> new
> > tickets have to look them up first. And here is a rule of “setting a
> ticket
> > to the latest version” might be one of the best options.
> >
>
> Exactly, it is the best of the worst options, and there is no better
> alternative so far. My suggestion would be to start assigning the next
> release version to all the tickets until the community comes up with a
> better process.
>
> D.
>

[dsetrakyan]

On Wed, Nov 8, 2017 at 1:32 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Dima,
>
> What is the problem you are trying to solve? I am not sure I understand.
> You cannot force maintainers to do a review. And you cannot force release
> manager to do this either. Because this role is only about following
> mandatory ASF steps to make release happen, nothing more.
>

Vladimir, this is not an ASF issue. As Ignite PMC, we can define whatever
processes we deem appropriate to better manage our Jira processes.

The issue I am trying to solve is that I want every new ticket that is
filed to be looked at by one of the committers. Currently this is not
happening and many new tickets never get reviewed by anyone, which
essentially means that we are turning a blind eye on some critical issues
spotted by users or other community members.

With the process I am suggesting a committer will have to look at the
tickets and perform some action. Most of the time the tickets will just be
moved to the next release, but sometimes they will be closed or
re-prioritized as more critical, etc.

D.

[Vladimir Ozerov]

Ok, I see. Then the question is when to do a review?

On Wed, Nov 8, 2017 at 9:19 AM, Dmitriy Setrakyan <[hidden email]>
wrote:

> On Wed, Nov 8, 2017 at 1:32 PM, Vladimir Ozerov <[hidden email]>
> wrote:
>
> > Dima,
> >
> > What is the problem you are trying to solve? I am not sure I understand.
> > You cannot force maintainers to do a review. And you cannot force release
> > manager to do this either. Because this role is only about following
> > mandatory ASF steps to make release happen, nothing more.
> >
>
> Vladimir, this is not an ASF issue. As Ignite PMC, we can define whatever
> processes we deem appropriate to better manage our Jira processes.
>
> The issue I am trying to solve is that I want every new ticket that is
> filed to be looked at by one of the committers. Currently this is not
> happening and many new tickets never get reviewed by anyone, which
> essentially means that we are turning a blind eye on some critical issues
> spotted by users or other community members.
>
> With the process I am suggesting a committer will have to look at the
> tickets and perform some action. Most of the time the tickets will just be
> moved to the next release, but sometimes they will be closed or
> re-prioritized as more critical, etc.
>
> D.
>

[dsetrakyan]

On Thu, Nov 9, 2017 at 11:10 PM, Vladimir Ozerov <[hidden email]>
wrote:

> Ok, I see. Then the question is when to do a review?
>

Whenever, the sooner the better. This we cannot enforce. But since the
tickets will have the upcoming release version, the review will have to
happen before the release. Makes sense?