"Code reviews become annotations" - cool feature, and it identifies a real problem. I don't think it solves it though.
We've learned many times that your source code and its history are the thing you care about. Spreading closely related information across different systems is dicey at best. It never seems to follow the same branching structure as the source code, and external systems come and go. Even for issue trackers, one of the most obviously useful tools we have for software development, it's not obviously a good idea to refer to issue ids from source code comments.
That is to say: if you believe that code reviews are an important part of the code, or at least sometime can be, then you should be getting that information back into the code itself. Show me a way to turn code review into a code comment from the review interface, that would be cool.
There's a substantial difference between what we're doing, and what git-appraise is doing. Git appraise is solving the problem of decentralized code review, but it doesn't solve the problem of making code reviews discoverable, after you've done them: having a directory full of JSON files doesn't make it easy to go from a line of code to the review that created it.
In other words: we're trying to make it possible to look at your code, and see every bit of historical information, in context, that made it as good (or bad) as it is at that moment.
That said, having the ability to export our annotations to a directory full of JSON files is high on the to-do list. You should absolutely be able to work with your own data.
This is a good point. In particular what happens if you fork a repository, do you lose the meta-data? What happens if you have a fork for coordination of a sub-team, are the pull-request annotations created on that fork also available with the main repository once it is merged in?
Good point! Right now it isn't fork-aware, but there's no reason, in principle, that the annotation data couldn't (or shouldn't) be forked with the repo. I'll file that as a to-do!
This is beautiful and clearly very useful. Some thoughts:
* Business-wise, your main risk is that GitHub agrees how useful this is and builds much of the same features. In a sense, GitHub can improve in this manner, by taking the best features of external services and implementing them directly.
* The killer app here would be if you can integrate this into an IDE. In other words, the annotations are great for code-review, but not just code-review. In general they are essentially better comments. Wouldn't it be great if I saw those annotations whilst coding? I understand that it's not as if you personally could create plug-ins for all existing IDEs. But could you have an API to make that possible for third-parties to author said plug-ins?
* Integrated with code-analysis software could make for a very pleasing automated-code-review service. For example, with Python you could annotate the source with the output of pylint. Obviously, I'm not suggesting that this replaces manual code-review, just that it would be a nice addition. I mean you already have the automated annotations highlighting where a line was affected by a pull-request.
* The tour was really nice, but whenever I was asked to "go ahead and click on the annotation" this did not really work, mostly it just advanced the tour. On that note, it would be good if the tour suggested how far was to go.
Yes, an API is coming very soon. And hopefully soon after that, some open-source editor integrations based on that API. Do you have an editor/IDE you prefer?
Integrated code-analysis would be cool, but it gets into a messy, language specific area that I'd like to avoid for the time being (these tools can be...flaky...when run at at scale, on lots of strange repos). But I'd like to find a solution -- either, again, via API, or possibly by some sort of jenkins-like service that allows you to run any particular tool you want, and attach the output to the code as annotations. I'd like Omniref to really be a "universal reference" for your code -- not just code review comments, but any sort of information that is relevant to lines of code.
Regarding the tour bug: could you send me an email (tim@omniref.com) with a screenshot of what you saw before/after clicking the annotation button? It might be a client-specific bug.
We currently use Reviewable.io. It has a lot of features that I expect from a code review tool, but the UI is just very bad and slow on so many levels.
Will give omniref a try.
@timr, I think you should charge per user, not per repository + per user. In today's micro-service/library/containers age, there a lot of small repositories within companies. Your pricing suggests there's a 2:1 repos to users ratio. Our team, for example, easily has 10:1 repos to users ratio.
Hi there, Reviewable founder here. Can you elaborate on "very bad and slow" please? The UI can be polarizing but I'm always open to simplifications / alternatives. As for performance, I'm not aware of any regressions at the moment as long as you're running Chrome 49+ or Firefox 46+ on a decent machine (Safari and Edge have... issues), but again I'm happy to investigate every report.
I'd like to echo this comment. Piotr has been amazingly responsive to problems with bugs or performance issues that we have hit (the Mozilla Servo team).
Apart from the UI, Reviewable also handles many of the really ugly "they did an over-under rebase, force-pushed, did another, then flipped back" cases that come up with longer-lived PRs and manages to keep the review state reasonable better than any other tool I've seen. And we've tried quite a few of them :-)
Hey Piotr, there's not a single issue I can just point out. The whole experience feels lagish and slow. It is most likely there's so much JavaScript on the client. I even have animations disabled. For example:
* /reviews page takes around 5 seconds to load
* Sometimes the above page gives API rate limit exceptions
* The list of PRs on the above page are not wrapped in an anchor tag. I can't right click the links (to open in a new tab for example), I have to hold onto cmd and press a small icon instead
I love all the features you offer, but the UX is not very pleasant at all. We can set up a web session to show you more of my experience.
Thanks! The pricing structure is a bit of a guess right now. I'm flexible on the repo restriction, and amenable to removing it completely, if that's what people want.
If it's the only thing that keeps you from trying us, shoot me an email at tim@omniref.com, and we'll work it out. Not because I want give the hard-sell, but because I'd have to alter the code. ;-)
* Editor integration. Let the comments show up in Atom or whatever as inline editor annotations (assuming they're on the right HEAD).
* Inline editing while reviewing. Very often I have to comment on a bit of code with "this is how you should write it". When code reviews are just comments, I have to write that as Markdown, and I often have to copy/paste a chunk of the original code, and it's up to the reader to mentally diff what I changed. I'd rather edit the wrong code directly, and the target user should see it as a third diff pane.
Editor integration: Agreed. An API is soming soon, which will make it possible for anyone to write an editor integration. Because there are A Lot of Editors.
Inline editing: interesting. I'd have to think about how to do that one, but it's a cool idea. Thanks!
The smart annotations literally require computing a revision history for every line in the code. Essentially, a signature that uniquely identifies the line in time and location. It's a non-trivial thing to compute, and there are a lot of edge cases, so I can understand why GitHub hasn't done it. ;-)
Editor integrations are a super-common request, but because there are as many editors as programmers (it seems), we'll probably start with an API, and then move to creating open-source extensions for the most common editors. But your vote for JetBrains is recorded!
Just want to let you know that our repo importing processes are currently being hugged to death. Oops. I'm spinning up more workers now, but we're about 100 repos behind at the moment.
protip: make your free option a bit of text with a link instead of highlighting it on an equal basis with your paid plan. People who want a free option will find it while people who are willing to pay you $50 wont think about the free option as much. Also those red buttons are very angry looking. Maybe make them green instead. I don't like clicking red buttons, red buttons usually do dangerous things like delete accounts and launch stuff in production. Green buttons are click magnets on the other hand.
I feel like this could all be done with a polished up chrome extension. I don't see what I'd be paying $50/mo for, which is double what I pay for my company's GitHub account itself.
I disagree that a Chrome extension is a good way to handle this. Where would the annotations get stored? There is enough complexity here that a dedicated service is warranted.
What happened to omniref for Ruby's source code? I can't seem to navigate to it from the main site anymore, I can only find it via Google search linking into the site.
This appears to hammer GitHub's API pretty aggressively. I attempted to import https://github.com/cockroachdb/cockroach and a few hours later my API limit is exceeded.
It's pretty conservative with the API usage, but if you have thousands of pull requests, issues and branches, it will probably hit the limit of 5k requests an hour on first import. After initial import, API usage is very light.
You're the first person to have this problem, but I'll add some logic to throttle the request rate before we run through your allocation. The trade-off is that it will slow down import of pull requests and issues.
Oh, yeah. It's way too much UI information to work well on a mobile device. I hid it to prevent eyeball bleeding from cellphone users. You'll see it on a larger screen.
I'll have to add some screenshots, but it's just a hard thing to make obvious on a small screen. Thanks for the feedback!
You definitely need some screenshots at least on mobile. I skimmed the page and left cause I didn't see anything. Glad I read the comments to see why it was upvoted, now I at least know to check it out later on my main machine. If this weren't HN you'd have lost me though!
Oops! I keep forgetting to put examples on the homepage. Thanks!
I don't have any public examples of code review, but I've imported some popular open-source repos as examples (I don't know if I have these live-updating atm, so they might be a little behind their respective repos, but they're still good examples).
We've learned many times that your source code and its history are the thing you care about. Spreading closely related information across different systems is dicey at best. It never seems to follow the same branching structure as the source code, and external systems come and go. Even for issue trackers, one of the most obviously useful tools we have for software development, it's not obviously a good idea to refer to issue ids from source code comments.
That is to say: if you believe that code reviews are an important part of the code, or at least sometime can be, then you should be getting that information back into the code itself. Show me a way to turn code review into a code comment from the review interface, that would be cool.