Limiting covered contributors

If you subscribe to Reviewable for private repositories, you can now directly limit the users who will count against your plan's quota:


If you configure this option, reviews will only be created for pull requests authored by members of the given team. (This holds true whether the review creation attempt is due to a repo connection or direct navigation via the review dashboard.) So if you're on a 10 contributor plan, and constrain your subscription to a team with no more than 10 members, you'll be sure to never exceed the quota.

Previously, you were able to limit the power to create reviews to a team, but this proved confusing since a single person on this team could connect a repo that would cause the creation of reviews with any number of contributors. This legacy option is no longer available but if your subscription was configured this way the restriction will continue to be enforced until the next time you edit the subscription (for any reason).

Hopefully this new option will be helpful and easier to use — let me know either way!

Live status updates on other reviewers

Have you ever wondered if a reviewer is working on your top priority super-urgent review right now, or if you need to send them yet another reminder? In the beta, you can now see how recently they interacted with a review and whether they have any drafts pending in the sentiments section at the bottom of the top-level discussion:


This indicator updates live. It works best for people who are using Reviewable's web UI (beta only for now), since there's no way to tell if they have comments buffered in GitHub or an email, but will also update the timestamp if outside comments are received.

Support for requested reviewers has arrived

Requested reviewers are now fully supported throughout Reviewable! Details follow, including which features are only in the beta so far. Note that you may want to update your custom review completion conditions, if you've got some.

First, requestedReviewers are now available in review completion conditions. The default condition uses requested reviewers in place of assignees if any are specified, tagging any who haven't joined the review yet as being waited on if any files have no reviewers at all. If you'd like to customize this, you can look for inspiration in the updated sample conditions available in the beta's repository settings. (You can safely update your condition even if not everybody on your team is using the beta, it'll work fine.)

Second, there are several improvements to the review list in the beta. It now includes PRs where you or one of your teams are a requested reviewer. It has two new sections: "waiting on me" and "being reviewed by me", to help you further prioritize your reviews. Finally, the hand no longer points at assignees (since that gets messy with requested reviewers thrown into the mix) but rather at people whose attention the review requires to move forward, so you can see at a glance who you need to nag.

Third, again only in the beta, the sentiments section at the bottom of the top-level discussion now has indicators marking who's being waited on, assigned, or a requested reviewer. You can also manage requested reviewers with the new ±reviewer:@username directives (similar to the ±@username assignee directives), and as usual all directives work in comments originating from GitHub or email as well. (You cannot use directives to set requested reviewer teams at this time — I can add this if there's demand.)

The beta is coming along nicely and I expect it'll get promoted to stable pretty soon. In the meantime, as always please let me know if you find any breakage!

Small new features in the beta

Besides a bunch of bug fixes (and undoubtedly some new bugs to balance the scales), there are a couple of small new features in the current beta version:

Special filters on the review list can now be negated (by prefixing with - instead of +), and there are some new ones for you to use:

  • ±needs:review: incomplete reviews
  • ±needs:fix: reviews with failing checks
  • ±needs:merge: completed and clean reviews
  • ±needs:me: reviews waiting on you
  • ±needs:author: reviews waiting on author
  • ±needs:reviewer: reviews waiting on a reviewer

Also, if some diffs were throttled to limit CPU use or hidden due to size, you can now force all diffs to show anyway at your own peril. The setting will persist for that review until you navigate away.

Major update now in beta

I've launched the beta of a major update to Reviewable! The changes are mostly internal but pave the way for the upcoming UI redesign. The beta is running on and I'm redirecting a small but increasing portion of traffic there to flush out any bugs. Please report any issues you encounter and feel free to visit the beta directly if you want to be extra helpful. Besides the URL, you can tell you're on the beta version by the header logo:

So what's in this update and why did it take so long? It's basically a rewrite of the client's internal data model, affecting tens of thousands of line of code. It's underpinned by a new framework, Firetruss, that I built to overlay an object-oriented layer on top of Firebase and manage data dependencies (which have been a perennial source of hard-to-reproduce bugs). The framework is built on top of Vue, which brings some performance advantages and much improved instrumentation to track down performance issues. It's also compatible with both Vue and Angular to ease the full transition from the latter to the former later this year.

The other major change is that most of the code that interacts with Firebase got broken out into a separate worker to make better use of modern multi-core processors. Even better, in Chrome or Firefox this is a shared worker so that all tabs share a single connection to Firebase as long as at least one Reviewable tab remains open. This cuts down on startup time as the socket is already established and the user authenticated, and lets all tabs share a single cache to reduce the need to refetch data.

Other than that, there's a few minor new features that I'll detail in a separate post, and more new features coming as the new version stabilizes. Exciting times!

Complex file renames

I've fixed the server algorithm that pulls together pieces of metadata from renamed files into a single synthetic "master" file. While it always worked fine in simple situations, it used to get weird (and outright wrong) results for more complex rename graphs, such as when you renamed A to B then later C to A. The algorithm for determining whether a rename occurred remains unchanged.

This may affect the review state presented to both the built-in review completion computation and custom review completion conditions, and hence also the output of these conditions. Please let me know if you spot anything untoward, especially when it comes to custom per-file reviewed flags since Reviewable needs to map those from the synthetic file back to its constituent parts.

Note that the file synthesis algorithm on the client remains the same for now, and I think doesn't suffer from the same bugs, but will be getting updated to the shiny improved one in the next major release anyway.

GitHub status updates

I've tweaked how Reviewable posts commit status updates to GitHub to (hopefully) cause less problems.

It turns out that in some projects Reviewable commit status updates triggered the CI tool, which in turn updated a comment that triggered Reviewable, getting into a vicious cycle that ended only when Reviewable bumped up against the limit of 1000 status updates per commit. Reviewable now no longer temporarily flips the status to pending "Checking status..." and will fall back to an even less invasive approach if it gets close to 1000 checks, so your PR won't get stuck in an error state.

The downside is that if something moves a review from complete back to in-progress, the GitHub status will remain as success for a few extra seconds, opening a small window of opportunity for a merge that maybe shouldn't have been allowed.

Completion conditions and obsolete revisions

In Reviewable, a revision becomes obsolete if any of the commits it covers are no longer part of the PR; this usually happens because of a force push. Those revisions are shown crossed out in the file matrix:

While Reviewable dealt with this just fine, until now custom review completion condition code couldn't tell whether if any of the review's revisions were obsolete. This could lead to unexpected outcomes, especially if you rolled back a branch making the last revision obsolete.

If your completion condition code ever assumed that the last revision is the latest / current one (this includes the sample conditions, if you copied them!), you'll need to fix it like so:

_.last(revisions)                       // BAD OLD WAY
_(revisions).reject('obsolete').last()  // NEW WAY

This goes for both review.revisions and individual file.revisions. I updated the samples so you can safely crib from them again.

BTW, another way to fix this would have been to simply redact obsolete revisions from the data structure passed to the condition code. I decided against this approach because it would preclude some potentially useful condition logic.

Collapsing discussions

Collapsing a long discussion (e.g., by clicking Acknowledge) will no longer scroll you to some seemingly random spot on the page. If the top of the discussion is off-screen, Reviewable will automatically counter-scroll the window so it'll look like the discussion is collapsing from the top down and remain within the viewport.

BTW, the rewrite is making good progress! The end isn't quite in sight yet but it's just over the horizon. :)

Sample commit status in new repos

When you connect a repo, Reviewable will now automatically create a sample commit status (not associated with any PR). This way, you can include Reviewable in the branch protection settings in GitHub even before you've opened your first PR!

This also works nicely in conjunction with the repo auto-connect feature announced a couple days ago.

No published changelogs yet.

Surely Reviewable will start publishing changelogs very soon.

Check out our other public changelogs: Buffer, Mention, Respond by Buffer, JSFiddle, Olark, Droplr, Piwik Pro, Prott, Ustream, ViralSweep, StartupThreads, Userlike, Unixstickers, Survicate, Envoy, Gmelius, CodeTree