getTaskDescription = (name: string) => {
  // NOTE: This information is currently derivable, and it's bad to store
  // derivable data in the reducer... but, I expect soon this info will be
  // editable on a project-by-project basis, and so we will need to store this
  // in the reducer.
  switch (name) {
    case 'start': {
      return 'Run a local development server';
    }
    case 'build': {
      return 'Bundle your project for production';
    }
    case 'test': {
      return 'Run the automated tests';
    }
    case 'eject': {
      return 'Permanently reveal the create-react-app configuration files';
    }
    case 'format': {
      return 'Runs a formatter that tweaks your code to align with industry best-practices';
    }
    default: {
      return '';
    }
  }
}
NOTE: I built this reducer trying to think of it as a database model.
Each task has a unique ID, and is a child of a project.

In practice, it's felt like a lot of trouble to keep this "flat" table
of entities.

When it came time to do the same thing for dependencies, I decided to go
with a "nested" structure, where the top-level keys of the `dependencies`
reducer are all project IDs, and it holds a simple map of the dependencies
for that project

It felt much simpler and easier to work with, so I should probably update
this reducer to match that reducer's style. Right now they're inconsistent
and that's bad.