6 ms·

(former Microsoft employee here) CodeFlow's workflow was nice, but everything else about it was _awful_. Capturing iterations, comments, threads, etc was the

(former Microsoft employee here) CodeFlow's workflow was nice, but everything else about it was _awful_. Capturing iterations, comments, threads, etc was the good stuff. The UI - eye-bleeding and amateurish. Network operations - terrible. Despite all that, the workflow was so good that I'd take it over github CRs in a heartbeat.

eyjafjallajokul 8y ago
For all of the people reading the article and trying to visualize the tool, can you summarize what about the workflow was so good?
- samirahmed 8y ago
  Contrasting to Github PR its a better process but really only a marginal impact on developer productivity. When i was there - Codeflow had the following feature - Multiple reviewer states ... accepted/reviewing/awaiting changes/decline to review/reject change. - Multiple comment states ... pending, won't fix, fixed etc. - Iterations based code review flow - after you review - you come back easily view the next iteration (relative diff) - you can really compare back and forth and track comments through iterations - github tends to loose comments through commits - Support for bots to comment like stylecop etc Codeflow workflow felt like an MS-Office application like Word or Outlook compared to Github - Heavy UI based workflow with no API/commandline counterpart sometimes - Desktop app - not website - Lots of knobs/states - Very easy to work back and forth in the UX I agree with an earlier comment however - the UX was pretty ugly - the workflow account for lots of states Github doesn't but there is a nice linear flow to the progression of a github conversion that (at least at the time i was there) . IIRC it was a managed .NET - WPF application which are kindy clunky - not as nice as a website with clear links etc.
  - pianoben 8y ago
    At least as of November 2018 (when I left), everything you said was still true. However! CodeFlow was also integrated into VSTS, whose review tooling is very much inspired by CodeFlow. Reviewers could use their web browser or the client app, and it all fed into the same system. Most of the features that set it apart from Github initially have been copied by now - comment threads with resolutions, individual reviewer states, etc, have all been recently introduced; the gap between CF and GH has shrunk substantially. That said, CF still does a better job of retaining comment threads and associating them with lines of code. Maybe it's just different UX decisions by the product teams, but it makes a difference when reviewing complicated patches.
  - deleted 8y ago
    [deleted]
ahartmetz 8y ago
As a contributor to a F/OSS project with some serious infrastructure (KDE), Github's uncontested success feels weird. It's a really anemic "solution" to the collaboration problem, especially with projects using it as their only collaboration platform. Most larger ones at least run mailing lists and a wiki or so. Some have a more sophisticated bugtracker, but most seem to stick with Github's... placeholder for one. Probably due to its integration with code review.
- machiaweliczny 8y ago
  I can recommend reviewable.io for github.
  - bogle 8y ago
    Don't look now as they're having trouble with dropping offline ...
    - piotrkaminski 8y ago
      All fixed! (And it only affected people signing in from two different browsers at the same time, which was actually a pretty small proportion -- which is why it took so long to find and fix the issue.)
- DaiPlusPlus 8y ago
  Github’s success stems from its simplicity imo. Pre-Github, projects would need to fire-up their own Bugzilla or Fogbugz instances, set-up all the project tracking criteria (areas, iterations, severity, etc). But unstructured label tags seem to work surprisingly well in practice: projects that would have otherwise demanded 20+ fields for work-item tracking now seem fine with issue labels.
  - pritambaral 8y ago
    > Pre-Github, projects would need to fire-up their own Bugzilla or Fogbugz instances, set-up all the project tracking criteria (areas, iterations, severity, etc). So a ready-made setup at an existing service open to multiple projects would work. I guess that's what Sourceforge was.
renholder 8y ago
>Despite all that, the workflow was so good that I'd take it over github CRs in a heartbeat. I have to agree, here, wholeheartedly. Put a bug in that would break the build? No worries, as soon as you kicked-off a CodeFlow, it would start a prod and smoke-test build for you. Everyone could also see those breaks and block the review from completing, until you fixed them in a new iteration. You would think that, with everyone moving (or having moved) from Source Depot to VSO/Git, CodeFlow would've falled into the deprecated products pile but because it was such a worthwhile utility, teams for entire products carried it forward, rather than relying on GitHub's CRs[1]. [1] - It became more of an amalgamation between the two [Source Depot and Git-basd-VSO] but CodeFlow was your one-stop shop to view it all.
- guitarbill 8y ago
  > No worries, as soon as you kicked-off a CodeFlow, it would start a prod and smoke-test build for you. Everyone could also see those breaks and block the review from completing, until you fixed them in a new iteration. This sounds exactly like PRs with status checks for protected branches (usually master)? Edit: Link with UI screenshots: https://help.github.com/articles/about-required-status-checks/ https://help.github.com/articles/about-required-status-check...

eyjafjallajokul 8y ago

For all of the people reading the article and trying to visualize the tool, can you summarize what about the workflow was so good?

samirahmed 8y ago
Contrasting to Github PR its a better process but really only a marginal impact on developer productivity. When i was there - Codeflow had the following feature - Multiple reviewer states ... accepted/reviewing/awaiting changes/decline to review/reject change. - Multiple comment states ... pending, won't fix, fixed etc. - Iterations based code review flow - after you review - you come back easily view the next iteration (relative diff) - you can really compare back and forth and track comments through iterations - github tends to loose comments through commits - Support for bots to comment like stylecop etc Codeflow workflow felt like an MS-Office application like Word or Outlook compared to Github - Heavy UI based workflow with no API/commandline counterpart sometimes - Desktop app - not website - Lots of knobs/states - Very easy to work back and forth in the UX I agree with an earlier comment however - the UX was pretty ugly - the workflow account for lots of states Github doesn't but there is a nice linear flow to the progression of a github conversion that (at least at the time i was there) . IIRC it was a managed .NET - WPF application which are kindy clunky - not as nice as a website with clear links etc.
- pianoben 8y ago
  At least as of November 2018 (when I left), everything you said was still true. However! CodeFlow was also integrated into VSTS, whose review tooling is very much inspired by CodeFlow. Reviewers could use their web browser or the client app, and it all fed into the same system. Most of the features that set it apart from Github initially have been copied by now - comment threads with resolutions, individual reviewer states, etc, have all been recently introduced; the gap between CF and GH has shrunk substantially. That said, CF still does a better job of retaining comment threads and associating them with lines of code. Maybe it's just different UX decisions by the product teams, but it makes a difference when reviewing complicated patches.
- deleted 8y ago
  [deleted]

ahartmetz 8y ago

As a contributor to a F/OSS project with some serious infrastructure (KDE), Github's uncontested success feels weird. It's a really anemic "solution" to the collaboration problem, especially with projects using it as their only collaboration platform. Most larger ones at least run mailing lists and a wiki or so. Some have a more sophisticated bugtracker, but most seem to stick with Github's... placeholder for one. Probably due to its integration with code review.

machiaweliczny 8y ago
I can recommend reviewable.io for github.
- bogle 8y ago
  Don't look now as they're having trouble with dropping offline ...
  - piotrkaminski 8y ago
    All fixed! (And it only affected people signing in from two different browsers at the same time, which was actually a pretty small proportion -- which is why it took so long to find and fix the issue.)
DaiPlusPlus 8y ago
Github’s success stems from its simplicity imo. Pre-Github, projects would need to fire-up their own Bugzilla or Fogbugz instances, set-up all the project tracking criteria (areas, iterations, severity, etc). But unstructured label tags seem to work surprisingly well in practice: projects that would have otherwise demanded 20+ fields for work-item tracking now seem fine with issue labels.
- pritambaral 8y ago
  > Pre-Github, projects would need to fire-up their own Bugzilla or Fogbugz instances, set-up all the project tracking criteria (areas, iterations, severity, etc). So a ready-made setup at an existing service open to multiple projects would work. I guess that's what Sourceforge was.

renholder 8y ago

>Despite all that, the workflow was so good that I'd take it over github CRs in a heartbeat. I have to agree, here, wholeheartedly. Put a bug in that would break the build? No worries, as soon as you kicked-off a CodeFlow, it would start a prod and smoke-test build for you. Everyone could also see those breaks and block the review from completing, until you fixed them in a new iteration. You would think that, with everyone moving (or having moved) from Source Depot to VSO/Git, CodeFlow would've falled into the deprecated products pile but because it was such a worthwhile utility, teams for entire products carried it forward, rather than relying on GitHub's CRs[1]. [1] - It became more of an amalgamation between the two [Source Depot and Git-basd-VSO] but CodeFlow was your one-stop shop to view it all.

guitarbill 8y ago
> No worries, as soon as you kicked-off a CodeFlow, it would start a prod and smoke-test build for you. Everyone could also see those breaks and block the review from completing, until you fixed them in a new iteration. This sounds exactly like PRs with status checks for protected branches (usually master)? Edit: Link with UI screenshots: https://help.github.com/articles/about-required-status-checks/ https://help.github.com/articles/about-required-status-check...