Daily Dev Admin

Daily Dev Admin

Email

• Exception notifications:

  • Search to see if there's an existing ticket
  • No? Create one
    • I generally just copy the exception message, request section and backtrace
    • Scrub out IP Address, Server, data/vhost and any sensitive params
  • Yes? Either just note that the exception happened again, mark as new, or ignore. I don't really have any good rules of thumb for how I decide this.
  • I ignore blog timeout errors, unless they become frequent enough that its annoying (daily is probably where I'd start to get suspicious).

• Exception notifications (spam):

  • We get exception notifications for things the spam-catcher catches.
  • Decide if its real spam
  • If so, take action
  • Go to the /admin/users/:id and ban the user
  • If its a spam request, report it to the site admins

• Cron errors

  • I generally ignore stalled? and replication stalled? messages at around midnight, or when they're isolated. If you see lots over an extended time period it might mean something us up. Drop in to #sysadmin and ask.
  • Ignore "unexpected parsing of exim line:" when its obviously a test request
  • Anything else: ticket and take appropriate action

• Transifex Notifications

  • Check with site owner and add member to team

• dev@wdtk emails

  • Read the message
  • Either fix the problem, or ticket it
  • Reply to keep them in the loop
  • Mention the issue in standup and/or sprint planning
  • Add notes to the sprint planning doc to discuss the issue if it warrants special attention

• clientsupport@alaveteli emails

  • Read the message
  • Ping Gemma if its something she can reply to
  • Either fix the problem, or ticket it
  • Reply to keep them in the loop
  • Mention the issue in standup and/or sprint planning
  • Add notes to the sprint planning doc to discuss the issue if it warrants special attention

• Gemnasium

  • Any alaveteli gems need updating?
  • Either:
    • bundle update GEM_NAME and make a PR if its a patch version bump, or if the update seems easy enough
    • Make a ticket if it looks more involved
    • Ignore if we've got the gem fixed under that version

GitHub Notifications

• Mark new issues as new
• Reply if there's something you can say, or if you think you might know what the issue is
• Just fix the issue if its trivial and you have some headspace for it
• Mark partner PR requests as awaiting review. If its their first PR, just say thanks and that we'll get to it soon as they might not understand the process.
• Add notes to the sprint planning doc to discuss the issue if it warrants special attention