Skip to content

Define consistent scheme for Short command descriptions #1777

@shrink

Description

@shrink

Describe the feature or problem you’d like to solve

The Short parameter used for commands is inconsistent and most do not provide any information beyond what is already provided through the name.

CORE COMMANDS
  gist:       Create gists
  issue:      Manage issues
  pr:         Manage pull requests
  release:    Manage GitHub releases
  repo:       Create, clone, fork, and view repositories

gist is described as Create gists yet you can also view and edit gists,issue describes "managing" issues and repo lists the functionality supported.

Proposed solution

Decide on a standard for the Short name.

I think there's a few different options, each of which has pros and cons. The conclusion I've come to is that because the CLI is typically used by power-users ("Goodbye, context switching.") that the best Short description has high information density.

Listing all of the commands supported could be automated (e.g: Short could simply be a dynamic comma separated list) which would reduce the maintenance burden, however it might become unwieldy as new functionality is added -- pr already has 12 supported commands.

Another option could be to pick a subset of the commands that provide enough context to inform the user about the depth of support, for example pr supports reopen which provides an indication that status can be managed so reopen (+2 more) is as useful as reopen, close and ready.

Another option could be to describe the resources as products/features: I don't think that provides as much value to power-users, but as the CLI functionality expands and new product lines are introduced it might become more valuable -- if I didn't know what a gist is, I'd benefit from this approach.

Product Description

CORE COMMANDS
  gist:       Share content privately or publicly
  issue:      Keep track of tasks within your team
  pr:         Participate in living conversations about changes
  release:    Package software for people to use
  repo:       Keep and collaborate on code with GitHub

Curated List

CORE COMMANDS
  gist:       create, edit, list and view Gists
  issue:      create, list and close Issues (+3 more)
  pr:         create, review and merge Pull Requests (+9 more)
  release:    create, download and view Releases (+3 more)
  repo:       clone, create, fork and view Repositories

Complete List

CORE COMMANDS
  gist:       create, edit, list and view
  issue:      close, create, list, reopen, status and view
  pr:         checkout, checks, close, create, diff, list, merge, ready, reopen, review, status and view
  release:    create, delete, download, list, upload and view
  repo:       clone, create, fork and view

Additional context

Definitely not a big issue, just some polish! I'm happy to PR any changes that are agreed upon: creating an issue first for discussion per the contribution guidelines. After working through this issue I've decided I like the curated list ((+n more) option) most.

📄

Metadata

Metadata

Assignees

No one assigned

    Labels

    docsenhancementa request to improve CLIneeds-designAn engineering task needs design to proceed

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions