Example with slack_channel and slack_username in secrets.json

[jordan8037310]

Provided an example for slack_channel and slack_username to be added to secrets.json per #99

[pantheon-mentionbot]

@jordan8037310, thanks for your PR! By analyzing the blame information on this pull request, we identified @ari-gold, @joshkoenig and @greg-1-anderson to be potential reviewers

[joshkoenig]

No sure how I feel about having non-secret things in secrets.json. It's not really meant to be a config system.

Further, in my experience real world implementations often have multiple channels/etc going on, which to me is more intuitive and easier to deploy if expressed in code, versioned, and deployed per usual, rather than relying on config being deployed to all environments as well.

I put this in a line comment on #101, but maybe we can dig into the thinking behind this change here?

[jordan8037310]

Responded in #101, the issue here is that secrets.json is already looking for the information there, and I was just going off the assumption that was a good idea :)

[greg-1-anderson]

I originally wrote the code to use secrets.json as a place to store configuration for the same reason: since it is there and convenient. However, since this project is an "examples" project, the theory is that these are not tools that folks will track (e.g. get updates for); instead, folks will just make their own fork and customize to suit. It was therefore felt that non-secret constants can just be replaced right in the code. That's why we took out secrets-as-configuration the first time this was discussed.

If you have a single Quicksilver script that you want to use across multiple sites, you could make your own Quicksilver Scripts repository, and make configurable / re-usable scripts there. The Terminus Quicksilver plugin supports the notion of private / personal repositories.

[ccharlton]

Having an associated JSON config file within the Quicksilver integration [plugin] seems to be a common pattern here, so stick with that.