On Mon, 2020-02-17 at 09:13 +0000, 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.
If the review process does not ever result in a significant amount of work (== no patch is ever rejected or significantly changed do to a review process), then we should reevaluate the review process. If this is indeed the case, then Gerrit has degenerated into a place to discuss formatting -- something we could have clang-format take care of automatically! If our review process is more than a formality then it might result in a significant amount of work -- the patch can be rejected or you might end up redoing significant parts of the code. In that case I do not see how you can consider your original task done before the review is complete. In both cases, IMHO having a separate state in JIRA provides very limited benefit. The code review process is meant to improve code quality. If this benefits is outweighted by reduced productivity due to the review overhead, then we should re-examine the topic of code review, not work around the issue in JIRA. We did introduce the code review process we use today in Nokia when we were a much different organization. Maybe we need to adjust our processes to the environment we work in nowadays? Best Regards, Tobias _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
