Jira Process Change

[Yakov Zhdanov <yz...@apache.org>]

Guys,

Our current Jira process involves going through potentially 100s of tickets
and moving them from one release to another. On top of being time
consuming, it just seems plain redundant.

I think a much better approach would be for the committers and contributors
to keep the tickets assigned to themselves between releases, and whenever
they feel that the feature will make a certain release, set the
“fixVersion” in the ticket.

The above process would work for the majority of bug fixes. Of course we
would still separately monitor tickets associated with main release
features and schedule them properly on the Release Plan [1] page.

Comments?

[1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Plan

--Yakov

Re: Jira Process Change

[Konstantin Boudnik <co...@apache.org>]

On Wed, Jan 13, 2016 at 07:14AM, Dmitriy Setrakyan wrote:
> On Wed, Jan 13, 2016 at 2:46 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> 
> > Cos and all,
> >
> > I changed column title to "Maintainer". This fits better.
> >
> > Now we need to agree on release manager for 1.6. I think I can do it for
> > 1.6, then we can try rotating between PMCs.
> >
> 
> I think, any committer should be allowed to take on RM duties, not only PMC
> members.

Locally, _any_ contributor might be an RM. But technically it is hard to do
because the release needs to be signed and usually contributors aren't a part
of WOT, so no one in sane mind would believe in the GPG signature like that.

But speaking about realities: the only real requirement is that a release has
_at least_ 3 PMC +1 votes on it (legally bound requirement); and of course the
publishing could be only done by a PMC member.

It is a good idea to rotate the duty and let everyone to taste and test the
process. Usually it catches enormous amount of bugs in the release docs and
help to build better automation.

Cos

Re: Jira Process Change

[Dmitriy Setrakyan <ds...@apache.org>]

On Wed, Jan 13, 2016 at 2:46 AM, Yakov Zhdanov <yz...@apache.org> wrote:

> Cos and all,
>
> I changed column title to "Maintainer". This fits better.
>
> Now we need to agree on release manager for 1.6. I think I can do it for
> 1.6, then we can try rotating between PMCs.
>

I think, any committer should be allowed to take on RM duties, not only PMC
members.


> Agree?
>
> --Yakov
>

Re: Jira Process Change

[Yakov Zhdanov <yz...@apache.org>]

Cos and all,

I changed column title to "Maintainer". This fits better.

Now we need to agree on release manager for 1.6. I think I can do it for
1.6, then we can try rotating between PMCs.

Agree?

--Yakov

Re: Jira Process Change

[Konstantin Boudnik <co...@apache.org>]

On Mon, Jan 11, 2016 at 05:32PM, Yakov Zhdanov wrote:
> Cos,
> 
> > In JIRA, open tickets are automatically got moved to the next version,
> once
> > the current one is getting "released" in JIRA, so the reassignment is done
> > without any human intervention normally. There's no need for any process
> > around it, IIRC.
> 
> Agree, but this way you can miss some important tickets or not so important
> tickets, but filed per devlist or userlist request and promised to be
> fixed. If anyone knows how to effectively manage this in Jira, please let
> us know. I think we should definitely try working "fixVersion" field as
> described.

I believe the most effective way to do so is once the list of features in the
release is discussed and agreed in the community, the RM will keep an eye on
the particular tickets and nudge folks if they aren't on time for the release.
there's nothing wrong with fixVersion field per se, I just was making a note
about proposed bulk JIRA updates.

> > A couple notes on the page:
> > - the macro to JIRA doesn't work, actually. Wiki users are different from
> >   JIRA ones. So it'd make sense to make an anonymous filter
> 
> Do you mean "lead" column? I think, we can just remove it.
> 
> > - what's the "Lead" role?
> 
> I meant that here we can put a person who is able to help with any question
> that may come out. However, all questions may be asked on dev list. So,
> this column seems redundant.

What I've seen to work in a number of other projects is a list of maintainers.
Say, you have people who are most interested in a particular component and
have best expertise built in it. Having a version controlled list in the
source tree would be a good way to quickly figure out who's the right person
to reach out to with any issues in the area. Lead just sounds too
enterprisee and managerial.

Cos

Re: Jira Process Change

[Yakov Zhdanov <yz...@apache.org>]

Cos,

> In JIRA, open tickets are automatically got moved to the next version,
once
> the current one is getting "released" in JIRA, so the reassignment is done
> without any human intervention normally. There's no need for any process
> around it, IIRC.

Agree, but this way you can miss some important tickets or not so important
tickets, but filed per devlist or userlist request and promised to be
fixed. If anyone knows how to effectively manage this in Jira, please let
us know. I think we should definitely try working "fixVersion" field as
described.

> A couple notes on the page:
> - the macro to JIRA doesn't work, actually. Wiki users are different from
>   JIRA ones. So it'd make sense to make an anonymous filter

Do you mean "lead" column? I think, we can just remove it.

> - what's the "Lead" role?

I meant that here we can put a person who is able to help with any question
that may come out. However, all questions may be asked on dev list. So,
this column seems redundant.

--Yakov

Re: Jira Process Change

[Konstantin Boudnik <co...@apache.org>]

On Tue, Jan 05, 2016 at 07:19AM, Dmitriy Setrakyan wrote:
> Agree. No need to just keep reassigning a whole bulk of tickets from one
> release to another.

In JIRA, open tickets are automatically got moved to the next version, once
the current one is getting "released" in JIRA, so the reassignment is done
without any human intervention normally. There's no need for any process
around it, IIRC.

I want to comment on 
> > I think a much better approach would be for the committers and
> > contributors to keep the tickets assigned to themselves between releases,
> > and whenever

That's basically how it works in the OSS projects. People are working on what
they feel like/have time for. That said, it is entirely acceptable for one to
pick-up a ticket assigned to someone else and work on it to make to the next
release. Assuming that whoever the ticket being grabbed from doesn't already
work on it, nor doesn't mind letting it go.

Release manager job isn't to assign work to ppl in the community, but to shape
up a release to its liking, essentially. And then it is up to effectively PMC
to vote it up or down. Going to the extreme: there's nothing wrong with having
more than one release coming from the same project at the same time. It is
confusing and perhaps wasteful, but quite legit for sure.

A couple notes on the page:
 - the macro to JIRA doesn't work, actually. Wiki users are different from
   JIRA ones. So it'd make sense to make an anonymous filter
 - what's the "Lead" role?

Thanks,
  Cos

> On Tue, Jan 5, 2016 at 2:23 AM, Yakov Zhdanov <yz...@apache.org> wrote:
> 
> > Guys,
> >
> > Our current Jira process involves going through potentially 100s of tickets
> > and moving them from one release to another. On top of being time
> > consuming, it just seems plain redundant.
> >
> > I think a much better approach would be for the committers and contributors
> > to keep the tickets assigned to themselves between releases, and whenever
> > they feel that the feature will make a certain release, set the
> > “fixVersion” in the ticket.
> >
> > The above process would work for the majority of bug fixes. Of course we
> > would still separately monitor tickets associated with main release
> > features and schedule them properly on the Release Plan [1] page.
> >
> > Comments?
> >
> > [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Plan
> >
> > --Yakov
> >

Re: Jira Process Change

[Dmitriy Setrakyan <ds...@apache.org>]

Agree. No need to just keep reassigning a whole bulk of tickets from one
release to another.

D.

On Tue, Jan 5, 2016 at 2:23 AM, Yakov Zhdanov <yz...@apache.org> wrote:

> Guys,
>
> Our current Jira process involves going through potentially 100s of tickets
> and moving them from one release to another. On top of being time
> consuming, it just seems plain redundant.
>
> I think a much better approach would be for the committers and contributors
> to keep the tickets assigned to themselves between releases, and whenever
> they feel that the feature will make a certain release, set the
> “fixVersion” in the ticket.
>
> The above process would work for the majority of bug fixes. Of course we
> would still separately monitor tickets associated with main release
> features and schedule them properly on the Release Plan [1] page.
>
> Comments?
>
> [1] https://cwiki.apache.org/confluence/display/IGNITE/Release+Plan
>
> --Yakov
>