Checklists

A checklist is a group of steps that you run whenever the project reaches a milestone, such as before a push or a release. Each step is a prompt, such as a security review, a docs update, or the release itself. Each run of a step is an ordinary autonomous task, which goes through the Execute, Questions, Review, and History tabs like any other.

Checklists are on the Checklists tab of the Tasks tool. To add one, click + Checklist at the top of the tab, or below the explanation shown when a project has no checklists. Each checklist is named for when its steps are run, and its dialog offers common names such as Before Push, Before Merge, and Before Release, or you can type your own. Click a checklist's header to fold or unfold it.

Steps

To add a step, click + Step at the bottom of the checklist, or select Add Step... from the checklist's ⋯ menu. The step editor sets the step's title, its prompt, which is about the whole project, and its Kind:

To make a step from a task you keep retyping, right-click on the pending task on the Plan tab and select Save to Checklist.... The task's first line becomes the title and its text the prompt, and the task is left in place.

Each step's row has a checkbox that includes the step when its checklist runs. This setting is yours alone, so other developers who share the step can leave it out. The row also shows the step's kind, its last result, and a run button. The result is one of:

A * after the result means that the step was edited, or the repository has changed, since that result. Click the result to show the report of the task that produced it. The checklist's header summarizes its last run.

The ⋯ menu on a step's row offers Edit..., Duplicate, Move to Checklist, Shared, and Delete Step.... The ⋯ menu on a checklist's header offers Add Step..., Rename..., Run Sequentially, Shared, and Delete Checklist.... To reorder checklists or steps, drag them by the grip at the left of the header or row. Dragging a step onto another checklist moves it there.

Sharing Steps

The step editor's Shared with everyone working on the project checkbox is checked by default. A shared step is stored in your own file in the project's TASKS/checks directory, which Wing adds to version control and includes in its commits whenever it changes. An unshared step is stored in the per-user project file (.wpu), and only you see it. This is independent of Share Plan; see Sharing Tasks via Version Control.

To make a checklist and your steps in it personal, or shared again, uncheck or check Shared in the checklist's menu. A new checklist is shared, but goes into your file only once it has a shared step, so an empty one is never committed. Each developer's shared steps are in a file of their own, so changes that two developers make at the same time merge without conflicts. Wing removes your file from the project and from version control when you have no shared steps left. Deleting a shared checklist deletes it for everyone once the change is committed.

Other developers' shared steps are hidden by default, along with their checklists that hold none of your steps. When there are any, a filter icon to the left of + Checklist shows no other users (the default), all other users, or the users checked in its list. Their steps and checklists then show the developer's name. Before you edit, move, or delete another developer's step, or rename or delete their checklist, Wing asks you to confirm, because the change is made in their file. Hidden steps are not run with the rest of their checklist.

Running Checklists

Run All on a checklist's header runs its checked steps, and the run button on a step's row runs just that step. Checklists can also be run from the Run Checklist submenu of the toolbar's Lightning Bolt menu, or by asking the Tasks Manager to run one by name. You can also ask the Manager to list the checklists, to run a single step, or to add, change, or remove one of your steps.

Wing makes each step into a task in a Checklists goal. While the Tasks Manager is on, the tasks are marked Ready for the Manager to schedule. Otherwise, they go in a new queue of their own, named like Before Push run 14:02, which runs them one at a time in the checklist's order. Each task ends by reporting a verdict of pass, issues, or fail, which becomes the step's result.

Action steps wait until the other steps have finished, and are not run if any of them failed or ended without a verdict. Issues do not hold them back.

When steps depend on the work of earlier ones, check Run Sequentially in the checklist's menu. Each step then starts only once the one before it passed, with Action steps last. A step that finds issues files a task to fix each one, and these run before the next step starts. A step that fails, or a fix task that ends without finishing its work, stops the run. This setting is shared with the checklist.

Reviewing a Run

The Review tab shows each run of a checklist in a section of its own, headed by the run's name and its verdict, such as "4 passed, 1 with issues: Ready to Push" or "Not Ready to Push". A run is ready when none of its steps failed or ended without a verdict. The ready phrase comes from the checklist's name, so Before Release gives "Ready to Release". Each step's report is shown with its task.

Mark Run Complete moves the run's tasks to the History tab, and their results stay on the Checklists tab. On the History tab, grouping by goal shows each run as a section of its own.