We should infer project context from the channel in which commands are being issued

[jeffreywescott]

@shereefb commented on Tue Jul 05 2016

If project name is missing we should infer from channel. For example, if we are issuing reflection commands in the project channel, there's no need to add the project name.

---

@prattsj commented on Sun Jul 10 2016

@shereefb: was thinking about this today during a chat w/ @bundacia about the retro changes in progress. do you think it also makes sense to go a step further and actually require that project-specific commands be issued from the project's channel?

---

@shereefb commented on Sun Jul 10 2016

It's a good question. I like the idea of relying more on channels for context.

I worry a little about the user experience of someone who is reviewing a bunch of projects, and having to navigate to different channels to log their project reviews. Gut sense, I think it simplifies things to use channel as a context.

---

@jeffreywescott commented on Sun Jul 10 2016

I'm against the idea of having to be in a certain channel to issue a command. That's just not how commands work. Furthermore, we will eventually have this same toolbelt of commands available from their terminal, so I don't want to go down a path where we're reliant on a chat context for certain information.

---

@prattsj commented on Sun Jul 10 2016

Sometimes, it is sort of how commands work. In a terminal, "context" is often drawn from the directory in which you're issuing the command.

---

@prattsj commented on Sun Jul 10 2016

I actually like this idea very much. It links the project-related activity in my mind as a player to this one specific space (and only this space) for discussion with my project's team. We don't have any working directory to look to for additional context as needed the way that a program might when a command is issued in a terminal, and it seems the room name can serve that purpose well by reducing the cognitive load for the user and, in a very practical sense, by reducing typing effort required by anyone who currently needs to specify project names due to being in multiple projects.

---

@prattsj commented on Sun Jul 10 2016

...we will eventually have this same toolbelt of commands available from their terminal, so I don't want to go down a path where we're reliant on a chat context for certain information.

A requirement for pulling the project name from the channel a command issued in in Echo and a requirement for cleanly supporting a terminal command line interface aren't mutually exclusive.

I'm just thinking...if we infer project name from the room at all...then it seems safest for the user that we do it this way exclusively. It's not hard to imagine a player on multiple teams accidentally issuing a command meant for one project in the room for another project. Sure, players on multiple teams would then have to switch channels, but that seems easier to me than having to type project names all the time, and when I think about how little effort it requires to switch between, say, the #los and #player-support channels in LG slack, I'm not concerned about it at all.

---

@jeffreywescott commented on Sun Jul 10 2016

The risk of someone making a mistake is much higher when we infer things ... if we force people to be explicit, then they'd have to explicitly type the wrong project to do something wrong. Furthermore, because project names are prefixed with #, they auto-complete, so the typing to me doesn't seem to be a huge burden.

When you say "do it this way exclusively", do you mean we shouldn't allow them to pass a project name to override it? I don't like this -- I really want the command syntax to remain consistent across different environments -- it's much less cognitive load that way. I imagine that (long term) many commands will be preferable to issue inside of echo (like /vote), whereas others will make more sense to do from the terminal (like /review). But regardless, I don't want the users to have to know different command syntaxes depending on where they are.

I'm okay with having a notion of "context", which in echo could be the channel that they are in, in the terminal might be the git repo they are in, etc. But context should be able to be overridden. It's kinda like if I'm in a certain directory and I type ls I get a file list for that directory, but if I do ls /tmp I get the list of files in /tmp.

---

@prattsj commented on Sun Jul 10 2016

Ok. So...project-specific commands should be issued from within a project channel, from which we'll infer project name by default but which can be overridden with an explicit project name param? And an attempt to make a project-specific command outside of a project channel without specifying the project would throw an error?

---

@jeffreywescott commented on Sun Jul 10 2016

That sounds about right.

[jeffreywescott]

Longer-term, we're moving away from chat-based UI. Closing.