See https://secure.phabricator.com/T2849 for discussion.
254 karma · joined January 17, 2011
This isn't what the results say. The win rate for the player who goes first ("Player 0") rose from 41% to 61% when the player who goes second ("Player 1") was not given The Coin.
This is summarized in the text:
> The Coin basically makes what used to be a first player advantage into a first player disadvantage. Not bad for a single card!
We also just got rid of "Clowncopterize":
---
To provide some context, this is the top-level entry point for all requests. It routes requests to code which does application-level things, like showing a code review or updating a task or whatever.
When the application-level things go wrong, we try to display a pretty, human-readable exception page with a nicely formatted stack trace (if you're in developer mode), etc. This page relies on some infrastructure subsystems (like configuration, to check for developer mode, and static resources, to include JS and CSS, and rendering, to actually produce the HTML) working correctly.
Normally, the exception is in application code and everything works fine. We produce a pretty page and send it back to the user.
However, sometimes there's an error in one of these subsystems. If we start rendering the page and encounter a second exception during rendering, we fall back to a less-pretty page which has bare text and no dependencies on subsystems. Normally, this happens during development when you've made a mistake in changing one of the subsystems, and all JS inclusion or all configuration checks are failing.
On this bare page, we want to retain the original exception (as well as show the followup exception) because it may be helpful in identifying and resolving the issue.
With the obvious caveat that I wrote the code, this architecture seems sensible and appropriate to me, and appears to function correctly in practice.
The tone of the project itself is similar to the tone of the site, so if you find it off-putting or believe your co-workers would find it unprofessional, the product may not be a great fit for your environment anyway.
We also haven't heard feedback about anyone having difficulty convincing others to try Phabricator because of the project's tone. Again, it's possible we're just not aware of it, but we have heard feedback about other issues in this vein (for example, the LAMP stack being a hard sell).
The GitHub URL will probably change if Facebook vanishes, but the project would otherwise be unaffected.
1. `arc land` is optional, and always has been. If you don't want to use it, you can just use normal `git` commands. All `arc land` gives you is a few checks against human error.
2. `.arcconfig` is no longer required, although if you want to use integrations like lint, you'll still need to configure them.
3. Anything we can improve on?
4. You should be able to use `arc which` to understand what `arc diff` will do. You can change what `arc diff` will do by specifying a different set of "base" rules, according to this document:
https://secure.phabricator.com/book/phabricator/article/arca...
Although our project is much smaller, we also run a bounty program through HackerOne, and publish aggregate results every month. You can see them under the "Security" headers of the changelog for the last few months to get a quick sense of the overall composition of reports that come through a channel like this, at least for our project:
http://phabricator.org/changelog/
For example, last month we received 49 reports, of which we believe 5 were legitimate security issues which we fixed and awarded. Although the signal on this channel is extremely valuable, it's embedded in a lot of noise, and separating the two is often difficult and time consuming. It wouldn't surprise me if we made mistakes with a few reports even at this relatively small scale, and we have a much easier task than larger projects do.
I'm extremely supportive of HackerOne, but I'm always a little worried we'll make a mistake and end up tried in the court of public opinion when we triaged >99% of the reports correctly and the overall impact of the program is hugely beneficial for researchers, for us, and for our users.
Of course, we should be aiming for 100%, and getting it right almost all the time isn't a free pass for the cases when things go wrong, but seeing just the cases where an issue wasn't handled correctly discards a lot of context.
At the moment, there's no way to revisit past questions, search for questions, etc. You can only swipe through questions and answers one at a time, in the order the application presents them to you.
This application is just a structured version of Twitter or Vine or Instagram, where you have to take a picture (which makes the content more interesting to browse) and other people are encouraged to respond and interact with you because the message is presented as a question.
Right now, the use case is that you are bored or lonely, so you "ask" a "question" to your friends about whatever sort of dog or lamp or restaurant or funny-shaped cloud you happen to be near at the moment. Your bored or lonely friends who are also using the app at the time respond in a general social way, not necessarily with good answers. Everyone feels good about it, and no one had to actually impose on anyone else.
It's reasonably good at this. This app provides structured social interaction, not really question-and-answer or search or access to vast untapped reserves of human knowledge.
Although presumably the app will eventually have more of those features, the focus on these features in the initial release leads me to guess that the creators understand what they've built. It may or may not be successful, but I think if it is it will be in the Twitter/Vine/Instagram/Reddit/Facebook bored/lonely space, not Google/Stack Overflow/Quora/Yelp actual-answers-and-knowledge space.
http://www.quora.com/Facebook-Engineering/How-accurate-is-th...
(I don't speak for my employer, Facebook.)