Re: [Development] Proposal: more Jira states to track stages of the work on an issue
Hi, Just adding in another vote for introducing a “In Review/Integration” state. As a disclaimer, I am working in the same team as Eddy. The reason I see it beneficial is to have better visibility on the progress of working on a certain task. Eddy already made it clear that while something is “in review” or in the process of getting integrated or “waiting for other changes to merge”, there is no active work on this task happening. Defining that as “In Progress” is misleading. Some people indicated that it feels like pressing a process into the workflow. I would like to highlight that this is absolutely not the case. Neither is this a PM decision or anything alike. It’s simply that recently we figured that with running sprints, the time spend on coding itself is only a fraction of time until a task gets resolved. We have had multiple (maybe even the majority) incidents of tasks running/sliding through multiple sprints, as we were not able to merge. To repeat, the idea is to improve on the visibility of a state of a task. Some might now say “Well, if integration (or CI) is the problem, then fix this rather than introduce another state”. That’s a valid point. But only if there are evident indicators. Personally, I prefer to have metrics proving a point, and that might be one mean to achieve this. Heck, we might even get to a point that this is not needed anymore, as everything goes super smooth (ie 5 minutes from issue raised to integration done reference before). But first, I do not see this happening within the foreseeable future. Secondly, are we really that gridlocked to not change anything at all because it might be revisited at some point? What I also miss in this thread is a suggestion on how this could be handled differently? One idea which came up in discussions is to declare an issue as “blocked” while it is waiting for integration. But imho that does not make any sense either. First, because blocked is in the “Open” State, which indicates that no one is currently looking at it at all and the task is free to grab by anyone. Furthermore, “blocked” usually means other external factors to justify this state. I’d also like to share the link to Atlassian’s workflow proposal on how to create an agile workflow in JIRA. https://www.atlassian.com/agile/project-management/workflow Note that this also includes two separate “active” states. BR, Maurice > -Original Message- > From: Development On Behalf Of > Edward Welbourne > Sent: Thursday, February 20, 2020 2:37 PM > To: Tobias Hunger > Cc: development@qt-project.org > Subject: Re: [Development] Proposal: more Jira states to track stages of the > work on an issue > > On Mon, 2020-02-17 at 09: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. > > Tobias Hunger (20 February 2020 10:00) replied: > > 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. > > I'm not suggesting or claiming either of those things, nor are they any part > of > the case I'm making for having a separate state in Jira. > > I'm better able to estimate how long I'll take to do the work before review > than to estimate the time it'll take for that work to get through review; but, > usually, the amount of *my* time that'll be taken up by the work during > review is small compared to the amount of work I do before sending it for > review. So, when it comes to planning my work and communicating what I'm > doing and when I expect it to be done, there is a vast difference between > the work I do before review and the work I do in review. > > * Before review: more or less full-time work, taking relatively > predictable large amounts of my time over a relatively predictable > calendar duration. > > * In review: sporadic work, usually cumulatively smaller
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Mon, 2020-02-17 at 09: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. Tobias Hunger (20 February 2020 10:00) replied: > 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. I'm not suggesting or claiming either of those things, nor are they any part of the case I'm making for having a separate state in Jira. I'm better able to estimate how long I'll take to do the work before review than to estimate the time it'll take for that work to get through review; but, usually, the amount of *my* time that'll be taken up by the work during review is small compared to the amount of work I do before sending it for review. So, when it comes to planning my work and communicating what I'm doing and when I expect it to be done, there is a vast difference between the work I do before review and the work I do in review. * Before review: more or less full-time work, taking relatively predictable large amounts of my time over a relatively predictable calendar duration. * In review: sporadic work, usually cumulatively smaller than the previous, happens reactively, I can only guess roughly how much of my time that'll take before reviewers tell me what to fix and I don't know how much calendar delay it'll involve. Distinguishing these two phases of the work is useful to me, it's useful to management and product management, it's potentially useful to others. Users affected by what I'm fixing may also benefit from being alerted to the start of review, if they're in a position to apply my patch and gain its benefits right away (albeit with some risk that, hopefully, review serves to reduce). > 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? That's a whole other question and, if you believe either of the concerns you described above is in fact a real issue, I encourage you to start a separate thread, giving your reasons for believing our code review process costs us more than it gains us. I don't believe that, but if you do then we need to discuss it and perhaps change our process, which might indeed make my proposal redundant, Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
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
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
TL;DR: I struggle to find any substance in André's objections. Meanwhile, I'd really like to hear from folk more familiar with Jira: * Would a new state actually make it possible to show a useful distinction, on Jira's scrum boards, between tasks in progress and those in review ? Or is Jira's scrum board too tied to "In Progress" for a new state to be any help at all ? * If that *is* viable, would a tag suffice to achieve the same effect ? A clear answer from a Jira expert on either of those would be more interesting than the present discussion. There are other uses for the "In Review" distinction, but my current purpose in proposing it is as a way to make Jira's scrum boards more useful. On Wed, Feb 19, 2020 at 09:45:48AM +, Edward Welbourne wrote: >> I very much doubt the distinction between In Progress and In Review is >> going to involve much bike-shedding. André Pönitz (19 February 2020 22:34) > *shrug* > > Assuming that JIRA states are meant to be disjoint and that the names > actually bear some meaning, "In Review" would mean "Not in Progress". That's silly. Does "In Progress" mean "No longer Accepted" ? Does "Accepted" means "No longer Reported" ? I doubt anyone is so silly as to read it that way. Nor would any read "In Review" as "Not in Progress". > Which already would be an interesting message to the reviewer. Like, > "whatever you do here, that's not considered 'Progress'". > > Of course, nobody intents to bui^H^H^Hsend such message, and that's > easily solvable, by either dropping the connection between state names > and meaning, or by dopping the disjointness of states. > > What do you prefer? That folk not wilfully misinterpret state names for the sake of vacuous rhetorical grand-standing. Already now there are tasks that get prioritized, and assigned, and re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened several times. Watchers that e.g. wait for a "Done" there get notified each time on such unprogressing transitions, and skipping these sums up to quite a bit of unproductive time already now. >>> >>> True enough; this would introduce one more transition, so one more >>> e-mail per bug. None the less, it's a transition that does mean >>> something useful to those watching - especially those waiting for a fix >>> - we are a significant step closer to a fix, > Is is? > > First, being on review might still not mean getting closer to 'Done'. > Patches get rejected or delayed for real or imagined reasons, nobody > might actually review, a successful review might not be convincing > enough for CI to let it pass etc, etc. The fact that sometimes we think we've fixed a bug but later have to re-open it doesn't persuade anyone - unless perhaps you - that we shouldn't have a Closed state. Likewise, the fact that sometimes we do a bunch of work in an attempt to fix something, but it all come to nothing, doesn't mean it's useless to have the In Progress state - even if the progress we thought we were making proved vain, it was meaningful to say we were trying to solve the problem. In the same way, when we think we've solved the problem, it's meaningful to make that clear, even if we haven't yet got past review and integration, which might throw us back to having to hack on the code some more. > Second, water-level reports on how close something is to being done > is practically never the reason why I watch tasks, I watch them > because I may need to act once it is resolved. And only then. Jira does not exist only for you, or indeed only for developers. It facilitates communication between all stakeholders. It serves purposes for some stakeholders that are of no value to others; and the resulting e-mails that matter to some are thus a cost to those who don't find those messages interesting. What matters is whether, on balance, it provides a net benefit. >>> and there's a patch they might even be interested in applying >>> locally. And, as Lorn pointed out, issues don't have to go through >>> every stage; it'd just be there for the benefit of those who find it >>> useful. > And to the distraction to those that don't. That's why the 'Verified' > state was removed not that long ago. Presumably we concluded that the benefit of the state didn't outweigh the cost. The reason I've started this discussion is that I believe an In Review state would outweigh its cost. You clearly disagree, although the reasons you give for disagreeing don't sound at all persuasive to me; they sound more like wilful curmudgeonliness, thus far: raising objections that would apply just as robustly to the basic "Reported -> Fixed" work-flow that a minimal bug-tracker would have. Is a Fixed bug no longer Reported ? Of course not, it's both Reported and Fixed. Is it pointless to have a Fixed state just because sometimes we re-open bugs ? Of course not, it's better to claim it's fixed when we think it is, and admit our error when it turns out we were
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
> On 20 Feb 2020, at 00:08, André Pönitz wrote: > On Wed, Feb 19, 2020 at 10:43:17AM +, Volker Hilsheimer wrote: >> Even when doing development (as opposed to the pointy-haired work), I >> benefit from having tools that help me to maintain a work-in-progress >> limit, that allow me to see what state the work someone else is doing >> is in (because I might depend on it or just be curios about it), or >> allow me to signal to customers waiting for the fix that they might >> want to have a look at a proposed change, even if they don't have an >> account on Gerrit. > > *Customers*, *without an Account*, to *look* at changes on Gerrit? > > Sometimes I really regret having dropped out of university before > finishing basic maths. Don’t worry, you don’t need to know about the really big numbers for that one :P >> The Qt Project defines “code review” as an explicit step that >> contributions have to go through. > > Correct. > >> Given that it takes a substantial amount of time to get things >> through review, > > A review, even a *proper review* by *your standards*, does not have > to "take substantial amounts of time". > > It's technically completely feasible (and I guess one could dig out > practically examples) where an issue goes from "Someone mentioned > a problem on IRC" to "Fix is integrated" in less then five minutes. Yes, and this proposal doesn’t affect that kind of work. Just as JIRA doesn’t affect this kind of work. > The undeniable fact that it actually *does* take a substantial amount > of time *in a lot of cases* is not the result of having "not enough > JIRA states" but actually that of a lot of causes, none of which that > I am aware are of of the sort that would benefit from changes to the > JIRA process. In this case, the proposal is not about “making work get done faster”, but “making work more visible”. This is valuable, for some people, and not only pointy haired ones. >> I think it would make the JIRA-model of how work happens a bit more >> useful if it would reflect the way that work actually happens. > > That's an interesting puzzle to solve when "the way that work actually > happens" is actually "outside JIRA, for a reason" > > And that happens to be rather normal when e.g. > - the issue is not coming via JIRA, like normal reviews, If there is no JIRA ticket, then we don’t have to worry about how many states a non-existent JIRA ticket could be in. > - the issue is urgent so JIRA would be too slow to use, Ditto. I don’t experience this to be the case, to be honest. > - the issue is small, so the overhead would be prohibitive >compared to the cost of the actual work. > - the issue is big, so wind direction would change to often >before this is done. Contributors that don’t use JIRA today because they don’t want to plan their work this way, don’t need to coordinate their work with other members in the team, are not subject to customers' or customer representatives’ inquiries, or always only work on stuff from your list can ignore this discussion. FWIW, I personally much prefer reviewing changes where I can look up the description of the problem that the change is trying to solve. Sometimes the commit message is good enough, but often the discussion of the problem in JIRA is very helpful. And from my experience, it seems that a lot of discussions happening during code review would have been good to have before code was written. JIRA is a good place for this. Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Mon, 2020-02-17 at 09: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. 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
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
Hi, On 17/02/2020 10:13, Edward Welbourne wrote: > Hi all, > > 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. 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? > > 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. 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. All in all I am with Andre' here. It looks like this is just for the sake of following some process. 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. BR, Olli > > Eddy. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Wed, Feb 19, 2020 at 10:43:17AM +, Volker Hilsheimer wrote: > Even when doing development (as opposed to the pointy-haired work), I > benefit from having tools that help me to maintain a work-in-progress > limit, that allow me to see what state the work someone else is doing > is in (because I might depend on it or just be curios about it), or > allow me to signal to customers waiting for the fix that they might > want to have a look at a proposed change, even if they don't have an > account on Gerrit. *Customers*, *without an Account*, to *look* at changes on Gerrit? Sometimes I really regret having dropped out of university before finishing basic maths. > The Qt Project defines “code review” as an explicit step that > contributions have to go through. Correct. > Given that it takes a substantial amount of time to get things > through review, A review, even a *proper review* by *your standards*, does not have to "take substantial amounts of time". It's technically completely feasible (and I guess one could dig out practically examples) where an issue goes from "Someone mentioned a problem on IRC" to "Fix is integrated" in less then five minutes. The undeniable fact that it actually *does* take a substantial amount of time *in a lot of cases* is not the result of having "not enough JIRA states" but actually that of a lot of causes, none of which that I am aware are of of the sort that would benefit from changes to the JIRA process. > I think it would make the JIRA-model of how work happens a bit more > useful if it would reflect the way that work actually happens. That's an interesting puzzle to solve when "the way that work actually happens" is actually "outside JIRA, for a reason" And that happens to be rather normal when e.g. - the issue is not coming via JIRA, like normal reviews, - the issue is urgent so JIRA would be too slow to use, - the issue is small, so the overhead would be prohibitive compared to the cost of the actual work. - the issue is big, so wind direction would change to often before this is done. Andre' > ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Wed, Feb 19, 2020 at 09:45:48AM +, Edward Welbourne wrote: > On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote: > >> Stepping through the interim steps is not a requirement, so it is not that > >> much difference to go from Reported->In Progress to Reported->In Review, > >> really. > >> > >> So the list you have to select from has one more entry to choose from, is > >> that such a big deal? > > > This is not the problem. > > > > More states lead to bikeshedding what would be The Right State for a > > task. > > I very much doubt the distinction between In Progress and In Review is > going to involve much bike-shedding. *shrug* Assuming that JIRA states are meant to be disjoint and that the names actually bear some meaning, "In Review" would mean "Not in Progress". Which already would be an interesting message to the reviewer. Like, "whatever you do here, that's not considered 'Progress'". Of course, nobody intents to bui^H^H^Hsend such message, and that's easily solvable, by either dropping the connection between state names and meaning, or by dopping the disjointness of states. What do you prefer? > > Already now there are tasks that get prioritized, and assigned, and > > re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened > > several times. Watchers that e.g. wait for a "Done" there get notified > > each time on such unprogressing transitions, and skipping these sums > > up to quite a bit of unproductive time already now. > > True enough; this would introduce one more transition, so one more > e-mail per bug. None the less, it's a transition that does mean > something useful to those watching - especially those waiting for a fix > - we are a significant step closer to a fix, Is is? First, being on review might still not mean getting closer to 'Done'. Patches get rejected or delayed for real or imagined reasons, nobody might actually review, a successful review might not be convincing enough for CI to let it pass etc, etc. Second, water-level reports on how close something is to being done is practically never the reason why I watch tasks, I watch them because I may need to act once it is resolved. And only then. > and there's a patch they might even be interested in applying > locally. And, as Lorn pointed out, issues don't have to go through > every stage; it'd just be there for the benefit of those who find it > useful. And to the distraction to those that don't. That's why the 'Verified' state was removed not that long ago. > Yes, we could do that with a tag, although I'm not sure how well Jira's > "scrum board" view would integrate with that. In any case, adding such > tags would generate mail, just as state transitions would, and > cluttering Jira with a plethora of person-specific and team-specific > tags We have "Reported_by_X", "Y_thinks_this_is_a_P1", "up", "Earmarked_by_Z", and a lot more. And it's completely fine to have them. The rule to handle them is easy: "If you are not fully convinced it is meant for you it /is/ not meant for you". > might not be the clearest way to communicate with folk; in > particular it'd mean there's no uniform way for teams to communicate > this, making it harder to write tools that can be shared between teams > with similar work-flows. Can't comment here, as I don't know what kind of tools this refers to. > > Looks like we are getting to the actual problem here. It's not > > about development after all. > > No "getting to" about it - my original mail was quite explicit about > the point of the exercise being clarity of communication with my > scrum master (whose beard is plaited - I would not call his hair > pointy). I am positive an "Eddy-calls-this-Done" label will be explicit enough to communicate the fact that Eddy calls this "Done" within this particular relation. > We've had tasks where the actual coding was done in one sprint but > the review and integration (and waiting for merges up from one branch > to another) have happened in other sprints. Distinguishing those > parts of the work would make sprint organisation easier. Ok, more seriously: I think you want to communicate "I did what I can do here, for this period of time". This is a valid, and noteworthy state, but at the same time orthogonal to the existing JIRA states. It would also apply to an "Won't do", or "Invalid", or whatever else state you chose after working on the issue. This calls for some markup that is orthogonal to existing JIRA states, and a label provides that. > The co-ordination of development, and communication to stake-holders > of what's going on, are important parts of our process. To dismiss > them out of hand as "not about development" strikes me as painfully > limiting. Jira is a tool as much for our customers (reporting bugs > and getting feed-back on whether and when we're going to do anything > about them) and our managers as for us. [ . o O ( BINGO! ) ... ] > The addition of an "In Review" state would
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
> On 19 Feb 2020, at 10:45, Edward Welbourne wrote: > What's the harm in leaving the task in In Progress state while it's being reviewed? >>> >>> There is no harm, but being able to better distinguish the main development >>> phase of a large task from the review stage would benefit the 'pointy hairs' >>> [...] > >> Looks like we are getting to the actual problem here. It's not about >> development after all. > > No "getting to" about it - my original mail was quite explicit about the > point of the exercise being clarity of communication with my scrum > master (whose beard is plaited - I would not call his hair pointy). > > We've had tasks where the actual coding was done in one sprint but the > review and integration (and waiting for merges up from one branch to > another) have happened in other sprints. Distinguishing those parts of > the work would make sprint organisation easier. > > The co-ordination of development, and communication to stake-holders of > what's going on, are important parts of our process. To dismiss them > out of hand as "not about development" strikes me as painfully limiting. > Jira is a tool as much for our customers (reporting bugs and getting > feed-back on whether and when we're going to do anything about them) and > our managers as for us. The addition of an "In Review" state would make > it easier for me to communicate, to everyone with an interest in my > work, something that at least two of them have made clear they want to > know (and that I have commonly wanted to communicate). > I naively imagine other teams have similar needs. > > I'm proposing a uniform way to do that, for those teams that want it. Even when doing development (as opposed to the pointy-haired work), I benefit from having tools that help me to maintain a work-in-progress limit, that allow me to see what state the work someone else is doing is in (because I might depend on it or just be curios about it), or allow me to signal to customers waiting for the fix that they might want to have a look at a proposed change, even if they don't have an account on Gerrit. The Qt Project defines “code review” as an explicit step that contributions have to go through. Given that it takes a substantial amount of time to get things through review, I think it would make the JIRA-model of how work happens a bit more useful if it would reflect the way that work actually happens. So, I support introducing this as an optional state. Cheers, Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote: >> Stepping through the interim steps is not a requirement, so it is not that >> much difference to go from Reported->In Progress to Reported->In Review, >> really. >> >> So the list you have to select from has one more entry to choose from, is >> that such a big deal? André Pönitz (18 February 2020 20:39) > This is not the problem. > > More states lead to bikeshedding what would be The Right State for a > task. I very much doubt the distinction between In Progress and In Review is going to involve much bike-shedding. > Already now there are tasks that get prioritized, and assigned, and > re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened > several times. Watchers that e.g. wait for a "Done" there get notified > each time on such unprogressing transitions, and skipping these sums > up to quite a bit of unproductive time already now. True enough; this would introduce one more transition, so one more e-mail per bug. None the less, it's a transition that does mean something useful to those watching - especially those waiting for a fix - we are a significant step closer to a fix, and there's a patch they might even be interested in applying locally. And, as Lorn pointed out, issues don't have to go through every stage; it'd just be there for the benefit of those who find it useful. Yes, we could do that with a tag, although I'm not sure how well Jira's "scrum board" view would integrate with that. In any case, adding such tags would generate mail, just as state transitions would, and cluttering Jira with a plethora of person-specific and team-specific tags might not be the clearest way to communicate with folk; in particular, it'd mean there's no uniform way for teams to communicate this, making it harder to write tools that can be shared between teams with similar work-flows. >> > What's the harm in leaving the task in In Progress state while it's being >> > reviewed? >> >> There is no harm, but being able to better distinguish the main development >> phase of a large task from the review stage would benefit the 'pointy hairs' >> [...] > Looks like we are getting to the actual problem here. It's not about > development after all. No "getting to" about it - my original mail was quite explicit about the point of the exercise being clarity of communication with my scrum master (whose beard is plaited - I would not call his hair pointy). We've had tasks where the actual coding was done in one sprint but the review and integration (and waiting for merges up from one branch to another) have happened in other sprints. Distinguishing those parts of the work would make sprint organisation easier. The co-ordination of development, and communication to stake-holders of what's going on, are important parts of our process. To dismiss them out of hand as "not about development" strikes me as painfully limiting. Jira is a tool as much for our customers (reporting bugs and getting feed-back on whether and when we're going to do anything about them) and our managers as for us. The addition of an "In Review" state would make it easier for me to communicate, to everyone with an interest in my work, something that at least two of them have made clear they want to know (and that I have commonly wanted to communicate). I naively imagine other teams have similar needs. I'm proposing a uniform way to do that, for those teams that want it. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Tue, Feb 18, 2020 at 01:11:29PM +1000, Lorn Potter wrote: > On 18/2/20 6:03 AM, Thiago Macieira wrote: > > I'm with Alexandru here: all ideas to have more states in JIRA start with a > > good intentions, but eventually people stop using them and just transition > > through all stages in one go when they've finished the work. For example, > > people realise they've never changed from Reported to Confirmed before they > > actually submitted the fix and autotest to Gerrit. I often do that and the > > task goes from Reported to Confirmed to In Progress in 5 seconds. With your > > proposal, it would go through yet another state in that period. > > Stepping through the interim steps is not a requirement, so it is not that > much difference to go from Reported->In Progress to Reported->In Review, > really. > > So the list you have to select from has one more entry to choose from, is > that such a big deal? This is not the problem. More states lead to bikeshedding what would be The Right State for a task. Already now there are tasks that get prioritized, and assigned, and re-prioritized, re-assigned, "Fix-for-version"-ed, closed, re-opened several times. Watchers that e.g. wait for a "Done" there get notified each time on such unprogressing transitions, and skipping these sums up to quite a bit of unproductive time already now. > > What's the harm in leaving the task in In Progress state while it's being > > reviewed? > > There is no harm, but being able to better distinguish the main development > phase of a large task from the review stage would benefit the 'pointy hairs' > [...] Looks like we are getting to the actual problem here. It's not about development after all. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Mon, Feb 17, 2020 at 09:13:17AM +, Edward Welbourne wrote: > 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. > [...] > Does anyone have any objection to this, or suggestions for a better way > to handle the relevant work-flow transition ? This situation can be handled by you adding an 'Eddy-calls-this-done' label. There's precendence for that, and this can even be applied to arbitrary other states, without affecting anyone else. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On 18/2/20 6:03 AM, Thiago Macieira wrote: >> I'm with Alexandru here: I confess I'd understood Alexandru as saying he'd wanted similar in the past but not been allowed it. Perhaps I misunderstood ... >> all ideas to have more states in JIRA start with a good intentions, >> but eventually people stop using them and just transition through all >> stages in one go when they've finished the work. For example, people >> realise they've never changed from Reported to Confirmed before they >> actually submitted the fix and autotest to Gerrit. I often do that >> and the task goes from Reported to Confirmed to In Progress in 5 >> seconds. With your proposal, it would go through yet another state in >> that period. Lorn Potter (18 February 2020 04:11) replied: > Stepping through the interim steps is not a requirement, so it is not > that much difference to go from Reported->In Progress to Reported->In > Review, really. ... and, likewise, to close a bug straight from In Progress, when that arises. I'm not suggesting this should be a state you *have to* pass through, only that it be available. > So the list you have to select from has one more entry to choose from, > is that such a big deal? Well, yes, it's one more thing; and a slow accretion of "one more thing" additions will always add up to hassle. So each addition must deliver more value than its incremental contribution to that hassle. >> In all projects I know, the fewer state transitions, the better. That's clearly not True - there's surely such a thing as taking it too far (eliminating all transitions, after all, would cripple a bug tracker) - but I agree that "fewer = better" subject to the constraint of Getting The Job Done. I recognise that what I'm asking for isn't utterly indispensable (like the transitions between Reported, Accepted and Resolved), but I believe it would improve some work-flows and thus deliver more value than its cost, much like the In Progress state itself. >> What's the harm in leaving the task in In Progress state while it's >> being reviewed? There is a significant transition in what I'm actually doing, that isn't reflected in the Jira state. This matters a lot to me, to my scrum master and, to a lesser degree, to other members of our team. I admit it's mostly irrelevant to everyone else, including the reporter. > There is no harm, but being able to better distinguish the main > development phase of a large task from the review stage would benefit > the 'pointy hairs' (I imagine) because the review process timeline is > often out of the control of the developer, and as we all know, often > takes very many iterations. At least that could see that a particular > bug is being held up not by the developer, but by the review > process/CI. Right - and we can split up a task into several stages (reflecting the practical reality of how we actually do work towards resolving issues in Jira) when planning our work and communicating to other stake-holders about how we're moving towards giving them what they want. > It also helps developers as we could search through 'In-Review' bugs > to find interesting bugs that need review. I hadn't thought of that ;^) Of course, folk can search Gerrit for reviews waiting for attention, but this would let them actually tie their search into Jira's knowledge of which things are high priority, or affect the code they're most familiar with. So searching for interesting reviews one could contribute to would be easier. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On 18/2/20 6:03 AM, Thiago Macieira wrote: I'm with Alexandru here: all ideas to have more states in JIRA start with a good intentions, but eventually people stop using them and just transition through all stages in one go when they've finished the work. For example, people realise they've never changed from Reported to Confirmed before they actually submitted the fix and autotest to Gerrit. I often do that and the task goes from Reported to Confirmed to In Progress in 5 seconds. With your proposal, it would go through yet another state in that period. Stepping through the interim steps is not a requirement, so it is not that much difference to go from Reported->In Progress to Reported->In Review, really. So the list you have to select from has one more entry to choose from, is that such a big deal? In all projects I know, the fewer state transitions, the better. What's the harm in leaving the task in In Progress state while it's being reviewed? There is no harm, but being able to better distinguish the main development phase of a large task from the review stage would benefit the 'pointy hairs' (I imagine) because the review process timeline is often out of the control of the developer, and as we all know, often takes very many iterations. At least that could see that a particular bug is being held up not by the developer, but by the review process/CI. It also helps developers as we could search through 'In-Review' bugs to find interesting bugs that need review. -- Lorn Potter Freelance Qt Developer. Platform Maintainer Qt WebAssembly, Maintainer QtSensors Author, Hands-on Mobile and Embedded Development with Qt 5 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On 17/2/20 7:13 PM, Edward Welbourne wrote: 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. +1 -- Lorn Potter Freelance Qt Developer. Platform Maintainer Qt WebAssembly, Maintainer QtSensors Author, Hands-on Mobile and Embedded Development with Qt 5 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
On Monday, 17 February 2020 01:20:43 PST Alexandru Croitor wrote: > Last time I brought this up, I was told that it would complicated the states > / transitions, and was deemed won't fix. > > I hope you have more luck. I'm with Alexandru here: all ideas to have more states in JIRA start with a good intentions, but eventually people stop using them and just transition through all stages in one go when they've finished the work. For example, people realise they've never changed from Reported to Confirmed before they actually submitted the fix and autotest to Gerrit. I often do that and the task goes from Reported to Confirmed to In Progress in 5 seconds. With your proposal, it would go through yet another state in that period. In all projects I know, the fewer state transitions, the better. What's the harm in leaving the task in In Progress state while it's being reviewed? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
Sounds like a good idea. It also would be nice to integrate this change with gerrit somehow. For example, if you push non-WIP changes and add reviewers, an associated task should be moved to "In Review" state automatically. On 2/17/20 10:13 AM, Edward Welbourne wrote: > Hi all, > > 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. > > 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 ... > > Eddy. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development -- Best Regards, Fanaskov Vitaly Senior Software Engineer The Qt Company ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: more Jira states to track stages of the work on an issue
Hi, Last time I brought this up, I was told that it would complicated the states / transitions, and was deemed won't fix. I hope you have more luck. > On 17. Feb 2020, at 10:13, Edward Welbourne wrote: > > Hi all, > > 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. > > 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 ... > > Eddy. > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Proposal: more Jira states to track stages of the work on an issue
Hi all, 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. 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 ... Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
