On 17/02/2020 10:13, Edward Welbourne wrote: >> We currently have an "In Progress" state. In practice when I work on >> an issue, I initially do the work, then put that up for review; the >> review phase takes up fragments of my time for a while, unlike the >> main work phase, which is closer to full-time. I have more control >> over (and a better ability to estimate) how long the actual work >> takes, while review (and subsequent integration) depends on factors >> outside my control, that are harder to estimate. >> >> (Sometimes, under the present branching model, I also have to put >> work on hold until other work merges up for me to rebase it onto. >> However, that complication shall go away soon, so I'll ignore it.) >> >> When my team is planning sprints, our scrum master wants to know what >> tasks I'll be working on, and what counts as "Done" for each of them. >> Having a separate state for "In Review", distinct from "In Progress", >> would let us distinguish the relatively plannable, and intense, part >> of the work from the part that (often happens in a later sprint, and) >> takes up a smaller proportion of my time but may take longer.
Oliver Wolff (20 February 2020 09:12) > I have never worked in scrum, but what difference does it make there? > The task is not done, as long as it is not in the done state. If the > review takes to long, give people from your scrum team more time for > review. If the major hassle is CI, we would need an "Integrating" > state to see how bad our CI is. But in the end your task is not > done. Isn't that what your scrum master (and other stakeholders) are > interested in? It's a fair point: however, a strict adherence to each work item in the sprint being a whole Jira Task would mean that many of the tasks I aim to get done for Qt 6 can't be attempted, because they won't fit into a single sprint. A major reworking of a complex body of code can sometimes be fitted into a fortnight, but getting the review (and integration) done in the same fortnight is unlikely (especially at present, when I'm doing some parts of the work on 5.15 or earlier and having to wait for them to merge up to dev before I can continue with the work that's only for Qt 6). So the only way to make the Definition of Done be that the Jira task is closed is to artificially make lots of sub-tasks, that ask for code to be written and sent for review and are Done when that happens, regardless of whether it's been reviewed or integrated. This would mean creating artificial sub-tasks where really they'd be better represented by just one task that has an extra transition. I should note that we're not dogmatically following scrum; we're only lifting methods and approaches from it, to see what works for our work and the ways it can progress. >> So I'd like to modify our Jira work-flows to include a distinct "In >> Review" state for when I've completed the main work and am either >> waiting for review or responding to reviewers' comments. Of course, if >> those comments prompt me to go back and start over, I'll also want to be >> able to go back to the "In Progress" state from it. >> >> Does anyone have any objection to this, or suggestions for a better way >> to handle the relevant work-flow transition ? If not, I'm hoping Alex >> can work out how to implement what I want ... > I am afraid that this will just lead to more mails sent by JIRA. I do > not see a clear benefit, as (as said before) the task is not done. Being > in review and in integration does not need any new state, because it > does not give useful additional information. I believe this *is* useful additional information, though: code has been written, or reworked, and I've tested it to at least my satisfaction. The remaining work to be done - and there typically shall be some - is the work that arises in response to review. > If I am bored and want to do reviews, I can just go to codereview and > will find more than enough open patches that are waiting for reviews. > There is no need to take a detour via JIRA for that. On the other hand, if you could search Jira for it, you'd be able to take into account the priority of the issue the reviewed change resolves; you could prioritise review in response to the significance of the bugs being fixed. Equally, you could search by component or any of the other ways that Jira distinguishes tasks. So, while you can surely find things to review in Gerrit, Jira would be able to give you better ways to refine your search. Albeit this is only a secondary win, rather than the initial point of the exercise. > All in all I am with Andre' here. It looks like this is just for the > sake of following some process. To some degree it is indeed for the sake of following a process: on the other hand, that process has its value and can be made more effective if the tools we use - notably Jira in this case - help us to make clear what work is at what stage in the process. Process is important: good process can enable a project to progress more confidently and recognise coming problems sooner. > If reviews and integrations take too long actions should be taken to > fix that, but adding another JIRA task as a dumping ground will not > help anyone. I presume you meant "state" rather than "task" - as it happens, what I'm trying to avoid is artificially adding lots of extra Jira tasks, purely for the sake of supporting a process. A separate "In Review" state would avoid creating lots of "Write the code" sub-tasks purely for the sake of having a ticket to close. Eddy. _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development