[teampractices] How deviantART organizes its work

[Shahyar Ghobadpour]

>> A bit dated, but still an interesting read:
>> http://dt.deviantart.com/journal/We-re-all-remote-220038037
>
> Thanks for sharing Erik - out of curiosity, how big of an engineering staff
> do they have?

I'm a bit late to this conversation, but figured I'd chime in, as a
former deviantART engineer. I don't recall the exact number, but I
believe we were about 50-60 engineers. And yes, as Erik mentioned,
that post is a bit dated, but not a whole lot has changed in terms of
_how_ the teams work. They changed software along the way, but the
general practices remained the same. I'm getting to the end of my
first week here at WMF, and I can discuss a bit about how things are
different.


dA uses Mumble for large meetings, and Skype for chat and small
meetings, versus our use of Hangouts for meetings and IRC for chat.
There are pros and cons to each of these, and while we always
complained about Skype, the major benefit of it is that even if you're
offline, you can still be messaged, and people can still talk to/about
you in a chat room -- you will receive the entire chat room and
private messaging history upon your next login. This is a bit of an
annoyance with IRC. I think I'll have to get more used to emailing
people here.

Almost everyone is remote, which means everyone is _always_ in chat,
and from timezones around the globe. And when they're not, they are
usually easy to get ahold of via email. This makes for easy
integration into work as a remotee, because someone is always around
to answer your question. There's global rooms (for departments, and
general chit-chat), and smaller rooms (for teams/projects).

All developers are full-stack, which allows them to easily move
between teams / new short- and long-term projects. Typically, people
start in Reactor, then move onto other teams for various amounts of
time. The first things you do in Reactor are easy bug fixes and one
major code refactor. That major code refactor can take days or weeks;
you keep committing code for review, and as concerns are raised, you
fix them and keep committing until finally someone approves your code
for landing. This is the process for almost all code; rarely does
something significant get pushed without being reviewed.


The big difference is that they use Phabricator to manage code
(including review), commits (including auditing), unit testing, as
well as bugs and features. I see you last really looked into it in
2012, and the main reason for not using it was the lack of permission
controls. As of November 2013, they've had per-object access
restriction in place, so I'm thinking it might be time to give it
another look. I can flat out tell you that Phabricator is by far the
best project/code/bug management system I have ever used, and I've
gone through at least half a dozen of them over the past few years.
It's a huge improvement in terms of productivity, since all the
features are integrated together in one single tool, and the interface
makes things like issue tracking, code review, and feature discussion
a LOT easier to do.

Things like Bugzilla and IRC were the de facto standards for
open-source communities in the past. I think we're stuck in that
mindset, and should be looking at more contemporary solutions. I would
really like to discuss this with everyone, and see if we can
reevaluate Phabricator for our needs this year. I think we could be
working a lot more efficiently by switching to it.

--Shahyar