We want to ensure that the CLI is human-focused. Once we allow for custom configuration files, computers can run jekyll build --config config_file.yml or whatever to get the configuration settings they want for that run. By limiting the number of switches which the CLI accepts, we will make jekyll help more readable and squash confusion over what each switch does, thus improving the overall usability of the
jekyll build --config config_file.yml
We want to document use-cases in a file in the codebase. If anyone wishes to re-instate a former switch or create a new one altogether, he or she must then argue that use-case and document it in this file.
Seems like the file could be over kill, where opening an issue and having a discussion over the use-case might be a bit more manageable, rather than having a file in the repo.
That's definitely true - it'd be one more thing to manage and keep track of. @mojombo suggested it because we want to ensure that everyone who comes to work on Jekyll with us shares a common understanding of what the jekyll CLI does and should do. More so we don't muck it up with too many switches :-)
Yeah, let's just pass on this for now. If we feel like we need to document our choices later, we should just do it closer to where the options are defined.