Date: 2012-08-31 02:59 pm (UTC)From: [personal profile] eylul
eylul: (0)
No need to apologize. One of my goals in putting this is also clarifying misunderstandings. Thus you just gave me an excuse to reformulate some of my arguments there. :)

Re: coder motivation, I just want to clarify that I don't envision a new system where people are ordered to work on specific bugs as in: you work on issue 345, he works on issue 423, she works on issue... etc. What I am suggesting is an org culture that motivates through reminding why we do this. It is not to have fun only, but to contribute, help out with something that is needed.

There will be always volunteers who will only want to put input to specific parts of code. However, I do envision a core team of staffers who not only motivated by their interest and personal use of the archive but also by making the archive a better place for all communities who uses it, and a project management that considers all sides and interests (including that of coders) when setting priorities and roadmaps. I also envision an OTW (and apologies for being blunt) where committees don't have to beg to get crucial and time sensitive work done, or where volunteers don't drop out demoralized because they don't have the minimum technical support that is required to do the work they came in to do and that the org will benefit from. I envision an AO3 where users don't have to resort to a yelling storm just to be heard and to have changes happen fast.

Besides, while it is true a more strict development plan might mean not always working to tasks that are interesting, it also means sharing of fun or high visibility work. True, we replace "I coded this!" with "I was part of the team that worked on this." (and not only programmers but also designing and testing) but especially since it will bring the work to the most needed parts of archive and ensure it happens in a more timely manner, it will bring more recognition and thanks. Thus I dare say it is a worthy trade, in terms of motivation.

Re: Agile vs Waterfall, actually for the purposes of this post I initially stayed away from software development methodologies, since I agree with you that deciding on one or another is orthogonal to the management and structural issues of AD&T. However, I got several comments in a week that I am supporting Waterfall (which short answer is, I don't not necessarily) and I assume it is a topic that will keep coming. I don't have a lot of experience in Agile in a professional setting in that I've always been more on usability/design sides of things, and my career path is in academia and not in industry. A lot of my questions was based on what I read and have discussed with people who do work in software development and project management over past few months. That is also why I asked for you to elaborate on that. :)

Re: integration. Unfortunately I believe the issue is deeper than about being a staffer or not in AD&T. 2 years ago when I was a testing lead, for example, there were a lot more staffers who were non programmers, who argued on these problems internally, yet a lot of these issues existed back then just the way it does now. What the problem boils down to is negative externalities. It is easy for documentation and effort in collaboration to look like an overhead, to decide to skimp on proper design and QA processes for that one tight deadline or feature, etc. Integration assumes people can notice negative externalities and work accordingly, which in practice rarely happens (and even more rarely when there is always the next emergency the way it is with AO3 and overworked AD&T). Separation is an overhead, yes, but it helps proper support of volunteers and ensures there is more accountability in place about following the proper processes of design, coding and testing. This way even when we are working on a shorter cycle or when emergencies are occuring, it will prevent individuals from making too many tradeoffs of short term solutions for long term problems.

My second concern with integration it doesn't address the larger scale inefficiencies which was one of my main reasons for proposing a split (which is actually a split and merge) Currently web and AD&T reinvent the wheel in terms of supporting front-end coding and design. Committees such as wiki, also do need technical support and has volunteers 1-2 volunteers that helps them. As I mentioned in the main post, splitting of AO3 management from design, front-end coding, backend coding and QA allows combining individual pools of volunteers by role, and actually lessening of managerial work that is currently being done in double on organizational scale as well as supporting the volunteers working on other projects better.

Another concern with integration I have is about the workload of the committee. AD&T is responsible doing volunteer training and support for 3-4 types of volunteers, and doing project management on top, and I cannot see how this can be fixed without a split.

I would be happy to hear how you would tackle these three concerns in an alternative solution that involves integration, and again thank you for taking time to comment.
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:24 pm
Powered by Dreamwidth Studios