Working in Watari day to day

Watari is built so a support lead can run it without reading code. Three screens carry the work: Home, Issues, and the page for each issue. They use the same words for the same state, so what a row says on one screen is what the issue page says when you open it.

Home: what needs youCopy Anchor Link

Home is where you land. It has three parts.

• Needs you. Issues where the next step is yours, in two parts: You can do these (answer Watari, update the customer, send an answer, check a ticket that stalled before Watari could read it), then Waiting on your engineers, each newest first, so what just moved is at the top. Each row names the customer's company and where the report came from. An issue your team filed in its own tracker names no customer, and one you added by hand names the customer you typed in. A connection that stopped working is listed above them. Until setup is done, the setup block sits here: three steps (where reports arrive, your code, your first issue), each marked Done, Your move, Waiting or Not yet, with the one thing to do next. Owners and admins finish setup; a member sees who is doing it. When the first issue is in, the block becomes one line, Setup is done, with that issue, until you open it. Setup never comes back after that: a later problem shows here as a Needs you row.
• Watari is working on. Issues Watari is moving forward right now, such as looking for the cause or drafting a fix. Nothing is needed from you.
• Updates. The five newest things that happened in the workspace, leaving out issues already listed in Needs you. Filter by Issues, Setup or Team, and choose See all updates for everything, with Mark all read and an archive. A new workspace has no Updates section until something has happened.

The number beside Home in the sidebar is how many issues need you, plus one while a setup step is yours, the same number Home and Issues show in their headers.

Issues: sorted by whose move it isCopy Anchor Link

Issues opens in three groups:

• Your move: Watari asks a question, the customer needs an update, an answer is ready to send, Watari found nothing to change in the code and the issue can be closed, a fix is ready to review, Watari paused, or an engineer is needed. What a support person can finish comes first, then what waits on an engineer. The step buttons above the group show one step at a time.
• Watari's move: Watari is looking for the cause, drafting a fix, or the fix is shipping.
• Done this week: the customer has been updated, the issue was closed without an update, or the request was logged for the product team.

The header says how many need you and how many Watari is working on. All, Bugs, Requests, No fix needed and Not filed narrow the list. Filtering, sorting, or choosing Table switches to a table with bulk actions and CSV export. The table uses the same step words as the board, with the owner, the type, the severity and how long each issue has been open. Not filed lists support tickets Watari read and filed nothing from, with the reason, and an admin can click Read again on any that should have become an issue.

The issue page: one next stepCopy Anchor Link

Every issue page opens the same way:

1. The title and who reported it, with a link back to the original ticket or work item.
2. A staircase showing how far the issue has come: understood, cause found, fix, customer updated.
3. One next step, labelled Your move or Watari's move. When it is your move, the card says exactly what to do: answer Watari's question, review the fix, send the drafted answer, or bring in an engineer.
4. Meanwhile, tell the customer. A reply your team can copy and send now. It never promises more than is true: nothing says "fixed" before the fix is live. Once the customer update is written, this line goes away: the update is what you send.

Below the next step, each part of the work has its own section, labelled with the step it belongs to: what the customer reported, Where it happens in your code, the fix, and the customer update. Engineering detail, such as the branch, the build check and reviewers, sits under For engineers, and how Watari decided, timing and similar past issues sit in sections you can open when you need them. Press Esc to close an open section, and J and K to move to the next and previous issue in the order the Issues list shows them.

Status is Open, Won't fix or Closed. Choosing Won't fix or Closed moves the issue to Done. Watari marks an issue resolved by itself once its fix is live.

Telling Watari how the fix didCopy Anchor Link

Under a draft fix, Fix was right and Fix was wrong (or the A and R keys) tell Watari how it did. Nothing is approved, merged or closed on your code host. A note says what you marked, with Undo for six seconds; the answer is saved when the note closes.

When Watari needs a detailCopy Anchor Link

If Watari is missing one fact it needs to find or fix the problem, it asks one plain question, with answer choices where it can. It asks only what someone on your team can see in the product or knows from the customer, never to open developer tools or read logs. The question appears on the issue page and as a comment on the source work item when the issue came from your issue tracker. Answer it in Watari, or reply on the work item and mention @watariai, and Watari picks up where it stopped: it keeps what it already found and the files it already looked at, and works on what your answer changes. A reply that only asks something back, such as @watariai status?, is not taken as the answer: Watari replies with where the issue stands and the question it is still waiting on, and starts nothing. It never asks the same question twice, and it asks at most two questions about one issue; after that, the issue goes to an engineer with what is still unknown. You never need to relay the question by hand. Even without a question, a developer who knows where the problem is can reply on the work item mentioning @watariai with where to look, and Watari tries again with it, as a message sent to Watari from the issue page does. There is no limit on how many times Watari tries an issue: whenever someone adds something new, an answer or where to look, it tries again. Sending something the issue already has starts nothing, because the same inputs give the same answer. To keep costs predictable, Watari tries one issue at most five times in a day, and says when it can try again.

Sending the customer updateCopy Anchor Link

Once the fix is live, Watari writes an update for your customer, and the next step reads Update the customer until someone sends it or decides not to. Read and edit it in the customer update section, then send it or skip it. When the issue came from your issue tracker and only your team can see that issue, you can also do this where you already work: Watari's comment on the issue quotes the update, and a reply mentioning @watariai with send sends it as written, send: followed by your own text sends your version, and skip sends nothing. Anyone whose replies Watari already reads on that issue can do it, and Watari replies to say what happened. Either way the issue closes once the update is settled.

Where it happensCopy Anchor Link

Where it happens shows the places in your code that matter now, each marked Strong match, Possible match or Weak match. Once Watari has drafted a fix, it shows the files the fix changes; before that, it shows the strong matches. The other places Watari looked at are one click away, and each place's code is shown when you ask for it. If Watari is looking in the wrong place, the next step at the top of the page lets an owner or admin tell Watari where to look, in your product's words, or search again. Searching again is for owners and admins because a new search can make the issue a Mapped Issue. When none of your repositories is ready yet, the section says Watari can't search your code yet and why, instead of reporting that no code was found. When every place Watari looked at is a Weak match, the section is called Where Watari looked, the step at the top reads Weak match instead of a found cause, and Watari asks where in your product the issue happens.

Codebase: is your code readyCopy Anchor Link

Codebase has two tabs.

Repositories groups every connected repository by whose move it is, the same way Issues does:

• Your move: something only a person can fix, such as a branch that no longer exists, a repository that is too large, a read that stopped twice, or a subscription that needs paying. Each says what happened and shows one button.
• Watari's move: Watari is reading the code, with the time left, or is about to try a stopped read again by itself.
• Ready: Watari can search this code. Each push is read on its own.
• Turned off: the repository is over your plan's limit. Its issues stay, and nothing is deleted.

Open a repository to see its status, whether Watari drafts fixes in it, where its issues come from and who owns its code. Branches, the check that runs before a fix opens, languages and files sit under For engineers. Only owners and admins connect, remove or change a repository; a member sees who can. A removed repository's issues stay, and what Watari learned from its code is kept 30 days, then deleted.

Where issues come from lists the folders your issues point into, each issue counted once in the folder of its best match, with how many are your move and Watari's move and who owns the folder. Only strong and possible matches count; the page says how many weak ones it left out.

Insights: what Watari did this monthCopy Anchor Link

Insights counts one calendar month, with the month before beside it: reports that became issues, issues found in your code that got a draft fix, and fixed issues where the customer was told. It names one next step when something is waiting on your team, and Share this month opens a summary you can print or forward. Your first week explains each count.

---

Next: Your first week, what to expect as your first reports arrive.