Date: 2012-08-26 05:17 pm (UTC)From: [personal profile] anathomical
For context: I'm currently a member of AD&T, and have been for approximately 18 months. That said, I'm speaking for myself in this case, rather than in any sort of official capacity. In my day-job I work as a coder and scalability specialist for web-sites, and do a small bit of side consulting on organization and corporate culture construction.

First of all, thanks for bringing this up. There are quite a few organizational issues that you correctly identify. Especially with regards to prioritization and supporting non-AO3 projects, and those definitely need to be dealt with.

(I had a section here analyzing various approaches to developing software, but realized it wasn't my main argument, so cut it.)

I actually think that as an organization the OTW would have significant problems implementing a full-on version of either Waterfall or Agile methods, and a lot of those problems boil down to variations on directive authority.

I basically think that the problem you're trying to solve is one of how to get coders to work on the things that need working on. Translation interfaces and unexciting features and bug fixes and non-AO3 code and all the other things that sort of languish with insufficient attention at the moment. This basically boils down to a directive authority problem.

Basically: in order to direct coders (or anyone, really) to work on a specific feature or idea, you have to convince them that it's worth their time to do so, and you have to do that in the face of competing things that they could be doing with their time instead. So if you want someone to work on (say) translation interfaces, you must convince them that doing so is a better use of their time than (say) reading fic.

The vast majority of corporations solve the problem of directive authority by paying their people. That creates a contractual (both legal and social) obligation to do the work that the corporation specifies rather than (say) reading fic. Unfortunately, at least at the moment, the OTW doesn't really have this option, so we have to fall back on one of the other ways of generating directive authority.

Other than self direction, which provides directive authority purely internally, almost all other forms are entirely social. It is, in fact, almost exactly like trying to get someone to write a specific piece of fic that you want to read: they might do it because they think the idea you have is awesome, they might do it because they're your friend, they might do it because they're getting something in exchange, they might do it because they want to impress you... Well, hopefully you get the idea: there are plenty of reasons they might do it, but none of them are just because you tell them to.

All of which means, I suspect, that the reorganization you're proposing won't actually solve the problem. Because what it sounds like you want is the ability to have higher-ups agree on the importance of a feature, and then to have the ability to make that feature happen with what amounts to managerial buy-in. And, let's be honest, that sort of process tends to be both more coherent (allowing for a sort of shared vision for direction) and more efficient (in that things that need doing get done).

However, because of the nature of the organization, I am pretty sure that you quite literally can't get this kind of structure. Which means that for a given feature to happen, or a given bug to get fixed, you either have to be a coder, or you have to campaign to convince a coder that they should spend their time on it.

They might do it because they think the idea you have is awesome, they might do it because they're your friend, they might do it because they're getting something in exchange, they might do it because they want to impress you...

But they won't do it because you tell them to. And I literally can't imagine that reorganizing would change that.

Which isn't to say that AD&T's current structure is perfect, or even optimal. I think there do need to be some changes made. But I think that if your goal is to have more directive authority over the activities of the organization's coding volunteers, this is the wrong way to go about it. I think that we should actually be having two separate conversations.

1) A conversation about project management inefficiency within the AD&T committee. This includes things like the fact that Google Code is flat-out awful for managing large feature requests along with other procedural and tool-based issues.

2) How do we we provide ways for people to get the work that needs to be done for the org to move forward done? If you can't write the code yourself, how do you get someone help? Current experience demonstrates that simply getting buy-in at the committee level is largely ineffective as I doubt that anyone's going to argue that (say) translation interfaces aren't important, but that work still hasn't been done. I propose that, additionally, proposals along the lines of yours would also be largely ineffective, and for similar reasons. Which means we need some other method for doing what is clearly an incredibly important task.

That is the conversation I think we should really be having. Not (to go back to my metaphor) "How do I create a structure that makes people write the fic I want to read", and rather "How do I create a structure that makes it as easy as possible for me to convince people to write the fic I want to read".

Directive authority is hard.

Identity URL: 
Account name:
If you don't have an account you can create one now.
HTML doesn't work in the subject.


If you are unable to use this captcha for any reason, please contact us by email at

Notice: This account is set to log the IP addresses of everyone who comments.
Links will be displayed as unclickable URLs to help prevent spam.


eylul: (Default)

October 2012

 12 3456
14 151617181920

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Oct. 18th, 2017 06:23 pm
Powered by Dreamwidth Studios