Opened 8 years ago

Closed 7 years ago

Last modified 6 years ago

#4658 closed Feature/Enhancement Request (fixed)

Trac Modifications for Next Support Phase

Reported by: Ross Owned by: Daniel Kahn Gillmor
Priority: Medium Component: Tech
Keywords: trac automation support.mayfirst.org Cc:
Sensitive: no

Description

We need to make a few modifications to trac for the next phase of support (Mayfirst's Ross Phase). We need to run a query against the database that says something like: UPDATE {ticket table} SET status = closed

WHERE

  • Ticket not opened by a support_member (which needs to be defined)
  • Last commented by a support_member
  • Last comment happened more than 3 weeks ago

We also need to create a cron job that will perform the same query in the future, and add an automated comment to the ticket that says, "This ticket has been marked 'fixed' due to inactivity. If the problem still remains, please re-open this ticket."

I'm assigning this ticket to dkg. If you wouldn't mind, dkg, I'd like to schedule a time to work on this together so I can at least know how to futz around in our pgres db.

Thanks,

Ross

Attachments (2)

scheduledworkflow.py (3.7 KB) - added by Daniel Kahn Gillmor 7 years ago.
ScheduledWorkflow plugin
scheduledworkflow.2.py (3.7 KB) - added by Daniel Kahn Gillmor 7 years ago.
updated revision (uses subcommand syntax)

Download all attachments as: .zip

Change History (62)

comment:1 Changed 8 years ago by Jamie McClelland

Owner: changed from dkg to Daniel Kahn Gillmor

I'm re-assigning to dkg's OpenID - which will alert him about the ticket.

jamie

comment:2 Changed 8 years ago by Ross

Ah ha! Lesson number 1.

comment:3 Changed 8 years ago by Daniel Kahn Gillmor

Keywords: support.mayfirst.org added

I'm not convinced that this is a legitimate approach. There are tickets that i know i've commented last on that i believe to be still legitimately outstanding (including some that are assigned to myself).

perhaps what we really need is some thoughts about how to handle the ticket workflow that enables us to set tickets to a "pending" state that will be closed if the reporter doesn't respond in a certain amount of time.

I'm pretty opposed to automatically closing tickets just due to the last-posting being from a support-team member.

Another approach you might be aiming at is to just get a list of open tickets that have *not* been answered most recently by a support-team member. This seems like a good use of a query, if possible, but it's a different thing from mucking about in the workflow state.

comment:4 Changed 8 years ago by Ross

I very much like the idea of adding another state to tickets. In fact, I think adding a couple of different states might be in order. One for "pending," which would be for tickets that have been assigned but not fixed by a support team member. The other state would be "inactive" for tickets that have been responded to by a support team member but not marked fixed, but have not been updated for 3 weeks.

If a ticket gets marked as "inactive" (in the automated fashion suggested above), an email would go out to those on the ticket saying, "Hey, this ticket has been moved to an inactive state. If the problem has been fixed, please close the ticket or re-open as necessary."

The algorithm could be a bit more complex as well, where only bug reports get put into the inactive state. Feature requests seem like a longer term type of ticket, whereas bugs either get fixed or don't.

comment:5 Changed 8 years ago by Daniel Kahn Gillmor

The state machine is pretty complex already, and people get confused by it, i think. Maybe propose a concrete set of changes to the [ticket-workflow] section of moses:/srv/trac/support/conf/trac.ini?

Here is the current config:

[ticket-workflow]
accept = new -> assigned
accept.operations = set_owner_to_self
accept.permissions = TICKET_MODIFY
leave = * -> *
leave.default = 1
leave.operations = leave_status
reassign = new,assigned,reopened -> new
reassign.operations = set_owner
reassign.permissions = TICKET_MODIFY
reopen = closed -> reopened
reopen.operations = del_resolution
reopen.permissions = TICKET_CREATE
resolve = new,assigned,reopened -> closed
resolve.operations = set_resolution
resolve.permissions = TICKET_MODIFY

comment:6 Changed 8 years ago by Jamie McClelland

I just opened #4669.

I think we have two distinct issues:

  • handle all the currently open tickets that should be resolved (#4669)
  • change our trac instance so that tickets that should be closed are automatically closed moving forward (this ticket)

Maybe if we come up with a clever enough solution to this ticket, #4669 will be moot. But for now, they seem like two issues.

comment:7 Changed 8 years ago by Jamie McClelland

Resolution: fixed
Status: newclosed

As for workflow... I'm not sure how trac works or the ease of modifying the work flow... however, I think we can describe the problem as:

Many times a support team member answers a ticket and is pretty sure that they have fixed it, however, not sure enough to outright close the ticket (which seems pretty harsh). If they close the ticket, some users feel like that's the end of the story and don't realize they can reopen it. If they leave the ticket open, it stays open forever.

To describe what I think would be a way to resolve this problem (described from the user perspective):

  • The actions box at the bottom of each ticket would have a new option in the resolved as drop down called "fixed-pending-review"
  • A cron job would run daily searching for such tickets and any ticket in that resolution with the last comment more than 2 weeks old, would automatically change the resolution to fixed
  • If anyone viewed a ticket in that status, it would be just like viewing a closed ticket - in other words, the default option would be to re-open the ticket. So, anyone who makes any comment would effectively re-open the ticket.

The only real change would be that members would get a ticket response saying that their issue has been changed to "fixed-pending-review" rather than just "fixed". It's a small change, but perhaps all that we really need to address the problem.

comment:8 Changed 8 years ago by Jamie McClelland

Resolution: fixed
Status: closedreopened

Woops! I was looking at the drop down options and accidentally closed this ticket!

But that's good - because I realize that the default action on a closed ticket is "leave as closed".

For tickets that are closed with resolution "fixed-pending-review" the default action should be re-open.

jamie

comment:9 Changed 8 years ago by Daniel Kahn Gillmor

your proposal is to put the new state as a new form of resolution instead of as a new "top-level" state.

Are we actually asking for an explicit review? if the reporter responds by providing a review that says "yep, works for me" should we re-open it by default?

this seems confusing to me.

I think i'd prefer to use a new top-level state "pending", which encourages an explicit change to either closed or re-opened.

comment:10 Changed 8 years ago by Daniel Kahn Gillmor

what do y'all think of the "simple optional generic review state" as presented in the trac workflow examples? We could change the name and tweak it a bit if we want to, but it seems to make sense to me.

comment:11 Changed 8 years ago by Ross

I agree with dkg on this. I would like to have another top-level state as well. What I would suggest is adding another form of resolutions which is "Closed due to inactivity" or something like that. This way we could differentiate tickets closed by the cron job and those closed by the wack jobs.

I think I would also like the cron job to move tickets from a new state to a pending state based on the same criteria it uses to move from pending to closed or to move all new tickets from "new" to "pending" on an ownership change.

The track sample workflow makes sense to me.

comment:12 in reply to:  4 Changed 8 years ago by Daniel Kahn Gillmor

Replying to https://id.mayfirst.org/ross:

I think adding a couple of different states might be in order. One for "pending," which would be for tickets that have been assigned but not fixed by a support team member.

How does this differ from the "assigned" state?

The other state would be "inactive" for tickets that have been responded to by a support team member but not marked fixed, but have not been updated for 3 weeks.

I'm not sure this warrants a new state, since it's computable from the existing state we have. I think the "responded to by a support team member" is a heuristic that implies that a support team member response effectively puts the responsibility for the ticket back to the reporter. This seems like it would discourage support-team members from contributing suggestions out of fear that those suggestions would be implicitly treated by the system as conclusive answers.

It seems like an improvement would be to ask support team members to set these expectations explicitly. One way to do that would be to regularly re-assign the tickets to their reporter when we think the situation is worth closing and just needs sign-off. But there are other reasons you might want to re-assign to the reporter than just terminal review, so i don't think that is sufficient either.

The algorithm could be a bit more complex as well, where only bug reports get put into the inactive state. Feature requests seem like a longer term type of ticket, whereas bugs either get fixed or don't.

I'm not sure we have a bright enough line between feature requests and bugs to make this nuanced workflow change worth the extra confusion it might cause (e.g. "what the -- i swear there is usually an "inactive" state available here...")

comment:13 in reply to:  11 Changed 8 years ago by Daniel Kahn Gillmor

Replying to https://id.mayfirst.org/ross:

I agree with dkg on this. I would like to have another top-level state as well. What I would suggest is adding another form of resolutions which is "Closed due to inactivity" or something like that. This way we could differentiate tickets closed by the cron job and those closed by the wack jobs.

wack jobs? :P

What if we could set a resolution with the "pending" status, and that resolution would take hold if the cronjob fired?

I think I would also like the cron job to move tickets from a new state to a pending state based on the same criteria it uses to move from pending to closed or to move all new tickets from "new" to "pending" on an ownership change.

hmm. i think the move to "pending" should be an explicit, manual move. The move from "pending" to "closed" is what we should automate. I'd be willing to take a stab at reviewing and moving a dozen open tickets to "pending" per week; with 5 people doing that, we should have the backlog mostly marked down by the end of the year.

So, putting all this discussion together and trying to digest it, my proposal is:

  • add a new "pending" state indicating that we think the ticket is done, but a final review is desired -- allow setting of resolution in that state.
  • the only way out of "pending" should be "reopen" or "resolve"
  • a cronjob runs nightly, moving all tickets that have been in "pending" for X amount of time to "closed" with the chosen resolution.

---

hmmm, now that i'm thinking about it this way, i can also see the appeal of Jamie's proposal in comment:7 Ross, what do you think?

comment:14 Changed 8 years ago by Ross

I still like the idea of having another top-level state, and I want the pending state to occur automatically. For me a meaningful workflow would create a state change once a ticket has been acted on, whether that's commenting on it or reassigning it. My sense is that a ticket in a "new" state, should be literally a "new" ticket. "Pending" should be intermediary between the ticket getting opened and it getting closed.

And I also think there needs to be an explicit "closed automatically" tag of some sort.

As far as cleaning up the current queue, I propose a ticket closing party or two. It might be pretty helpful to the support team as a whole for us to explore old support tickets together.

comment:15 Changed 8 years ago by Daniel Kahn Gillmor

Status: reopenednew

what does "pending state to occur automatically" mean?

by having a state change when a ticket is acted on, that's not automatic -- it's part of the action taken on the ticket.

The current state transition for a ticket is usually:

  • new (just opened)
  • assigned (someone is working on it explicitly)
  • close (the ticket is done)

comment:16 Changed 8 years ago by Daniel Kahn Gillmor

Status: newassigned

comment:17 Changed 8 years ago by Daniel Kahn Gillmor

there is also an additional state (reopened) which is when a closed ticket gets unclosed. It behaves like "new", for the most part.

My proposal adds a new state called "pending" (name open for discussion), which allows setting a resolution. the only way out of "pending" is to either "reopen" or "close".

the automated job would move from "pending" to "closed" if a ticket has been idle in "pending" for long enough.

If you'd like, we could have the automated job append a keyword like "autoclosed" to the ticket's keywords.

comment:18 Changed 8 years ago by Daniel Kahn Gillmor

My idea is that an assignee who is sure of their fix sets the ticket to "resolved" and chooses a resolution. An assignee who is fairly confident of their changes but not completely sure sets the job to "pending" and chooses a resolution, to encourage a followup if the reporter wants to give one.

The cronjob would clean up old/idle "pending" tickets.

then the "ticket party" would consist of people trying to set tickets to "pending" which seem like they are probably resolved but haven't gotten a final confirmation.

comment:19 Changed 8 years ago by Ross

I see what you mean. Ideally though, I'd like to have tickets move into a pending state if they had been commented on by a support team member as a way to say, "Someone is working on this ticket."

The difference between you're view and mine is the need for the assignee to manually set their tickets to pending. I don't see a big difference between, I've started working on this and I think this is fixed. Clearly we already have an issue with closing tickets, another forced manual change seems likely to create the same exact problem, except now we have more options for people not to use.

comment:20 Changed 8 years ago by Daniel Kahn Gillmor

I think there is a *huge* difference between "i've done some work/thinking about this" and "i think this is fixed"

If i felt that every time i commented on a ticket the system would assume i meant "i think this is fixed" i would be much more wary about commenting here.

comment:21 Changed 8 years ago by Daniel Kahn Gillmor

Resolution: fixed
Status: assignedpending

I've gone ahead and made the change i proposed -- it turned out to not be terribly complicated. and i cleaned up the existing ticket workflow as well (assigning tickets now puts them in state "assigned", and you need TICKET_MODIFY instead of TICKET_CREATE to reopen a ticket).

The new [ticket-workflow] section has:

{{{[ticket-workflow] accept = new,reopened -> assigned accept.operations = set_owner_to_self accept.permissions = TICKET_MODIFY leave = new,reopened,assigned,closed -> * leave.default = 1 leave.operations = leave_status reassign = new,assigned,reopened -> assigned reassign.operations = set_owner reassign.permissions = TICKET_MODIFY reopen = closed -> reopened reopen.operations = del_resolution reopen.permissions = TICKET_MODIFY resolve = new,assigned,reopened -> closed resolve.operations = set_resolution resolve.permissions = TICKET_MODIFY pending = new,reopened,assigned -> pending pending.operations = set_resolution pending.permissions = TICKET_MODIFY pending.name = pending review }}}

I'm setting this to "pending" because i think this is done.

If you find yourself saying "but what about the cronjob‽", then you should probably re-open it :)

comment:22 Changed 8 years ago by Jamie McClelland

Resolution: fixed
Status: pendingreopened

I don't feel strongly one way or another about adding a new resolution status (fixed-pending-review) or having a new state (the generic review state dkg pointed us to seems to fit the bill). I think I favor the new state, especially since it's seems to be sanctioned enough by the trac developers to be on their wiki.

I think the terms pending and review are being used somewhat inter-changeable in our conversation adding to some confusion.

Adding a review top level state addresses what I initially identified as the problem (in ticket:4658:7). I think we should refer to this as "review" not pending.

I think the "pending" issue is addressing a different problem, namely: is anyone working on this ticket or is it just blowing in the wind? Ross - if this is not the problem you are addressing with "pending" let me know :).

Here's a workflow that I think would address it:

  • New tickets on creation get assigned to the (not-real) "intake" user
  • Ross re-assigns tickets daily either to himself or to other members of the support team.
  • Support team members who can't take a ticket assigned to them, re-assign to intake
  • Any ticket that is older than N hours or has it's last comment older than N hours AND is assigned to intake gets assigned to ross.

I agree with dkg that tickets should only be automatically closed if they are explicitly placed in the review state. If a ticket is assigned to me it's my responsibility to evaluate whether:

  • I can't do it - so re-assign to intake
  • I can do it in a timely fashion (post a comment saying so or just start doing

And, when done, either close the ticket or put it in pending review state.

I also like adding a new resolution of "closed automatically" - although not sure how to implement it in a way that doesn't show up in the user interface but is still available for the cron job (perhaps some kind of javascript).

p.s. I've been trying to post this comment for the last 15 minutes but you all keep beating me to it :). In response to Ross' last point - the primary thing keeping me from closing tickets is not seeming to harsh when I'm really not sure I fixed the problem. There are some cases when I ask for more information and we never hear back - that's a real issue.

I think we could get around that by calling the state "feedback".

Basically, almost anytime a support team member is responding to a ticket with a comment other than (i'm working on it) they would change the state to feedback. The default state after a ticket is in feedback would be to return the ticket to "assigned" state?

p.p.s ok, another failed attempt to post my comment :). I'm re-opening because I'd prefer the state to be "feedback" rather than pending.

comment:23 Changed 8 years ago by Jamie McClelland

ah - now i see it's called "pending review" which is better than just pending.

But I still prefer "pending feedback" because it makes it more sensible if you are asking for more information as opposed to asking if it seems fixed or not.

comment:24 Changed 8 years ago by Daniel Kahn Gillmor

Resolution: fixed
Status: reopenedfeedback

OK, you've got it.

comment:25 Changed 8 years ago by Jamie McClelland

Resolution: fixed
Status: feedbackreopened

Re-opening just to see what the UI looks like...

comment:26 Changed 8 years ago by Jamie McClelland

Resolution: worksforme
Status: reopenedfeedback

More experimenting... I no longer think we should have tickets automatically closed from the feedback state have their resolution set to "automatically fixed" because it looks like I can set a resolution to "worksforme" and set it to feedback. I wouldn't want these automatically changed to "automatically fixed" i'd want it set to "worksforme".

comment:27 Changed 8 years ago by Jamie McClelland

Status: feedbackclosed

More testing...

comment:28 Changed 8 years ago by Jamie McClelland

Resolution: worksforme
Status: closedreopened

comment:29 Changed 8 years ago by Jamie McClelland

Owner: changed from Daniel Kahn Gillmor to Ross
Status: reopenedassigned

I'm now assigning to ross and then I will set to pending feedback.

comment:30 Changed 8 years ago by Jamie McClelland

Resolution: fixed
Status: assignedfeedback

comment:31 Changed 8 years ago by Daniel Kahn Gillmor

Resolution: fixed
Status: feedbackreopened

(re-opening because we still need the cronjob)

My thought was that you could set the status to "pending feedback" and the resolution to "fixed" (if you think it is probably fixed) or "worksforme" (if you think you've given enough information), etc. Then if someone explicitly closes it, your selected resolution will persist.

In my proposal, the cronjob that culls idle "feedback" tickets would also keep the existing resolution, but would append "autoclosed" to the keywords.

Also: your proposal of auto-assigning to a non-existent "intake" sounds like a good idea, except i don't like the institutional sound of "intake". What if we just set the assignment to the empty string instead? That would make it pretty clear that no one is assigned, and it is also in state "new", which is another good hint.

comment:32 Changed 8 years ago by Daniel Kahn Gillmor

I've added an explicit "relinquish" action that removes ownership of the ticket, and re-sets it to "new".

comment:33 Changed 8 years ago by Daniel Kahn Gillmor

note that we can adjust the order of the actions presented as well. Right now, the order of suggested actions on a reopened ticket is:

  • leave
  • resolve
  • relinquish
  • reassign
  • pending feedback
  • accept

Some thoughts:

  • we could drop the "accept" action entirely, since "reassign" defaults to the current user's OpenID, so it would effectively do the same thing. one fewer option seems cleaner.
  • it would be nice to offer "relinquish" only to the current owner of the ticket; but i don't know how to do that.

comment:34 Changed 8 years ago by Jamie McClelland

The autoclose key word is a great idea. I agree about dropping the accept action entirely.

This is looking good! I think we're getting there.

I have some suggestions for small language changes that are more designed to provide instructions on how to use the system rather than explaining what will happen.

Change from:

resolve as (fixed) => The resolution will be set. Next status will be 'closed'

Change to:

resolve as (fixed) => Close this ticket (if you believe it has been resolved)

Change from:

relinquish => The ticket will be disowned. Next status will be 'new'

To:

relinquish => This ticket is currently assigned to (...). If that's you and you can't address it, un-assign the ticket to indicate that it should be re-assigned to someone else.

Change from:

reasign to (...) => The owner will change from https://id.mayfirst.org/ross. Next status will be 'assigned'

Change to:

reasign to (...) => Re-assign to another user.

Change from:

pending feedback as (...) => The resolution will be set. Next status will be 'feedback'

Change to:

pending feedback as (...) => Request feedback. If no feedback is received in two weeks, the ticket will automatically close with the resolution you choose.

comment:35 Changed 8 years ago by Ross

Owner: Ross deleted
Status: reopenednew

Wow, this is amazing! Thanks guys. The only change I would like to see is moving the pending feedback to the second position. I think it makes more sense in terms of the general workflow progression.

I'm relinquishing control of this ticket to see what happens.

comment:36 Changed 8 years ago by Daniel Kahn Gillmor

Owner: set to Daniel Kahn Gillmor
Status: newassigned

I've removed "accept", and i've updated the ordering of the proposed actions to reflect what i think ross wants.

Jamie, you seem to be under the impression that we can trivially edit the gray/italic text after each action. Those texts are automatically generated based on the actions of the ticket workflow state machine. I don't think we *should* edit them, even if it was easy to do.

What we do have solid control over is the black text next to the radio buttons. any proposals for how those could be re-worded?

(hint: most people don't read the small/gray/italic text anyway)

I'd like to make the "relinquish" option only present if you are the ticket owner, but to do that we'd need to install the VirtualTicketPermissionsPlugin to be able to reference TICKET_IS_OWNER in the ticket-workflow section. Do y'all think this is a worth-while thing to do? It would make it so that people who aren't assigned the ticket wouldn't see the additional/confusing "relinquish" option. Let me know if you think that's a good idea.

I'm accepting this ticket since the cronjob is still unfinished, and i think i should probably be responsible for that.

comment:37 Changed 8 years ago by Daniel Kahn Gillmor

Our current list of Components with the default owner looks like this:

0 moses:~# su - www-data -c 'trac-admin /srv/trac/support/ component list'

Name             Owner                          
------------------------------------------------
Membership/Dues  https://id.mayfirst.org/jamie  
Outreach         https://id.mayfirst.org/alfredo
Tech             https://id.mayfirst.org/jamie  

0 moses:~# 

Should we set some of those default Owners to null for this workflow?

comment:38 in reply to:  36 Changed 8 years ago by Ross

Replying to https://id.mayfirst.org/dkg:

I'd like to make the "relinquish" option only present if you are the ticket owner, but to do that we'd need to install the VirtualTicketPermissionsPlugin to be able to reference TICKET_IS_OWNER in the ticket-workflow section. Do y'all think this is a worth-while thing to do? It would make it so that people who aren't assigned the ticket wouldn't see the additional/confusing "relinquish" option. Let me know if you think that's a good idea.

I think it's worth installing the plugin. Relinquish could be pretty confusing to users in general.

comment:39 Changed 8 years ago by Daniel Kahn Gillmor

OK, it'll probably be another day or two before i can get to that, but i'm going to try to package the plugin for debian and moses will be our test case for it.

comment:40 Changed 8 years ago by Daniel Kahn Gillmor

OK, i've gone ahead and packaged that plugin, backported it to squeeze, installed it on moses, and enabled it on SMO.

I see "relinquish" on tickets that i own, and i do not see it on other tickets.

So, the things that remain on this ticket, as i see them:

  • decide about any changes to the action text
  • think about the cronjob for moving things from "feedback" to "closed"
  • adjust the default owner of at least some of the default components

comment:41 Changed 8 years ago by Jamie McClelland

Sweet! Getting rid of relinquish for non-owners is a great move.

Bummer about not being able to change the italics/gray text.

I think the only action that is not at all intuitive is "pending feedback as".

How about changing to:

"request feedback, if no response resolve as [pick resolution]"

comment:42 Changed 8 years ago by Ross

I think the final thing that needs to be done with the default ticket processing is removing jamie as the default ticket owner.

My preference would be to have the no-owner as the default owner, which should allow me to filter for tickets new tickets that haven't been assigned, but avoid the thousands that are owned by jamie.

comment:43 Changed 8 years ago by Ross

Check that...could we make the default owner "New"?

comment:44 Changed 8 years ago by Jamie McClelland

Hey Ross,

Why would you prefer "new" as the no owner string?

I think setting owner to empty (i.e. null) might be a better option, since when someone relinquishes a ticket it gets set to empty. I think having those states be the same is desirable.

I also prefer it because it's more intuitive (if it's not assigned to anyone it means it's not assigned to anyone).

As for how to write the cron job... we would need to be able to modify tickets in an automated way from the command line.

There seems to be an XML-RPC plugin to trac, but I'm not crazy about that approach because I think we'd have to handle authentication which seems needlessly complicated.

One email list post suggests there is no command line trac options, it suggests we should write some python code and use the existing trac api's.

TicketToTracScript seems to do something close to what we want, but I think it only creates tickets, not modify them. TracCmdScript seems to do exactly what we want, but it seems to be just a command line wrapper to the XML-RPC code.

We could just write clever SQL queries.

Or, we could be the first to write an extensible trac + shell program in python for trac, which in the spirit of drush could be called.... trash!

jamie

comment:45 Changed 8 years ago by Daniel Kahn Gillmor

  • I've updated the text for the feedback transition to the longer string jamie described.
  • as for the "not being able to change the gray text" bit -- it's free software, we can change it if we want to. I just don't think it makes much sense to change it. That gray text is for people who are trying to understand the state machine model for the tickets in more detail. I think it should stay as it is, and we should provide the "friendly" (yet imprecise) text in the black text.
  • I welcome suggestions for improved text for "relinquish" -- the word makes sense to me, but i'm cognizant that i incline toward baroque vocabulary. :P
  • I strongly prefer an empty assignment over the string "new" for unassigned tickets. I think it reflects reality more clearly, and trac knows how to render it properly.
  • I hear that y'all think we should remove jamie from the default assignment -- but jamie *isn't* the only default assignment. depending on the "component", it could also be alfredo. Some options:
    • remove all default assignments (both jamie and alfredo)
    • only remove the default assignment from Tech to jamie (leaving Outreach and Membership/Dues auto-assigned)
    • remove all of jamie's default assignments, leaving alfredo as the point person for Outreach.

As for the cronjob: I think we should start with a simple python script that does raw database queries and modifications as needed. If we find ourselves needing some level of pre-written trac-specific features, we can pull in the trac python modules.

re: "trash": trac has had an shell-oriented administration program since its inception, called trac-admin. It's one of the reasons that i like the platform :) Apparently, as of trac version 0.12, this is an extensible tool as well. I don't think we want to upgrade to 0.12 right now, but it's worth keeping this in mind if our python script seems worth deploying to the outside world.

comment:46 Changed 8 years ago by Jamie McClelland

Thanks dkg for the text changes. I'm perfectly happy with how they are now. Relinquish works for me and there will finite number of people who will see that option for whom we can educate about it's precise meaning in this context (I might suggest "bail" as an alternative, but it's a little too judgmental :).

A simple python script sounds good to me for the cron job.

As for default assignments, I'd suggest we remove "outreach" as a component since it's rarely used. I'd suggest clearing me as the default for Tech tickets (no default assignment on tech tickets). And I'd suggest changing Membership/Dues so that the default assignment is https://id.mayfirst.org/hilary.

jamie

comment:47 Changed 8 years ago by Daniel Kahn Gillmor

Done:

0 moses:~# su - www-data -c 'trac-admin /srv/trac/support/'
Welcome to trac-admin 0.11.7
Interactive Trac administration console.
Copyright (c) 2003-2009 Edgewall Software

Type:  '?' or 'help' for help on commands.
        
Trac [/srv/trac/support]> component remove Outreach
Trac [/srv/trac/support]> component chown Tech ''
Trac [/srv/trac/support]> component chown Membership/Dues https://id.mayfirst.org/hilary
Trac [/srv/trac/support]> component list

Name             Owner                         
-----------------------------------------------
Membership/Dues  https://id.mayfirst.org/hilary
Tech                                           

Trac [/srv/trac/support]> 
0 moses:~# 

comment:48 in reply to:  44 Changed 8 years ago by Ross

Replying to https://id.mayfirst.org/jamie:

Hey Ross,

Why would you prefer "new" as the no owner string?

I think setting owner to empty (i.e. null) might be a better option, since when someone relinquishes a ticket it gets set to empty. I think having those states be the same is desirable.

In the default view tickets, if you filter by no owner, every owner appears. For me it would be better to have an explicit owner of the ticket just for UI ease. So even if the owner were no owner, the UI would be more effective. The ability to simply filter by owner "no-owner" would be better for me.

Or I'm sure there's a slightly more esoteric filter I could do. Probably something stupidly simple. So barring a "no-owner" owner, you could just school me in trac queries for all tickets with owner "/".

There seems to be an XML-RPC plugin to trac, but I'm not crazy about that approach because I think we'd have to handle authentication which seems needlessly complicated.

The one advantage of the XML-RPC is the emacs plugin see #3682. :-)

~/ross

comment:49 Changed 8 years ago by Daniel Kahn Gillmor

It sounds like you're saying that trac's query syntax should be able to support a search for "tickets with no owner", and it doesn't. Maybe that's a bug worth fixing explicitly rather than working around? what do you mean by 'all tickets with owner "/"'?

xml-rpc presents some authentication issues that i haven't looked into yet. have you examined how it would work in the context of mod_auth_openid authentication?

comment:50 Changed 8 years ago by Daniel Kahn Gillmor

since we're using openid, each legitimate assignment should have at least a / in it. so what about a query that shows all non-closed tickets without a "/" in the owner field?

comment:51 Changed 8 years ago by Ross

Looks like I was wrong about searching for no author. I used the wrong conditional when I was testing it out. If you do a search for "owner is " trac will in fact show the correct results, but if the conditional is "contains " it shows every owner.

I'm now fine with as the owner.

As far as xml-rpc goes, I'm okay with not implementing it. I attempted to find more info on mod_auth_openid authentication and xml-rpc but came up generally empty. So let's just table it.

comment:52 Changed 8 years ago by Ross

So it looks like we have most of the workflow issues in place. We still need to resolve ticket #4695, three ideas have been presented, but the right one has yet to be implemented ;).

I'm not sure, however, if we've implemented the cron job yet. This seems to be the most important feature for the new workflow to work. Where do we stand with this? Is there anything we need to do before putting the cron job in place?

comment:53 Changed 8 years ago by Daniel Kahn Gillmor

The xmlrpc discussion should take place on #3682.

The final nuances of ticket state should take place on #4695.

The remaining piece here is the cronjob, to move tickets from "feedback" to "closed". We need to know:

  • How often should the cronjob run, and when? (proposal: daily, at noon America/New_York time)
  • What keyword should the cronjob add to culled tickets? (proposal: "autoclosed")
  • What identity should changes made by the cronjob appear to be made by? (proposal: https://id.mayfirst.org/support )
  • How long should a ticket have remained in the "feedback" state to be transitioned to "closed"? (proposal: 1 week)
  • This will initially be a python script. It should be placed under revision control. Where should it get tracked? (i have no proposal here)
  • should e-mail notifications of these transitions go out to anyone? if so, who, and what should they say? (i have no proposal here)

comment:54 in reply to:  53 Changed 8 years ago by Ross

Replying to https://id.mayfirst.org/dkg:

  • How often should the cronjob run, and when? (proposal: daily, at noon America/New_York time)

Mmm...I was thinking daily, at midnight America/New_York (at least if I'm going to get the email(s) about closed tickets.

  • What keyword should the cronjob add to culled tickets? (proposal: "autoclosed")

Yes, I approve.

  • What identity should changes made by the cronjob appear to be made by? (proposal: https://id.mayfirst.org/support )

Yes, I approve.

  • How long should a ticket have remained in the "feedback" state to be transitioned to "closed"? (proposal: 1 week)

I think a week might be too short. Jamie and I had talked about 2 to 3 weeks. I think 2 would be sufficient.

  • This will initially be a python script. It should be placed under revision control. Where should it get tracked? (i have no proposal here)

It should probably get tracked on the server where trac is housed, no?

  • should e-mail notifications of these transitions go out to anyone? if so, who, and what should they say? (i have no proposal here)

I think an email should go out to the MFPLSB, to the Reporter, and to the person who made the last comment, if different from the reporter. It should say, "Ticket number X (hyperlink to the ticket) has been closed due to inactivity. If this issue has not been resolved, please re-open the ticket." Or something along those lines.

comment:55 Changed 8 years ago by Daniel Kahn Gillmor

Thanks for the quick feedback, Ross!

I'm fine with midnight over noon. i don't think i understand your reasoning, but i'm happy to just agree in blissful ignorance.

I'm fine with 2 weeks instead of 1.

i have no idea what you mean "it should probably get tracked on the server where trac is housed" -- trac the project is hosted by edgewall.org. support.mayfirst.org is hosted on moses.mayfirst.org. Yes, if we're deploying it to moses.mayfirst.org, then pulling from a revision control system (or, indirectly, via puppet from a revision control system) makes sense, but i don't think we want to host that system on moses directly, do we? for one thing, we aren't currently hosting any revision control systems on moses; do we want to start? And hosting all the revisions only on moses.mayfirst.org seems ripe for a single-point-of-failure scenario. If we lose moses and have to rebuild, we'd presumably want to be able to recover the cronjob from some other revision control system. So I'm asking what revision control system we want to use. My current sense is that the MF/PL revision control setup is a bit scattered between svn and git, and i have no idea what the current policy is for system-specific infrastructure.

an email should go out to the MFPLSB

Is there an e-mail address for the MFPLSB? If we're hard-coding something, i'd rather hard-code a role-based e-mail address rather than a personal e-mail address.

Changed 7 years ago by Daniel Kahn Gillmor

Attachment: scheduledworkflow.py added

ScheduledWorkflow plugin

comment:56 Changed 7 years ago by Daniel Kahn Gillmor

Sensitive: unset

I've just written a ScheduledWorkflow plugin, which adds a new subcommand to trac-admin.

With this plugin enabled, it should be possible to do the following from trac-admin:

Trac [/srv/example]> transition feedback closed 14
Transitioned 21 tickets from feedback to closed
Trac [/srv/example]> 

I propose we install this on moses.mayfirst.org and set up a cronjob to invoke it nightly.

Changed 7 years ago by Daniel Kahn Gillmor

Attachment: scheduledworkflow.2.py added

updated revision (uses subcommand syntax)

comment:57 Changed 7 years ago by Daniel Kahn Gillmor

I've update the plugin a bit, so the command should be:

transition do feedback closed 14 $USER "$COMMENT"

where $USER is the name of the user indicated as closing the ticket, and $COMMENT is the comment attached to the closure.

comment:58 Changed 7 years ago by Daniel Kahn Gillmor

Resolution: fixed
Status: assignedfeedback

OK, the plugin is installed in moses:/srv/trac/support/plugins/scheduledworkflow.py

and i've added moses:/usr/local/sbin/smo-scheduled-workflow which makes it simple to invoke the plugin from the shell.

Finally, i added a line to the per-user crontab for www-data@moses to /usr/local/sbin/smo-scheduled-workflow every day at 0:00.

I think this is done.

comment:59 Changed 7 years ago by automatic

Status: feedbackclosed

No news is good news (we hope)! Given the lack of feedback, we think this ticket can be closed.

comment:60 Changed 6 years ago by Daniel Kahn Gillmor

For future reference, I've published the scheduled workflow plugin at trac-hacks.org.

Please login to add comments to this ticket.

Note: See TracTickets for help on using tickets.