[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
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-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

     * 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
       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-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.