fuzzylunkin1 wrote:QUOTE (fuzzylunkin1 @ Jun 16 2010, 02:02 PM) You realize this would not only grant Bard development control but also [partial] control over all aspects of the community. It's not just whether he'd be good for this job, but rather whether the community trusts him to make important decisions that affect everything. Tigereye chooses not to make important decisions rashly and lets the ZLs debate them amongst themselves.
While fuh-zz has a point, I have no designs on being some sort of despot or high mucky-muck.
I don't believe in star chambers or ivory towers.
To expound a little bit on something I posted a while back when I first considered telling TE I was interested in being Dev ZL:
The development zone lead is a leader of course, but not in the "I have a big stick and you will obey me" sense.
The dev zone leader should be able to UNIFY the developers, helping to organize their efforts to produce a test build and assemble output into a cohesive whole. That's only about 1/10 of the Dev ZL's job. Then there's coordinating the community effort for beta testing. Ensuring everyone knows HOW to get onto the beta server, make sure it's as easy as possible, and make sure that everyone who wants to test, can. Joining a beta test should be as easy as joining a pug. That's about another 1/10 of the job.
The rest of it (That's 8/10 of the job or so, if we want an active, functioning dev team working towards a common goalset) involves PR, Bureaucracy, locating more development resources (QA people and coders), enhancing those resources (hand-holding and training QA and new coders), working as an intermediary between the ZL team and the needs of the Dev Zone (that's hand-holding TWO sides, because not all ZL's understand the allegiance code, and not all C++ coders understand Allegiance politics), and generally doing the sort of thing that the guys who wear pink button-down shirts in offices, also called MIDDLE MANAGERS, are required to do, packaged with a heaping helping of super-politeness.
Being Dev ZL means significantly less time to code and a WHOLE LOT OF TIME HERDING CATS if we want to get back to the R1/R2-era levels of development activity. (You know, that "reasonable release schedule" everyone here would love to see again)
I threw my hat into the ring for this job because I have experience successfully managing IT teams at several points throughout 11 years of my IT career to date and one of the first and most important things I learned was using resources wisely. For that reason, I'd rather have Imago and most of our other developers coding instead of managing, personally.
One of my major goals is to speed the transition from bug report to game patch. As it stands at the moment, we have a fair amount of bugfixes and even some features that have been sitting in the code repository for anywhere from months to going on a year that really should be in game so we're clearly getting hung up between "bug fixed" and "game client patched". I have a few other things I'd like to implement as well, but anything that could potentially have impact on game play will be run by through the dev team and by the zone leads. I don't plan on making any blind sweeping changes. Development Zone Lead is a position of responsibility that comes with some power, not a position of power that comes with responsibility.
