plans

["Luka@pop3.aracnet.com (Peter)" <luka@MIT.EDU>]

so, it's time for us to start really doing stuff.

we've been around long enough now that it's time to review our current
organization, make changes as appropriate, devise a good plan of action,
and then start executing.  i'm expecting to finish the plan this weekend,
and start things rolling monday.

why change things?
1. the world has been moving around us.  redhat is developing their tbird
   release, turbolinux is out, linuxconf has been updated multiple times....
   we need to re-evaluate our role given current development by others.
2. given our own current situation, with some groups/projects clearly on
   better footing than others, and some strong new additions (such as the seg),
   we would probably be wise to restructure a bit, so as to get the most use
   out of what we have, and not delve into anything unfeasible.

proposed schedule for re-organization:
1. starting immediately, we'll be working out a detailed plan of action,
   encompassing all goals from immediate through long-term.
2. by monday, it should be at the point that we are confident in at least the
   strength group structure we are using.
3. monday, we announce groups (responding to another of ken's questions,
   finally).  we wait until monday, _just in case_ we do change something
   major.  i don't know if we will yet, but 2 days now is not going to hurt
   (as long as we stick to that bound for real).  and then we get down to
   executing, and producing results.

what should this plan look like? (what is the "plan-plan")
 (i debated with omega about this for a while, so this part should be pretty
bug-free by now.)  the plan will generally lay out our goals for as far as
we can see (though only enough to be secure in initial actions needs to be
ready by monday).  there are 2 main things that will be important in
structuring the plan:
1. timeframes will be labelled, and causality from one action to another
   should be noted in as much detail as possible.  this is because we are
   working toward long-term goals, but will have to start with short-term
   steps, and make sure that we produce results and keep interest every step
   of the way, but without losing sight of where we are going.
2. planning will be done on roughly three levels: mission, meta-goals, and
   goals.  mission is our concrete reason for existence, which will not change.
   meta-goals are general goals which will tend to be minimally influenced by
   time (eg, making an admin db come into existence), and goals are particular
   manifestations of meta-goals (eg, writing the admin db).  the reason this
   is dreadfully important, is because we're in the middle of a very rapidly
   progressing game, and when we set down long-term goals, if we're not
   careful, it may turn out that the goals will no longer be valid by the time
   we achieve them.  for example, we may aim to write a user-friendly linux
   distribution in 2 years, but with the way things are going, it's not
   unlikely that someone else _might_ pull exactly that off in one year, so we
   want to make sure that our actions at any step are working toward
   short-term usefulness, and long-term meta-goals, so that we won't end up
   having done a lot for nothing.

so, what's the plan?
 well, there are a few things i want to throw out for consideration, and
hope to hear some thoughtful feedback on.
1. we've sort of been assuming a goal of producing a seul distribution
 up until now.  is this the right approach?  if so, in what timeframe?
 my input: i think if we do this, it will be long-term: 1-2 years from now
 before a real release.  if we're seriously considering doing it, we should
 also think about the implications of producing a release for public, general
 consumption: they'll want something that's supposed to work; we'll want to
 avoid liability and lawsuits if it doesn't.  actually marketing a release
 agressively to the public may have to be done in a commercial context, and
 if we're expecting all this, then it should be taken into account (as
 necessary) in the design of the system.  as the alternative, we might
 consider doing our thing as a bunch of additions to an existing distrib
 (eg, redhat or debian), but in that case, the pitfall may be that we have a
 lot of cool, integrated components that work together built, but the
 distributors might not take the whole thing and merge it straight in.  they
 may just take pieces, and end up with something horrible.
2. if we're not producing a new distrib, what are we producing?
 as far as code goes, components.  we should probably start in the short-term
 by producing components that are designed to fit into something bigger, so
 that we'll be producing useful apps and utilities and stuff all the time,
 but as our resources allow, and if we get there and the time is right, we
 then throw it all together at once, system glue and all, and release a
 distrib.  something else to consider in this case is how to trim/extend the
 group structure we have, to encourage work in areas we are strong in, and
 that are useful.
3. "as far as code goes?" what else is there?  standards... sort of.  more
 like suggestions really.  what i am really getting at, though, is gathering
 and organization of information that will be useful to anyone pursuing our
 mission (including us).  gathering complaints/info from end-user types on
 what they don't like about linux, and turning that into "standards" or
 "suggestions" which would define a better linux if followed, which are
 backed up with actual research, so we know they are good ideas.  also
 introspecting on ourselves: gathering info from people programming
 end-user apps, and finding out what should be changed to make it easier.
 here's one example that illustrates that this is truly useful, not just
 trivia:  config files; currently underdocumented and hard to use whether
 you are a user or a programmer or a program trying to do config admin tasks.
 we could define a document-type-definition (dtd) format which people who write
 apps could use to specify what their config file's format is in a rigid,
 machine-understandable form.  they throw this dtd in with the app, and then
 programs designed to make the user's life easier by putting front ends on
 config file mgmt can be written trivially for any app that uses our format
 to describe its config file.  just link against the seul dtd parser, and
 your program can immediately understand any compliant config file.

so, that's it.  input?
once we have concrete decisions in the making, document drafts should go in
cvs under sys/ somewhere.

communication should be mainly via email, since my schedule is weird, and
irc is not overly conducive to highly structured discussion, which this should
be.  if we find time for it, we might get together saturday night for some
(small) amount of general brainstorming and discussion.  we should try to get
large issues out via email before then, though.

good night,
 -luka
===
SEUL-Leaders list, seul-leaders-request@seul.org
===