Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] project organization

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Jeremy Blosser (emrys)" <jblosser-smgl AT firinn.org>
  • To: SM Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] project organization
  • Date: Tue, 14 Feb 2006 01:09:53 -0600

On Feb 13, Eric Sandall [eric AT sandall.us] wrote:
> On Wed, 8 Feb 2006, Jeremy Blosser (emrys) wrote:
> <snip>
> We currently are moving the Security Team into the QA Team, where the
> Security Team manager could be the QA Team Lead's assistant, thus
> setting up redundancy. If other teams merge with the QA Team, they
> could also be 'assistants' and add redundancy.
>
> We can do the same with other teams, e.g.
> * PR Team Lead becomes an assistant to the PL
> * Web Team and Server Team (server people, we don't have an 'official
> team' for this atm) would be assistant(s) to Tome Team (perhaps
> renamed to reflect their managing all of our services)
> * Grimoire Team moves under Sorcery (since Sorcery is what the
> grimoires must adhere to)
> * Grimoire Team moves under Cauldron Team (since the grimoires need to
> be in a certain state for the ISOs)

So it's already been noted there are problems with the above... since it
was intended as an example I'll add that I don't like the principle of
things being arranged based on system dependencies. Yes, the ISO team
needs a stable grimoire, but I don't think that alone should make one under
the other.

> One possible organization (using some of the above ideas):
> Project Lead (or Council of Elders formed of all the teams)
> |-> Quality Assurance Lead (PL Assistant)
> |-> Grimoire Team (QA Assistant)
> |-> Sorcery Team (QA Assistant)
> |-> Cauldron Team (QA Assistant)
> |-> Tome Lead (PL Assistant)
> |-> Public Relations Team (Tome Assistant)
> |-> Web Team (Tome Assistant)
> |-> Server Team (Tome Assistant)
> |-> Documentation Team (Tome Assistant)

This is similar to something I was throwing around, but didn't end up
suggesting because I just don't like adding more tiers, and a lot of the
grouping doesn't seem natural beyond having the 3 dev teams together. You
could get rid of the second tiers by keeping the TLs reporting to the PL
and just have optional APLs in those two roles, but I'm not sure how much
it would all really help. I also wouldn't really call those two top level
positions what they're called there, because I don't think they really
relate to the current positions named. In the end I'm not really sure we
need a separate QA team as much as we need the other TLs managing timely
releases of their components. Those are sort of minor things but they can
color the discussion anyway so I'll put them out there.

Can anyone give some history of why we have so many defined teams for such
a small project? I'll go out on a limb and suggest it might be more
natural to not have it this way at all. Our developer base seems to split
more naturally between those that mostly work on individual spells in
certain areas of interest and those that work on whatever big things looks
interesting or necessary at the moment, with a few others who really
specialize in certain components like sorcery or the installer. But even
those last tend to take serious interest in other areas if they look
important to the project.

A possible arrangement based on the above would be something where we keep
the TLs, but not the teams... make the TLs component leads or something
instead, or the "council of elders" idea but with a PL still over them.
Basically, have the majority of developers that work on spells continue to
do that, then have a tier of more "free agent" types who are working on the
hairier stuff, then from that group have specific leads identified so we
continue to have ownership and oversight of the major areas instead of
anarchy, then a PL over them. This arrangement would be very similar to
what we have now except it would allow various team members to move more
freely between projects as they're needed or want to, and would put a bit
more responsibilty on the leads to make sure their areas were progressing
toward their goals. I'm mostly making this up as I type it, but it seems
like it might describe the kind of thing that happens naturally now.
Acknowledging it and actively supporting it might find us spending less
time spinning wheels and more time getting things done.

Attachment: pgpa9Qh7VuPMR.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page