Issue workflow?

[vrataf]

As an administrator of Czech mutation of Cyclestreets ( http://www.cyklistesobe.cz/ ), I have reported following request from boards of several our groups: They want some tool to track which issues were submitted to officials, resolved, declined, etc.

I tried to find this topic in the issue list here, but without success - so I am creating a new one.

Generally, most of issues have similar workflow: They are proposed first, then discussed on the website, then submitted by some local group as a proposal to local officials, and then (sometimes) resolved. For processing of dozens of issues by the group - and also as an information for members, an "issue status" would be nice - especially if such operations like listing or sorting by status were implemented.

I see that such proposal creates connection between particular issue and group: I am not absolutely sure if this connection trough the status should be 1:1 (not good if more groups covers the area) or 1:n, so any group covering the area could set the status of the issue separately (can be confusing for non-members) - probably the second approach is cleaner.

I know that a selection of important issues is covered by priority setting, however, this is something different. Also, tags can be used this way (some people from Prague local groups actually do it), but it is not systematic, and issues cannot be sorted by the status.

So I propose to add following features:

• Any issue can be chosen by the group and then its status is assigned to one of (vaguely) following values: [ no-link | assigned by group = group is willing to do something with it | submitted to officials & waiting to response | submitted & responded | submitted & postponed or declined | closed - resolved | closed - dismissed by group | closed - from different reason | "whatever-the-group-considers-to-be-usable" ].
• Status could be changed by group board members.
• on an issue page, issues can be filtered by the status.
• the same on the map
• this feature should be optional, particular groups could decide if they want to use it.

Also, I don't see further consequences of direct connecting issues with group - it can be probably useful also for different purposes.

[gravitystorm]

I think we definitely need some kind of workflow/status, since at the moment issues are 'open' forever (even if they are completely fixed!) and, as you say, there's no way to track the progress of potential solutions.

We've never really discussed this. At the original design meeting we sort of ignored it since we were (rightly) focused on making sure people were actually going to use the system in the first place!

I'd like to keep the complexity to the very minimum though. I don't want to make complicated state-change flow charts or have lots of different statuses which will put off small groups and casual users. But I can see that some groups might want more than others.

We already have one object that makes the link between issues and groups, and that's message threads. If it's possible I'd like to have any group-specific statuses attached to threads. This also means that if one issue requires 3 different things to be done, each 'thing' can have their own thread and therefore their own status. And by using threads for status, we don't need to implement another ton of group-privacy options.

(Also, an 'issue' can only either be 'still an issue' or 'not an issue', it's the /solution/ that can be proposed, submitted, postponed etc hence my preference for threads).

[mvl22]

I think we definitely need some kind of workflow/status, since at the moment issues are 'open' forever

I have always thought that the key solution to this is:

1) Have a new reply type (alongside text reply, image, link, deadline etc.), available to Committee members which lets them mark the discussion as closed. This would be useful anyway - I've certainly needed this a few times with my Camcycle Committee hat on - and others have commented on the need for this.

2) If all discussions on an issue across all groups are marked as closed, the issue would state "Resolved - all discussions closed" or similar, and perhaps be listed separately. (I suppose there is the question of how to handle discussions which are group-private though.) A key point to bear in mind is that different groups may rightly have different views on whether a reported issue is actually solved to their satisfaction.

And by using threads for status, we don't need to implement another ton of group-privacy options.

+1 very strongly.

[vrataf]

gravitystorm, mvl22: Yes, we also do not need something overcomplicated (however, it has to be quite intuitive). Sticking with threads seems OK, so I agree with mvl22's proposal.

If Committee members would be able to set group threads as closed, then simple issue logic could work (like no group discussion = unassigned, all group discussion closed = resolved for the group). Then, filters can work in thread lists and maybe a tool for Committee members to close all open threads at once can be added.

However, there is one thing I lack: this way we cannot easily mark that something was submitted to the officials (or some similarly important step was done). I'd like have functionality like find proposals to the office made more 30 days ago... But, maybe, it could worg following way: the status could be modified by new reply type (text + status change), with possible stautus values { no-follow | step done | closed } . Then:

• issues could be sorted to categories { unnassigned | in processing | resloved - all thread closed }
• open threads could be listed by the time of the last step done.

I am not sure if such management can be already done using deadlines - maybe we can better use deadlines, like "setting today+30 days: letter sent, they have 30 days for reply." However, I don't feel this to be very clear for users, who would probably prefer just to add "workflow" reply "letter sent".

[mvl22]

See also #169 where the suggestion of a reply-type which aims to identify the role (i.e. responsibility) of key individuals subscribed to a thread more clearly is raised.

[vrataf]

I have asked my colleagues to read this issue and issue https://github.com/cyclestreets/toolkit/issues/169, and join the discussion here to see which proposal will work for them.

[krizvasa]

I´m vrataf´s colleague. I am skeptical about capability of groups to move forward with submiting issues to officials. I believe more in potential of active individuals than groups. To be sure (as administrator) that issue was submited to officials, I will ask user who created the issue by email.

Groups are not that important for me in the system. Most of submissions to officials are done by active members whether they are/are not in the group.

I prefer to simplify and use following statuses: [ no-link | submitted to officials | resolved].

Status could be changed by user who added an issue and administrators of the site on an issue page. issues can be filtered by the status. the same on the map this feature would be obligatory.

This would be easier to understand for users and if they don´t get it, administrator can do it instead of them with no much effort. I would not connect statuses with 30 day timing.

I also needed several times (as author of an issue) and I would like to have possibility to add arbitrary user (who is not member of the group) to group-private thread of issue

[mvl22]

Dear both,

Sorry that I've been slow in responding - the last 4 weeks have been a never-ending stream of work. I'm catching up now with other important things like this. I've still to do a full response to this and the other thread.

Groups are not that important for me in the system. Most of submissions to officials are done by active members whether they are/are not in the group.

Cyclescape has been designed to operate in both a groupwise and an ungrouped mode. In some places, there will be strong groups already existing (e.g. Cambridge Cycling Campaign here), where the democratic basis of such a group leads to long-term sustainable. Other times, more ad-hoc working works well.

Will respond properly shortly - sorry for the long delay on this. It is high priority for me.

[mvl22]

I think we definitely need some kind of workflow/status, since at the moment issues are 'open' forever (even if they are completely fixed!) and, as you say, there's no way to track the progress of potential solutions.

Yes. The Cambridge group is certainly starting to see reported issues being resolved, now that they have been on the system for a while. (It's a sad state of affairs that even getting a small patch of cycle parking can take two years to achieve in the UK, but there it is!)

It would definitely be useful to be able to mark a thread (and have this propagate to an issue in the absence of any other group's thread being present and open) to de-promote these issues in listings and on the map.

[mvl22]

If Committee members would be able to set group threads as closed, then simple issue logic could work (like no group discussion = unassigned, all group discussion closed = resolved for the group).

Yes, it sounds like we are all agreed on this.

[mvl22]

However, there is one thing I lack: this way we cannot easily mark that something was submitted to the officials (or some similarly important step was done). I'd like have functionality like find proposals to the office made more 30 days ago...

One way to do this would be for the attachment upload to include a field for setting the date with an associated description (i.e. "Reply expected by [date]"). This way the date functionality is strongly associated with the document to which it relates, and the date can be set with very little extra effort. Then...:

But, maybe, it could worg following way: the status could be modified by new reply type (text + status change), with possible stautus values { no-follow | step done | closed } .

I like this. I think what you're saying is that there would be a new reply type. Clicking to select that type would show the list of unresolved replies, e.g. the two documents for which no letter has been received back from the authorities. Next to each, a radio button set to amend the status could be present, e.g. "Response now received" or "A reminder has been sent to the officials".

Equally, a new document added could have a control which allows that same change to be made. This, a new document could be marked as being the awaited reply.

I am not sure if such management can be already done using deadlines - maybe we can better use deadlines, like "setting today+30 days: letter sent, they have 30 days for reply." However, I don't feel this to be very clear for users, who would probably prefer just to add "workflow" reply "letter sent".

Hopefully my suggestion above could use the same code infrastructure as the deadline system. Thus, when the deadline system adds support for sending reminder e-mails, e.g. "Meeting coming up in two days", similarly it could send reminders like "Letter to the municipality does not seem to have received a reply - someone needs to follow this up".

@krizvasa Do you think this set of changes would be workable?

[mvl22]

I am skeptical about capability of groups to move forward with submiting issues to officials. I believe more in potential of active individuals than groups.

I think this is a cultural thing which is dependent on history and geography. Cambridge for instance has a very strong group culture which has come about over many years of collective work and over 1,000 members. It is hoped in these cases that Cyclescape would help increase the cohesion and strength of such groups.

In other places, groups may not exist, or as you suggest may not be that important. That is not at all a problem, and indeed one of the key aims of Cyclescape is that it should provide a platform that will help join together isolated individuals who do not yet know each other, so they can work together increasingly as a collective body that creates momentum.

So we designed the system to ensure that both models of working work equally well. Although this does lead to some tensions in the design of the system, e.g. the need for group privacy and groups who require a full-names-visible policy, I think the site can certainly be effective for both ways of working.

[mvl22]

Status could be changed by user who added an issue and administrators of the site

Yes, in the ungrouped context, it seems sensible to me that the original author effectively gains administrative rights in this way, since she started the discussion.

[mvl22]

I would not connect statuses with 30 day timing.

I agree. I don't think statuses should be changed automatically due to some kind of timing system. Timing should merely be a reply type that has the ability to be filtered on and do things like sending emails when things are overdue.

[mvl22]

I also needed several times (as author of an issue) and I would like to have possibility to add arbitrary user (who is not member of the group) to group-private thread of issue.

Agree on this: it is much needed. Though it's a separate matter really - could you create a new Github issue for that?

[vrataf]

I am also sorry to delayed reply (some misunderstanding in who will reply here ). I try to make short summary:

We all agree that following fucntionality would be added:

1) Changing status of a thread (e.g. marking as closed)

2) Status can be changed by group Commitee member. Or by administrator or by founder of the thread when the thread is not connected with any group.

3) Status can be changed when document or deadline is added, or by a new reply type.

4) Issues, where all topics are closed, may be de-promoted in lists and in map. (The detailed logic is also not tuned yet)

Not clear aspects of (3):

I think what you're saying is that there would be a new reply type. Clicking to select that type would show the list of unresolved replies, e.g. the two documents for which no letter has been received back from the authorities. Next to each, a radio button set to amend the status could be present, e.g. "Response now received" or "A reminder has been sent to the officials".

Equally, a new document added could have a control which allows that same change to be made. This, a new document could be marked as being the awaited reply.

I don't understand this too much. Does this mean that the status would be assigned to every particular reply and document in the thread (when set)? I supposed that the overall status of the thread would be simply set by the last status change.

I am also happy to understand that there is no necessity to use the system in "groups mode" only. However, in the ungrouped mode, there are two roles for account with rights of administrator: 1) "technical" administration of accounts, groups, etc. and 2) "everyday" administration of issues and threads. I think these two roles should be distinguished somehow (it is probably topic for new issue here - should I create it?)

[mvl22]

We all agree that following fucntionality would be added:

1) Changing status of a thread (e.g. marking as closed)

2) Status can be changed by group Commitee member. Or by administrator or by founder of the thread when the thread is not connected with any group.

4) Issues, where all topics are closed, may be de-promoted in lists and in map. (The detailed logic is also not tuned yet)

Good; yes. Agreed.

Bringing in @gravitystorm to see if he has any comments at this stage, before any work you might potentially fund would be begin.

[mvl22]

I think what you're saying is that there would be a new reply type. Clicking to select that type would show the list of unresolved replies, e.g. the two documents for which no letter has been received back from the authorities. Next to each, a radio button set to amend the status could be present, e.g. "Response now received" or "A reminder has been sent to the officials".

Equally, a new document added could have a control which allows that same change to be made. This, a new document could be marked as being the awaited reply.

I don't understand this too much. Does this mean that the status would be assigned to every particular reply and document in the thread (when set)? I supposed that the overall status of the thread would be simply set by the last status change.

Sorry, I agree I was not clear.

I was talking about the creation of a new type of reply, which we could call something like "Document awaiting reply" or similar.

Exactly like the other types of reply (e.g. text reply, add attachment, add link, etc.) this would not change the overall status of the thread. It would be independent of the overall thread status. This is because the issuing of a document and the receipt of a reply from the municipality often does not actually resolve the cycling problem at hand.

For instance, if some new cycle parking were wanted, an issue and thread would be created on that. A campaigner might write a letter to the municipality, asking if adding cycle parking would be possible in principle. The municipality would respond, and the campaigner would upload this response to the thread. However, there would still follow other correspondence, e.g. negotiation on the exact location, and other things. Perhaps 6 months later the cycle parking might actually appear. Only at that point should the administrator/owner of the thread mark the thread as closed.

So, I was thinking that a "Document awaiting reply" could be later "resolved" by a reply type "Resolve document awaiting reply" or similar. The documents still which had not received a reply would somehow be indicated, e.g. in a box listing outstanding matters on the right, or in red or something. But either way, all of this is independent of the overall thread status.

What are your thoughts?

[krizvasa]

I trust you guys. I agree. It is difficult for me to imagine proposed functionalities before I see them and use them.

@mvl22: your changes from 25 Jun are workable. and new reply type will be nice.

I am not sure if it is clear that Workflow option: "1:n, so any group covering the area could set the status of the issue separately" is better. than "1:1"

[vrataf]

Well, finally I understand.

@krizvasa: I think that group and thread should be connected 1:1 , else it will be too complicated. Other groups can make own threads.

@mvl22, @gravitystorm: So, I try to define clear proposal.

1) Changing status of the thread, incl. "closed". However, we need to distinguish isues that were resolved, and that were dismissed from various reasons (duplicity, poor proposal, denied by authorities, etc.). Thus, we need to define minimum set of statuses:

• no-status,
• assigned to group,
• closed - resolved.
• closed - unresolved (dismissed)
• closed - no result (see at (4), why).

2) Access to status change as above (Group commtee member can assign his/her group and then close "own" thread, Administrator can assign to any group and close any thread. Threads should be probably also unassigned, if not private for group.)

3) New type of reply "document awaiting reply" that can be resolved (individually)

• If someone tries to close thread with unresolved replies, there should be warning (or it could be prohibited, but I don't think it's necessary).

4) Filtering issues and their depromotion in map: The logic here fails to be simple. I propose three variants:

a) "strict logic" for issue (complicated). Issue status is developed using following logic: 1) unassigned = all threads no-status 2) assigned to other group = at least one thread assigned to any group 3) assigned to my group = at least one thread assigned to "my" group 4) resolved by my group = all group threads closed, at least one "closed - resolved", no "closed-dismissed" thread 5) dismissed by my group = all group threads closed, at least one "closed - dismissed", no "closed-resolved" thread 6) resolved completely = all threads closed, at least one "closed - resolved", no "closed-dismissed" thread 7) dismissed completely = all threads closed, at least one "closed - dismissed", no "closed-resolved" thread 8) closed with mixed results = all threads closed, at least one "closed - resolved", and "closed-dismissed" thread. 9) closed with no results = all threads closed - unresolved. Advantage: Issues may be drawn in the map with distinguished colors, we can easily make distinguished lists (especially 3, 8, 9 can be interesting for admins). Disadvantage: Complicated logic.

b) Simple isuue status for map and applying filters on threads and not on issues. Statuses for map: 1) unassigned 2) assigned to other group 3) assigned to my group 4) closed by my group (all group's threads closed) 5) closed completely (all threads closed) Then threads can be filtered simply by its status in (1). Advantage: Simple logic and usable Disadvantage: Cannot distinguish between resolved or dismissed issues (so does not solve request from (1).

c) Map like in (b), filters for issues like in (a).

[smsm1]

Issue closing has been requested on Twitter at https://twitter.com/lan3y/status/610488370939195392

[iainlane]

Hi, that's me mentioned in that last message.

I presented Cyclescape to our (www.pedals.org.uk) group meeting last night. One issue that was raised is about how we handle consultations on minor traffic amendments (e.g. changing times of parking bays). We get a fair few of these and, since issues never go away, if we add them all to Cyclescape then the map will eventually become overwhelmed. So currently some arbitrary filtering is needed on the side of the receiver (or if my issue #378 is resolved then on whoever is triaging these) as to what we pt onto Cyclescape and what is left off. Now, one thing is that these consultations always come with a deadline "Please submit your comments by xx/yy/zz" which is a few weeks in the future. If we have issue closing per this ticket, then it would be neat for us if the deadline could be used to /automatically/ close issues. This would mean that we can simply make issues for all of these consultations knowing that they will be hidden after a short while anyway, and then anyone who has subscribed to the relevant locations will have their chance to comment through us if they want to.