[teampractices] How deviantART organizes its work

Fri Jan 10 23:29:25 UTC 2014

On 10/01/14 16:02, Steven Walling wrote:
>
> On Fri, Jan 10, 2014 at 1:34 PM, Shahyar Ghobadpour 
> <sghobadpour at wikimedia.org <mailto:sghobadpour at wikimedia.org>> wrote:
>
>     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.
>
>
> Thank you for sharing. All this is extremely helpful.
>
>     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.
>
>
> The solution many of us use for this problem is an IRC bouncer. I'm 
> actually connected all the time in IRC even when my laptop and/or 
> client is closed, so I get messages and scrollback etc.
>
> One of the things that keeps us stuck in IRC land is that it's not 
> just an internal company tool. It's also deeply embedded in the 
> Wikimedia community, even among a segment of "non-technical" community 
> members. We used to actually hold IRC office hours (you can look up 
> the logs on Meta) as general community chats, though this is slowly 
> dying out as a communication practice.
>
>
>     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.
>
>
> Having played with their test version, I'd definitely be happy moving 
> to Phabricator as a replacement for Bugzilla, IRC, and maybe even 
> Trello/Mingle.

Why don't we see about getting a test Phabricator up and running 
somewhere? (The website makes it clear how very serious it is...)