[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SEUL: group organization
The complete group breakout is ready. The following is pretty much just
a dump from lynx. For better viewing, you may want to see this at
http://www.seul.org/doc/structure/groups/group-breakout.html
This is the group organization we plan to follow (although if changes are
appropriate, then changes can be made). A current version will be kept at
that url.
You'll notice that there are still some leader spaces open. If you want to
take one of these on in the development area, just email me directly.
Next thing: we'll soon be organizing mailing lists. So they'll be at seul.org.
(btw, i kinda like the name seul, but i'll ramble about that later), and
each major group should have its own mailing list, so you can sub to
whichever areas you're interested in following/working on. (Some references
to new lists are also made below - but note that they are *not* active yet.)
And the other next thing: I have design plans for the SEUL system. woohoo!
I'm going to brush them up so they are actually readable, and post stuff for
open discussion withing the next day or so.
Top-level group breakout
The SEUL project is organized hierarchically, starting with seul-...
top-level groups, each of which is then broken into further branches
as necessary (eg, seul-foo-...). A software component maintained by a
specific group can then also be easily identified as
seul-foo-bar-baz:productname, for example.
The goal of this organization is to divide SEUL up into manageably
sized teams, designed so that each team can do its work well, with
minimal direct interaction between teams. This is important because
SEUL is going to be a very large project, not an overnight hack, and
may have upwards of 100 people working on it at a time. It is
important to keep things organized, since we are trying to create a
uniform, integrated operating environment, and that will not come
naturally out of 100 people haggling and coding without organization.
Toward these ends, the following defines a layout for the SEUL
project. The average "independent" team consists of at most about 10
people each, which is manageable, and necessary interaction among the
teams (which are really interdependent no matter how you slice it),
can be carried out in a relatively systematic and restrained manner.
seul
seul-leader(s): Oversees the entire SEUL project. This concept is
still under debate...
* seul-sys
Maintains the services used by our developers on a day-to-day
basis. This includes SEUL servers and custom-built software tools
(eg seuldoc). A specific seul-sys-leader is not necessary.
It is best to contact the group most related to an issue directly,
though mail to seul-sys reaches all primary maintainers. The
following sys groups and maintainers currently exist:
+ mailing list admin: cl@txcc.net
+ web admin: omega@aracnet.com (root == cl@txcc.net)
+ cvs admin: luka@mit.edu, omega@mit.edu (root == luka@mit.edu)
+ seuldoc maintainer: arma@mit.edu.
* seul-pub
This group is in charge of communicating with the outside world:
web/ftp design and maint, responding to inquiries, posting to
others' lists/newsgroups, etc.
seul-pub-leader: omega@aracnet.com
webmasters: omega@aracnet.com, jsiren@pc164178.oulu.fi
* seul-dev
The actual development team. Overall system design/specification
is done by 1-3 system architects. Various subgroups, each with
individual leader(s) handling further development and coding of
specific modules. One seul-dev leader oversees the whole thing,
making sure that things are working as desired: architects are
listening to others' input, implementors are following specs, and
everything is staying well-balanced.
+ seul-dev-leader:
The development team leader. Currently luka@mit.edu
+ seul-dev-sysarch:
The system architects. Currently luka@mit.edu
+ seul-dev-*:
The various actual development groups. See below for the list
and descriptions of these groups.
Development groups
These are the 6 seul-dev- groups. Each should be headed by one or two
leaders. At least one of the leaders should be a programmer with
expertise in that group's area, and should write a lot of the
structural code in that group. If there are two leaders, it may be
convenient to have one deal more with programming and one with
management and communication. Beyond this the organization of the
group is up to the group leader(s), though if any group needs to grow
beyond about 10 regular members, it may be necessary to either branch
out the group further, or otherwise keep the group at a manageable
size.
* seul-dev-distrib
This group defines and assembles the actual SEUL distribution.
Leader: none currently
Basically, final configuration of the SEUL product is done by this
group. Think of this as configuring content, as opposed to writing
the system to support that content. This group should make sure
that adequate input has been gotten from surveys and other
research, so we are sure that the content we are releasing will be
widely appreciated. The scheme is that install/admin devise a
system such that various default/customized packagings can be
configured (sort of an extra layer of abstraction above the
current concept of packages), and the distrib group fills in the
spaces deciding how the contents of the seul distribution should
really be grouped, and what users would want what configurations,
as well as how many of these we want to support directly
ourselves.... For example, deciding if we want a "home" setup, a
"business" setup, a "school" setup, etc, and what they need to do.
This is a sufficiently abstracted concept that distrib can work on
specifying our desires for the final system while admin
simultaneously is still coding the actual system to support the
desired configurations (and others, if done well!)
* seul-dev-install
Develops the installer. This includes everything from backing up
and repartioning through the first time the system boots on its
own from hard disk (or equivalent).
Leader: none currently (maybe Bill Thanis)
Interacts first with admin and distrib groups, who define the
shape of the system the installer will be installing. For now, the
distrib group will have the most influence on the look of the
installer, defining things like available user types and related
installation options.
Also may reuse code or specs from the ui group, but for the first
implementation that may be disregarded, since writing good,
friendly installer tools will be hard enough to start with.
* seul-dev-ui
Abstract ui management toolkits, and some coding of "glue" UI
stuff.
Leader: none currently (maybe Bill Thanis)
Two main responsibilities:
1. Common gui look and feel among apps. This group
defines/writes the toolkits and conventions that should be
used in all seul software, thus providing for something linux
does not have now, which is a common look among all [seul]
applications. This makes the user more comfortable, and more
productive, by being used to gui conventions between apps. It
also takes the work of creating good ui components into one
group, hopefully with members specializing in ui design, to
provide for high-quality designs that can be shared.
2. Define/code the main gui. The goal is sort of to make the
user never have to see a command line. Provide window manager
setups that will start the user off in a reasonable graphical
environment, and create a system for others (admin and app
groups) to extend the content of the ui, without breaking the
intended look and feel.
Basically, once the ui group is through with their work, no one
else should have to specialize in gui design in order to create a
good-looking seul app.
But NOTE: There are a lot of gui toolkits already out there. I
expect this group to reuse as much as possible, before inventing
an entirely new system from scratch! Writing everything from
scratch would be a huge, unnecessary undertaking. Just remember...
GPL, please.
* seul-dev-admin
Admininistration software - automated, manual, and a centralized
database for keeping everything synchronized.
Leader: none currently
Main responsibilities:
1. SEUL's master database - which watches/logs all
installs/deinstalls and keeps things in sync, and complains
if things are messed up. Should be closely tied to the
package manager, as well as other utilities such as tar,
install, etc.
2. Admin interface software - writing basic sysadmin
apps/applets (think control-panel), and creating a
[programming] interface to the admin database.
3. Automated admin. Make things that need to happen happen. Cron
jobs and bootup jobs to do scans and keep thing happy. Log
rotations are an example of stuff written for this task.
NOTE: Admin programs, the packager, the master db, and the layout
of seul config files, will be VERY closely related. That's why
they are all dealt with by one group. Distributing them would lead
to too much interdependency among groups at this level.
* seul-dev-apps
All user apps that are not the duty of another group.
Leader: none currently
Gather apps. Port/hack apps as necessary to fit into the seul
spec. Write any important apps/applets still missing. In the long
run, people in this group can expect to be freely writing apps to
run under seul, or helping third-party vendors make their apps
seul-compliant.
* seul-dev-help
An integrated online-help system.
Leader: twoducks@globalserve.net
1. Write a help browser, and a spec for other apps to use for
invoking/controlling it.
2. Specify the help document format.
3. Write some actual help docs too. This group may also acquire
specialists in writing documentation, who help write docs for
other groups' stuff.
----------------------------------------------------------------------------
Simple End User Linux Mailing list
To be removed from this mailing list send a message to majordomo@txcc.net
with the line
unsubscribe seul-project
in the body of the letter.
----------------------------------------------------------------------------