About mantis:

new -> confirmed -> assigned -> quick review -> (testing if needed) -> (review if needed) -> merged -> closed

(testing if needed) -> (review if needed) can be
(testing if needed) -> (review if needed) -> (testing if needed) -> (review if needed) -> (testing if needed) -> (review if needed) etc … if needed.

I think a quick review can be done before testing to check the complexity of the commit.
Some commit can be merged just with a good review
But some other need more test

Ping Gabriel ;)

ping @ollehar
ping @c_schmitz

I think
we can have some search filter
Review (no assignment) : https://bugs.limesurvey.org/search.php?project_id=12&status=60&handler_id=-2&sticky=on&sort=date_submitted%2Clast_updated&dir=DESC%2CDESC&hide_status=-2&match_type=0

And i think not assigned is more clear :
For example in https://bugs.limesurvey.org/search.php?project_id=12&status=65&sticky=on&sort=date_submitted%2Clast_updated&dir=DESC%2CDESC&hide_status=-2&match_type=0
All seems assigned , i don't take it.

I think assigned can be used for assign on current task :)

Hi Denis!

I see the main difference in between what I said and you said is this
quick review -> (testing if needed) -> (review if needed) -> resolved...
vs
testing->review->resolved...

I would set the workflow based on WHO is doing WHAT.
After a fix is done, it will be ready for tester (or someone else) to test it or review it .
I believe that's the thing to be signalized: Fix is done and DEV is releasing.

If the tester is a developer who is only checking code and will be doing a quick review, I am not sure that's something that need to be shown in the workflow, is it?
If the tester is doing one or many reviews, again, I am not sure it is something to be shown on the workflow.

Once the tester grabs it, I believe the tester should assign it to himself, and setting it to "review".

What do you think?

My suggestion:

• new -> Issue is new
• confirmed -> Someone looked at it and was able to reproduce - otherwise ask reporter and set to 'Feedback'
• assigned -> Assigned to a developer
• 'Ready for code review' -> Development is done, ready for code review
• 'In code review' -> if done move to 'ready for testing', otherwise move back to 'Assigned'
• 'Ready for testing' -> ready for testing
• 'In testing' -> Being tested. If successful move to 'To be merged' otherwise to 'Assigned'
• 'To be merged' -> Ready for Merge - after merge move to resolved
• 'Resolved' -> Merged to master but not released
• 'Closed' -> Released

Additional rules:
Code review and/or testing can be omitted if the change is obviously uncritical and affects only 1-2 lines of code.

Let me know what you think...

I would set the workflow based on WHO is doing WHAT.

Yes : Assign to is used for this. no ?

Once the tester grabs it, I believe the tester should assign it to himself, and setting it to "review".

Yes, then : more clear is it's (for example) : status = testing, but unassigned : https://bugs.limesurvey.org/permalink_page.php?url=https%3A%2F%2Fbugs.limesurvey.org%2Fsearch.php%3Fproject_id%3D4%26handler_id%3D-2%26sticky%3Don%26sort%3Dlast_updated%26dir%3DDESC%26hide_status%3D90%26match_type%3D0&permalink_token=20220525LaFn3Uarcox17SXTBt2CQQH_sbckYXtQ

@c_schmitz : you think review must be done before testing ?
Else : it's more for usage of mantis state :)

@c_schmitz Does that apply to current options?
Is Mantis configured like that already?

image.png (7,400 bytes)   

image.png (7,400 bytes)   

Well I can extend the status list as needed. Just we need to agree first.

OK. I would just do code review after testing.

Another question.
After a DEV set it to "ready for testing", who would assign that to a tester?

testing -> review
If issue : can be testing -> review again sometimes.
Reviewer can choose if need testing again or ok to merge after :)

After a DEV set it to "ready for testing", who would assign that to a tester?

My opinion: tester get it (assign it), dev unassign :)
Then : we don't need "Ready for testing"and "Ready for review"

Ready for testing == (status == testing && Unassigned)
In testing == (status == testing && assigned)

At last, as we are speaking about Mantis, on the email notifications, can we maybe make more explicit who is doing the status changes?

Example. I get this line:

The following issue has been set as DUPLICATE OF issue 18074.

Would be great (easier and time saver) to see somehting like

The following issue has been set as DUPLICATE OF issue 18074, by C_SCHMITZ

Internally we always do review before testing. Because we assume that code changes might introduce more bugs.
So, please do code review before testing.

I added the new statuses now. Let me know if there are any open questions.

Then : we use "Ready for …" without updating assignment ?

I would also keep "acknolwedged".
Bugs are created as "new".
Someone glance them but can't confirm them. Then they are set as "acknolwedged".

So people which need to confirm issues shall pick up status "acknolwedged" as well as new.
Moving them to "acknolwedged" is good for monitoring incoming bugs.

yeah, I did not touch acknowledged or confirmed.

@DenisChenu: Yea, if you use "Ready for" I would set the assignee to (empty).

Final Set of Status

• 'new' -> Issue is new
• 'Acknolwedged' -> Issue is received and has been seen. Pending to be confirmed.
• 'confirmed' -> Someone looked at it and was able to reproduce - otherwise ask reporter and set to 'Feedback'
• 'assigned' -> Assigned to a developer
• 'Ready for code review' -> Development is done, ready for code review
• 'In code review' -> if done move to 'ready for testing', otherwise move back to 'Assigned'
• 'Ready for testing' -> ready for testing
• 'In testing' -> Being tested. If successful move to 'To be merged' otherwise to 'Assigned'
• 'To be merged' -> Ready for Merge - after merge move to resolved
• 'Resolved' -> Merged to master but not released
• 'Closed' -> Released

Additional Rules:

• Code review and/or testing can be omitted if the change is obviously uncritical and affects only 1-2 lines of code.
• If you use "Ready for" it is ok to set the assignee to empty.
• Internally we always do review before testing. Because we assume that code changes might introduce more bugs.
  So, please do code review before testing.