CodeStream master plan

1) from the teams we speak to, code review is generally a somewhat formal process, and almost always involves code that is changing in the current sprint. with codestream, we want to enable continuous collaboration by making it possible to comment on (and soon create an issue on) any block of code at any time, whether it changed this sprint or not. so rather than trying to compete head-to-head with code review tools, we see codestream as complementary. with integration possibilities, perhaps even more.

2) the major difference between github PR comments and codestream-enabled comments are that a) codestream is in-editor (although there are some early plugins for PRs now), b) codestream is real-time (as compared to the email-like transactional semantics of web-based comments), but more importantly c) codestream comments allow you to talk about any part of the codebase at any time, not just what's changing in a given sprint, and d) codestream comments don't get buried when the PR is merged, they persist as annotations on your codebase even as your code changes. we're excited to see how this enables new modes of communication about code, although to be honest we don't yet have an idea what % of discussions that will represent. we hope a lot!

3) in the beginning, it's all human-driven. the next phase will introduce integrations with defect tracking tools such as trello, jira and asana, so that you can more easily create an issue on a block of code you're looking at in your editor. the third phase will be bot-driven or system-driven alerts which, given our integration into the editor, will be able to preserve context (repo, file, line, range), and optionally persist, and therefore hopefully become more powerful.