Re: (dsssl) The Future of DSSSL

Subject: Re: (dsssl) The Future of DSSSL
From: Trent Shipley <tcshipley@xxxxxxxxxxxxx>
Date: Wed, 9 Jan 2002 01:08:07 -0700
<header>minutes of first week's discussion</>
<header>Part 2</>

<topic><header>Management issues</>

Resolution of many management questions depend on information from Javier 
Farreres de la Morena.

The primary problem is the organization of the project and where it will get 
most of its hacker resources.  F de la M has indicated that he is willing to 
volunteer his students.  This implies that the project will have resemblences 
to Ingres or BSD Unix, albeit on a smaller scale.

Project scope thus will depend heavilly on

-- Number of students volunteered
-- Level of student talent (Eg Arizona State mediocre, MIT excellent)
-- Level of student education (undergrad vs grad)

-- Whether any other professors are in a position to volunteer any other lab 

Note that Rahtz has questioned whether the project poses any interesting 
theoretical problems.  If not, then it would be inappropriate for graduate 
students and possibly even for upper-level undergraduates.  Note that there 
is also the question of whether it is technically challenging enough to let 
students demonstrate virtuosity.

If volunteered students do form the main body of coders its adds the 
management problem of how to integrate non-student volunteers into the 

Reliance on student coders will also dictate policy throughout the OJ2 
project since OJ2 policies will need to acomodate the institutional demands 
of our gracious University suppliers.  (Eg. if students work in C++, then 
everyone does.  If its CLOS Lisp, everyone uses CLOS Lisp.)

<topic><header>Proposed management requirements, tasks, etc.</>


        <>The project shall be coded in C++</>
        <>(xor) Programmers shall have a choice of any reasonable, compilable 
source languge [ecclecticism]</>
        <>(if the latter) Objects will be passed between modules using (pick 
one: XPCOM, Freeware CORBA product, etc.) </>

        <> Jade internals will be updated
        <> OO documentation for legacy code will be produced in a timely 
        <> Documentation of legacy code will include UML diagrams where 

<> Recycling</>
        <> Whenever possible existing code will be recycled.
        <> Freeware code for similar projects will be examined for 
incorporation into OJ2
        <> Relevant third-party modules and functions will be documented for 
        <> Reuse of existing Freeware Scheme implementations is a priority 
for the expression lanugage (XL)

<> Backends</>
        <> A list of desired backends will be compiled
        <> For each backend a list of requirements will be compiled
        <>  For each currently exsting backend (eg JadeTeX) the mantainers 
will be asked to keep OJ2 current on the requirements for the respective 

<>Project naming</>
        <>OpenJade 2.0  (entire project scope)
        <> OJ2 (short)
        <> MOJO-L (code-name.  cf: Potato, Seamonkey.)
        <> SP2 (parser)
        <> Grover (grove engine)

<>Contact existing admins.  See if they want to continue.

<>Determine whether to stay on SourceForge.

        <> Coordinator(s) (De Facto is Javier, whether he likes it or not)
        <> Architect or Architectural committee (Javier)
        <> Secretary (Shipley)
        <> Librarian [CVS, etc]
        <> Archaeologist(s) (Shipley)
        <> Analysts
        <> Tech-writers
        <> coders

<>Schedule, deadlines, milestones (Get some)

    <sublist type="ordered">
        <>  Stake or share claim for problem area  (required)
        <>  Study relevant existing code (suggested)
        <> Draw UML for relevant code (Required)
        <> Add diagram to Jade Internals (Need for CVS committ)
        <> Study standard (suggested)
        < id="propose-plan"> Revise UML, do other pre-programming to 
incorporate standard (suggested)
        <> Propose final class diagram and docs (Req4Comments, required)
        <> Modify docs (and code at contributors option, required)
        <> If there exist comments go to "propose-plan" until Librarian 
allows commit.
        <> Incorporate into the total UML and documentation, edit until 
        <> Update or write code.
        <> Ammend UML, code and docs per Request and discussion (Go to start)




 DSSSList info and archive:

Current Thread