Reference application issue evaluation process

Development
1

Hello all;

Currently when a dev works on an issue mainly from the reference application and submits it for review and testing in order to be merged ,the issue remains assigned to the person who does the testing and the merging not the dev who raised the pr which i think needs to be rectified as compared to the way its done with reviewing and merging of issues in core.

Am proposing that if possible then we should adopt the workflow in core were the issue remains assigned to the dev who did the actual after the ticket is closed off :cowboy_hat_face:

Thanks

@cintiadr @dkayiwa

3 Likes
2

:grinning:cc @mozzy

3

I have never liked the reference application JIRA project workflow.

3 Likes
4

@cintiadr @burke @mksd @mogoodrich is it possible to change the the reference application JIRA project workflow, if yes then we should give it a shot :gun: :blush:

1 Like
5

Yes sure, it’s bloated with unnecessary step IMHO.

6

The workflow in core is the original, custom (pre-agile) workflow, which follows a very prescribed workflow. When Reference Application 2.0 development started, the teams wanted to use agile boards – i.e., columns of tickets with the ability to drag & drop tickets between the columns – which do not work with the custom core workflow. That’s why RefApp uses an agile workflow.

In core, we don’t reassign the issue during commit review. So, the ticket is never re-assigned.

In RefApp (using the agile workflow), the system doesn’t automatically re-assign tickets when a ticket is moved from a development to testing column, but does offer “Claim Issue” and “Assign Issue” actions, which I presume testers are using to re-assign the issue. The only way to get the issue re-assigned to the original developer would be for someone (the test or the dev) to re-assign the issue OR to never re-assign the issue in the first place. The core workflow has a “Designated committer” property for tickets that is independent of ticket assignment.

So, I could see two options:

  1. Add a “Tester” property to tickets in the agile workflow and use this (instead of ticket assignment) to designate the tester, avoiding the need to re-assign tickets.

  2. Just don’t re-assign the ticket when testing. This would require teaching testers not to claim tickets and would make the tester “invisible” … so probably not the best option. But it could be done immediately by just not re-assigning tickets when testing. :slightly_smiling_face:

1 Like
7

I don’t have enough context to give any opinion on which workflow to have, but quite a few of us have Jira admin to modify it (when we have reached some agreement) :slight_smile:

1 Like
8

thanks @burke for this ,with option 1 does it require to create tickets to implement option 1?

In the mean time i think we can adopt option 2 ,and may be the release manger for reff app 2.10 @mozzy can also look into this option