Fundraising/Bug Triaging

From Wikitech

Phabricator

For general information about how Phabricator is used, check out mw:Phabricator/Help.

Below are specific instructions for what we in fundraising are doing with it.

Creating a task

Anyone can create a task for Fundraising Tech: Create a task with the project tag Fundraising-Backlog.

You can also use this link. It has all the necessary information pre-filled. https://phabricator.wikimedia.org/maniphest/task/create/?projects=fundraising-backlog

Please tag additional projects if there's relevance (for example, if you encounter something problematic in Civi, tag Wikimedia-Fundraising-CiviCRM).

Writing bugs

Please put [BUG] in the title of the task if you think something is not working as it should (this will help me triage)

  1. The more specific a bug is written, the better. When writing reports, the following information is really helpful:
    1. Expected behavior vs. actual behavior - be as specific as possible. A few minutes of time defining a bug as you're experiencing it could save hours of time figuring out what the actual issue is.
    2. For example, if a page isn't loading, saying "it times out" or "a white page loads" or "I got a 505 error" is way more helpful than "it doesn't work".
    3. Specific numbers are really helpful as well in the case that something is off (like reconciliation or information in the Dash)
  2. Is it reproducible? How much of the time does it happen? If you can narrow in on exactly how to make it happen, that's really really really useful.
  3. How critical is this - some metrics might include # of people effected (for example if donors, how many are complaining), how crippling is the problem, etc. This will help the team prioritize working on it
  4. OS/Browser - this is especially true for problems like alignment, clicking not working, etc.

Screenshots

Screenshots are really helpful to help us debug anything user-facing. One recommendation is to use Skitch, in which you can blur confidential info, highlight, annotate, etc.

Task workflow

General

  1. All new tasks appear on a triage list. The team looks at this list at least once a week (usually more).
  2. Tasks will be prioritized by the product manager.
  3. During each sprint planning, tasks will be chosen for the next two weeks and added to the Sprint project
  4. When a task is "closed" in any project, it will close in all projects.

Per sprint

  1. All tasks will start in "Backlog". Once they have been fleshed out enough (requirements, acceptance criteria, and estimate) for tech to work on them, they will be unassigned and the tech team can pick from the list.
  2. FR-Tech will move the cards from Backlog to Deployed.
  3. When a task is finished, Anne (or other reporter) will verify that it's finished and close the task.

Fundraising projects

Dashboards

You can use "Dashboards" in Phabricator to show yourself relevant information on your Phabricator home page.  It's very customizable, but a little confusing (like oh so many things). Here's generally how: mw:Phabricator/Help/Dashboards.

You can add the Fundraising Stakeholder Dashboard. This should give you a view of tasks you have created, tasks you are watching and general Fundraising Tech Info.

Prioritization

Unbreak Now! / Emergency: Something that is currently live, is causing one of the following things:

  • Unexpected service outages
  • Parts of the donation pipeline are broken in a way that donors can see.
  • Critical data loss
  • Failing jenkins/cron jobs
  • Donor services is suddenly buried under an avalanche of email about the issue
  • Security issues (including fraud)

High / Must Have: If this item isn't done or fixed by the campaign launch date, we will have to move the campaign launch date. Must Have should also include issues that will definitely escalate to "emergency" status over time, and non-critical data loss.

Normal / Should Have (bug): If this item isn't done or fixed by the campaign launch date, somebody will have to regularly manually intervene in the automated system... but launch will still be possible.

Normal / Should Have (feature): Will accomplish one of the following:

  • Free up significant personnel time through automation
  • Make us an extra dumptruck full of money
  • Solve a significant mystery. This could be extra visibility into some piece of our system, or constitute something both large and new to test (think Mobile donations).

Low/Lowest / Nice To Have: Gosh, having this thing would be swell. <--the vast majority of everything ought to land in this category.

Retrieved from "https://wikitech.wikimedia.org/w/index.php?title=Fundraising/Bug_Triaging&oldid=2109201"