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: Eric Sandall <eric AT sandall.us>
  • To: SM Discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] project organization
  • Date: Mon, 13 Feb 2006 16:21:40 -0800 (PST)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 14 Feb 2006, Mathieu L. wrote:
On Mon, Feb 13, 2006 at 01:30:38PM -0800, Eric Sandall wrote:

<snip>

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)

That cuts us down to two teams (which is probably a gross
simplification ;)), with 2 (or more) PL assistant leads, 3 QA
assistant leads, and 4 Tome assistant leads. For the Council of Elders
idea, all the assistants to leads and the leads would be on the
Council (so about 10 people). Each team could sub-divide more if they
want (e.g. grimoire would also have subdivisions for stable-rc,
stable, and each section).

I'm still pondering about that, in one hand it doesn't seem logical to
me to have Grimoire and Sorcery as subdivisions as I consider them to be
the most important part of smgl. But on the other hand I see the
advantage of having them managed together by a higher instance.
confusing...

The above is mostly just an example of a possible layout.

I think our main issue (as our poll[0] noted) is documentation. If we
can get our documentation (at least for the developers) updated and
finalized that might get more consistency in commits as well as giving
a clear definition of who is supposed to be doing what (with respect
to what maintaining a section means, who can edit maintained or
unmaintained sections, what bugs we need to focus on, etc.).

Totally agreed. if one thing, we need to have a clean website and a neat
wiki for proper documentation. Motivation is probably the biggest
problem here because I don't think many ppl among us find writing and
formatting wiki pages amusing.

I guess that means it's my job to do it (and/or find volunteers). ;)

- -sandalle

- --
Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFD8SKYHXt9dKjv3WERArONAJ9NWzplGH4a4rt8/sAoEouP89M6TQCZAXF+
K67RxZRatgfmrsW0j9Ma3+g=
=H6YL
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.24.

Top of Page