@[OSLL]

Questions on states and transitions:

• What's the reason to have 'reopened' state?
  • There surely have to be 'reopen' action, but imho it should make resolved -> active transition.
• What's the reason to have 'delayed' state?
  • Either issue assessor don't want to work on it anymore, then it should be reassigned to someone else or made unassigned
  • Or the task itself doesn't matter anymore. Then it should be resolved and closed with the appropriate comment.
• What's the reason to have a separate 'testing' state?
  • Isn't testing a completely separate activity?
  • If we include 'testing' state, shouldn't there be active -> testing and testing -> active transitions?

Question on roles: who does what? Especially, who's doing testing and who's closing?

• Reopen state is passive state like assigned. Active state means developer are working on the issue. It's possible another guy can transmit issue from resolved to reopened. In this case your question means can we add resolved -> assigned transmission. It's possible, but i think assigned and reopened are different

• I think a good idea to have an issue owner always. In another case it possible to have lots of hanged issues without attention. There is a reason to have delayed state. As an alternative we can transmit active to assigned but we will lose difference between new issues and issues that have been under work already.

• About testing i'm not sure. My idea was sometime we resolve issue but we have to monitor it. For example we've implemented some functionality in network driver and it works properly but it fails from time to time. Usually we have some stabilization period. We aren't working on issue actively, but we are not actually sure about closing it. I'm suggesting testing state to emphasize attention we pay to resolved issue. I can remove testing state from diagram if our understanding isn't clear.

• Roles is my next step. I think it will be easy: there are only two actors Creator and Assignee. Creator creates the issues and assignee does all work. everybody can close issue if he think it should be close. But useful practice is to reassign resolved issues to the Creator.

The practice of reassigning a resolved issue to the creator when thinking it should be closed seems to be a good idea. If we want to make it the only practice then there should not be testing -> closed and reopened -> closed transmissions, imho. Instead of them there can be testing -> resolved and reopened -> resolved transmissions.

If testing -> resolved transmission breaks the visibility of the states the task passed then another state like checked could be added. And checked issues would have to be reassigned to the creator, too, after what the creator would close it.

What do you think of that?

Resolved means done and waiting to close; I don't think we need checked state 'cause after checking in state resolved the issue transmits to reopen or closed. That fork covers all checking results: Yes(really fixed) and No(not fixed). About testing state please read above it state to signalize stabilization period... I can remove it if we haven't clear understanding here.
Arina, thanks for commitment

Ok, testing and reopened make sense to me.

• first for developer who wants to emphasize that he's been either testing or developing, switching between these activities as needed;
• second for the developer that has finished testing successfully.

Reopened -> closed transition is rather strange. What is the underlying scenario? (:

• if one cannot work on issue it must be reassigned or made new;
• if external conditions prevent work from being done, reject it, or make it assigned and move to another version.

Okay, I will update state chart ASAP

Now we have some strange situation: "resolved" are not completed, but there is no actions required to do with them. I think we should add state "checked" or make "resolved" state to be final. See also #239.

Aleksei Zlobin wrote:

Now we have some strange situation: "resolved" are not completed, but there is no actions required to do with them. I think we should add state "checked" or make "resolved" state to be final. See also #239.

resolved means developer thinks "all is done and works properly", but closed means "task creator thinks all is done"

Kirill Krinkin wrote:

resolved means developer thinks "all is done and works properly", but closed means "task creator thinks all is done"
So i should use "closed" state for tasks completed myself even if i think that they can be reopened?

Aleksei Zlobin wrote:

Kirill Krinkin wrote:

resolved means developer thinks "all is done and works properly", but closed means "task creator thinks all is done"

So i should use "closed" state for tasks completed myself even if i think that they can be reopened?

You should use closed for tasks which are completely done. Take a look at the picture http://osll.spb.ru/wiki/osll/_OsllWorkflow_