Date: 2012-08-27 10:30 am (UTC)From: [personal profile] eylul
eylul: (0)
Hi Ana,
First of all thank you for long and thoughtful comment. Even if I am about to go on a disagreeing spree :)

1) First of all I don't think my post was only about issue of directive authority. Today if we could fix that issue, there would be still problems such as, the need of picking a software development model and actually making it work as you said, but also other concerns such as supporting technical staff and volunteers better.

What I defend first and foremost is that people doing design should know designing methods just like people who do coding know programming techniques and best practices. And that our QA volunteers should be able to get training support and processes to do their job without conflict. The advantage of separate committees is to build separate structures of training, support and mentoring, and ensuring QA and Design teams don't need to go through programmers to access project and volunteer managements.

Also another reason for splitting committees is the amount of work the current AD&T is. I hope it got better in the year I have been absent but we tended to burn out chairs. Meetings went overtime or agenda would be never gotten through (issues sometimes taking weeks to get to), and the ML load on top of it. And on top of all that we ask our staffers to do coding. This results on very few people being able to contribute to the project any meaningful way. Dividing various management workloads into 4 committee structures will ensure people can actually focus the roles they want to spend time in.

For these two reasons, even if we didn't have the directive authority issue, I would still defend dividing committees.

2) I am sorry but I disagree strongly with you on that coders will only do what they like. Volunteers all across the org deal with same challenge everyday. Volunteering your time means sometimes doing work that is not your favorite. Support volunteers answer tickets everyday that is not their favorite, many tag wranglers wrangle fandoms that are not their own, I am sure Legal has to answer questions that they might not be interested in. Wiki has to manage content that doesn't interest them. QA need to evaluate code that they'll never use. Every day around OTW people do work voluntarily that is work and not fun. Yet somehow they still do it. This is what volunteering is. You give time to a project that you support. You support them by giving your time. It makes us feel useful, makes us feel we give something back to community, and earns us social credit.

Also it is important to note programmers both experienced and beginner benefit beyond the giving back to the community and social benefit. It allows you to work with a separate code base, with new platforms, to acquire new skills. It allows you to network. It is also a good experience to show when you look for jobs for example. Thus I would say there is a lot of incentive to attract programmers to this project even if they can't always work on the feature or bug they want to.

There are of course ways to ensure this will NOT work. For example if some of coders are getting first pick on what they want to work on and others aren't (which was the way things were when I was in AD&T) it is a smart way to ensure people will not stick around and feel used. However for example if the whole group worked one month on translation, next month on browse, the one after that is bug fixes, being in this together will build a sense of community and achievement. (It would also have the added benefit of not having needed features such as open door import or filters being delayed, or suddenly 3 features coming at once with not enough time to QA.)

Another reason why having a project management structure and coding committees dedicated to supporting volunteers will help is that we will be able to accommodate bringing in paid programmers through programs like Google Summer of Code, or say unpaid interns looking for experience. (we did the latter once years ago, and won Bing through it). It is no cost to us except time to mentor, and it is possible to get work done, and can even win us a long term volunteer in process.

I hope this addresses your concerns.

By the way I am really interested to hear you actually talk more about processes. I am not actually not defending classic Waterfall as only option (despite comments I received :)). What I would like to see happen is an iterative design of some form, and user-centric design practices applied. Agile does concern me however, because everything I read so far on it is either not user centric at all or is completely not scalable to the size the archive has grown, although I am no expert on it. Thus I would actually love to hear what your ideas are on this.

Thank you again and looking forward to hear more from you.
From:
Anonymous
OpenID
Identity URL: 
User
Account name:
Password:
If you don't have an account you can create one now.
Subject:
HTML doesn't work in the subject.

Message:

If you are unable to use this captcha for any reason, please contact us by email at support@dreamwidth.org


 
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.

Profile

eylul: (Default)
eylul

October 2012

S M T W T F S
 12 3456
78910111213
14 151617181920
21222324252627
28293031   

Most Popular Tags

Style Credit

Expand Cut Tags

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