[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SEUL: seul-dev task divisions

I have been gathering together leaders for the various seul-dev-* groups, and
soon I am going to move traffic off the seul-project list in an attempt to
get the discussion divided into the appropriate groups. (At this point, we're
pondering making a seul-discuss@seul.org list to take over the random chatter
from seul-project, and making seul-project moderated. It may well be too
early to try to divide things too far. Please respond to seul@seul.org if you
have opinions here.)

These are the current groups and a very brief summary of their tasks (much
text here taken from Luka's posts from long ago). I will be posting a more
comprehensive description of most of these groups over the next few days,
and trying to encourage followup discussion on the appropriate lists. I
think in order for this to succeed, we need strong leadership in each
subgroup. I've been trying to find leaders that are strong coders as well as
capable organizationally.

Don't pick apart details here yet, until I've gotten out the more complete
versions of each description. I'm also working very hard to get people set
up for updating the webpage, so it can become something useful. Stay tuned.

Please respond to seul@seul.org (just the sysarchs) directly if you have any



seul-leaders (omega@seul.org, arma@seul.org)
 We're trying to keep everything working smoothly, in terms of the domain
 setup and admin services (website, mailing lists, ftp, CVS development
 services) as well as broad steering of SEUL goals, groups, etc.

 General SEUL discussion that doesn't really fit into any of the other groups.
 Hopefully the majority of SEUL discussion will take place elsewhere.

seul-dev-admin (nickm@mit.edu)
 1. We hope to provide a robust infrastructure to mediate between
    package managers, user environments, runtime systems, system
    variables, software configuration, hardware settings, and so forth.
    It has not yet been determined what form this infrastructure should
    take, though a solid, registry-like database with a clean API has
    been suggested.
 2. We hope to provide manual and automatic administrative tools for
    the end-user, either by writing ourselves, assisting others in
    writing them, or by choosing a few simple, robust systems from
    among those already in existence.

  Micah Yoder (yoderm@geocities.com) may be leading this group.  This group
will be doing /some/ actual development, but the key priority now is to
gather info about what already does (or doesn't) exist.  There are a lot
of apps out there, and no one really has a good grasp on just how
extensive it is.  (Generally, when I ask a person "does this sound like an
app that has already been written", the answer is "I have no idea; maybe;
do a search".)
  So, collecting pointers to existing app indexes like SAL and the LSM
would be the first thing to do, then defining/adopting a format for
indexing other apps efficiently (both apps created by this group, and
found lying around un-indexed), and finally bringing together a single
starting point for searching for Linux apps.

seul-dev-distrib (grep@oriole.sbay.org)
1. find out and record lots of info about our target user.  figure out large
   classifications of users we can target (home, school, business,
   and any other big ones that are discovered).  figure out what each user
   group wants, and any distinctly good/bad setup for any user group.
   also, note commonalities among groups.
2. decide which user groups we want to support, and the exact configs for
   those user groups (as allowed for by the seul configurability available).
3. write the configurations, compile the distribution.  and complain when seul
   configuration utilities mess up, so we can get them fixed.

seul-dev-help (twoducks@seul.org)
 1. writing a help browser, and specs for other apps to use for
    invoking/controlling it.
 2. writing specs for the help document format.
 3. writing some actual help docs.
    this group may also acquire specialists in writing documentation, who
    help write docs for other groups' stuff.

  This group writes software to get the user from *wherever* to a running
seul system, with minimal effort on the part of the user.  This can be
installing a system from scratch, or installing over or next to an existing
os.  And if the user is trying to preserve data (as indicated by answering
a question like "do you want to keep another os which is currently installed?")
then the installer should be extra careful about not destroying data that may
be related to that os. Things that need work:
 1. an fdisk/fips that rocks!  (read "disk setup utility")
 2. device detection code
 3. the rest of the installer.
 4. seul-extensions in the installer.
 5. gui/help system hooks.

  Abstract ui management, focusing on a common gui look and feel (defining,
writing, finding toolkits and conventions that should be used in all SEUL
software), and defining/coding (preferably finding and adapting) the main
SEUL gui -- interface toolkits for application interaction, window manager,
menus, etc.
  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.

seul-pub (mjackson@seul.org)
This list is for discussion of the web site, the announce, and public-
relations in general.  It is watched carefully by all the project leaders and
everyone maintaining web pages.  Membership for page maintainers will likely
be considered mandatory, so everything can be kept in sync. Seul-pub is
moving into a broader coverage, encompassing all of SEUL publicity and
public relations, Linux advocacy and persuasive documentation.

seul-seg (solaris@cicei.ulpgc.es>
 Seul Expert Group (S.E.G.)
  This is a group of people to coordinate gathering large amounts of
knowledge about our intended userbase and their needs, based on factual
  Current goals: find out what's wrong with linux, and get into writing
exact details about what needs to be done (with prioritization) in order
to make it more user-friendly.  The group is going to need to take vague,
general input from the masses, the seul-project people, and any other
contacts they find useful, and turn them into very concrete statements
about what we want out of linux (backed up with evidence from the input
that was collected).
  Aldo (solaris@ulpgc.es) is managing this, so contact him if you would
like to contribute as an end-user, or know a typical end-user who would
consider participating.