[Development] Proposal: more Jira states to track stages of the work on an issue

[Volker Hilsheimer]

> On 20 Feb 2020, at 00:08, André Pönitz <apoenitz at t-online.de> wrote:
> On Wed, Feb 19, 2020 at 10:43:17AM +0000, 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