Skip to Content.
Sympa Menu

sm-discuss - [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: [SM-Discuss] project organization
  • Date: Wed, 8 Feb 2006 18:58:12 -0600

On Feb 08, Eric Sandall [eric AT sandall.us] wrote:
> As there's been talk of removing the Project Lead position and just
> having a Council of Elders (all of the Team Leads) you may start
> another thread (separate from this one) to discuss that if we're
> wanting to go along that route.

I've been out of the swing of most things for a couple months and don't
know about those conversations, but I have been talking a bit with people
about the way the project is organized, so I guess now is as good a time as
any to have a discussion the list. I've been working on catching up and
was going to wait til I knew I had to raise this, so if I seem ignorant of
things that have happened recently I'm sorry.



Basically it seems to me that our current organization and plans don't mesh
very well with the realities of people's schedules and interests. The
results are pretty severe, as we currently are quite behind on basic things
like security updates and are almost two months past the date we set for
the 0.3 branch of stable and the 0.9.6 ISO.

Note that I'm not trying to specifically blame anyone person or group for
this; I have certainly been as absent as anyone lately. But it does seem
that our existing efforts aren't producing the results we would like, so
it's in our best interests to figure out what we can do better. Frankly
I'm not sure what that is, but I have a couple of thoughts I can throw out
anyway...

It seems to me primarily that the current structure relies too much on
individual Team Leads to be available and pushing their teams forward
toward the established goals. We have almost more processes and teams than
we do active developers, and while the relative role of each varies a lot,
at any given time we probably only have a few leads who have time to be
very active in the project. But the efforts of most teams depend on
others, so that (for example) while the ISO team has been making good
progress on 0.9.6, they can't really make a release until the QA and
Grimoire teams get some other things done. Again, I'm not looking to start
a blame game... it could just as easy go the other direction next time (and
has in the past, I think). I'm just citing examples of where it breaks
down.

The simplest response to this would probably be to try to get a more tiered
approach where some teams are under other teams, but I'm not sure that's
best. We don't really need middle management, we just need redundancy.
Maybe we could look at clustering leads of teams with similar functions so
that if one lead is absent, someone else is obviously able to keep moving
things forward. Maybe the "council of elders" idea Eric mentioned is
something like this, I don't know.

Of course, the above assumes we're taking the right approach even focusing
on the things we are focusing on, like a 1.0 release. I'm not sure we are,
given that we seem to need leads to move things forward this much. I think
another fault of the current model is perhaps that we're asking the
developers to focus a lot on policy and polish things that tend to ignore
where they are actually interested and spending their time. This tends to
lead to things like people referring to policies that aren't documented in
the first place because our web sites are still recovering, or we just have
more policies than time to document them. And while there are still plenty
of p4 commits each day, we don't really get all that much closer to the
goals we're behind on. Whatever the reason, given our numbers it might
make sense to consciously pull back from focusing on a user-facing 1.0 and
spend more time getting an environment developers can really work in,
defined by looking at what people are actually working on or frustrated
with when they do have the time. I imagine that's not a very popular
thought, but at the least it seems apparent that the way we're operating
now is not going to get anywhere near producing the 1.0 on our current
roadmap within the next 6 months.

Attachment: pgpTFiVk42vHQ.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page