Skip to content

Define expected commands #15

Open
Open
@mattstratton

Description

@mattstratton

A lot of this is sorta stubbed out, but I think that it makes sense, in order to work through the UX, to add all the commands and basics in the cobra stuff.

Here's what I think the high level command are:

  • config Returns the current configuration
  • doctor Check that everything looks good
  • event Create or modify an event
  • program Create or modify a program
  • speaker Create or modify speakers
  • sponsor Create or modify sponsors
  • version Return the current version of the tool

The main commands (event, program, speaker, and sponsor) all have sub-commands of add and edit, for consistency.

Add and edit commands for event, program, and speaker will take in either city year as arguments, or prompt for them. The add and edit commands for sponsor will take in the sponsor name as an argument or prompt for it.

Edit event should prompt and say "what field do you want to modify" or something. And then act on it. so maybe something like:

>event edit chicago 2017
Do you want to [1] edit the value of a field, [2] add an organizer, or [3] add a sponsor?
>1
Fields you can edit are [1] Event Twitter, [2] Google Analytics Tracking ID, [3] start date, [4] end date ... 
>1
The current value of your event twitter is devopsdays. Would you like to change it? (Y/n)
>Y
What should the new value be?
>@ponyville
Great! The new value has been set. 
Don't forget to use git to add, commit, and push up the new branch for review

The good things? We can validate fields as they are entered. The bad? The list of fields could get REALLY LONG.

What's going to end up happening is going through all the if cases (edit an organizer vs add one, how do they add sponsor levels?, etc)

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions