head	1.1;
access;
symbols
	TIGRIS_1_1_0RC2:1.1
	TIGRIS_1_1_0RC1:1.1
	TIGRIS_1_1:1.1.0.14
	TIGRIS_1_0_8:1.1
	TIGRIS_1_0_8RC3:1.1
	TIGRIS_1_0_8RC2:1.1
	TIGRIS_1_0_8RC1:1.1
	TIGRIS_1_0_7:1.1
	TIGRIS_1_0_7RC3:1.1
	TIGRIS_1_0_7RC2:1.1
	TIGRIS_1_0_7RC1:1.1
	TIGRIS_1_0_6:1.1
	TIGRIS_1_0_6RC5:1.1
	TIGRIS_1_0_6RC4:1.1
	TIGRIS_1_0_6RC3:1.1
	TIGRIS_1_0_6RC2:1.1
	TIGRIS_1_0_6RC1:1.1
	TIGRIS_1_0_5:1.1
	TIGRIS_1_0_5RC6:1.1
	TIGRIS_1_0_5RC5:1.1
	TIGRIS_1_0_5RC4:1.1
	TIGRIS_1_0_5RC3:1.1
	TIGRIS_1_0_5RC2:1.1
	TIGRIS_1_0_5RC1:1.1
	TIGRIS_1_0_4:1.1
	TIGRIS_1_0_3:1.1
	TIGRIS_1_0_2:1.1
	TIGRIS_1_0_1:1.1
	TIGRIS_1_0:1.1.0.16
	TIGRIS_1_0_0:1.1
	TIGRIS_1_0_0_RC1:1.1.0.12
	dlr:1.1.1
	TIGRIS_0_9_2_4:1.1
	TIGRIS_0_9_2_3:1.1
	HELM_PEER_PORT_BRANCH:1.1.1.1
	TURBINE_PEER:1.1
	TIGRIS_0_9_2_1:1.1
	TIGRIS_0_9_2:1.1.0.10
	TIGRIS_0_9_0:1.1.0.8
	TIGRIS_0_8_4:1.1.0.6
	TIGRIS_NOV_12_2000:1.1
	OLDHELM:1.1.0.4
	TIGRIS_NOV_11_2000:1.1
	TIGRIS_SEP_13_2000:1.1.0.2
	TIGRIS_BASELINE:1.1;
locks; strict;
comment	@# @;


1.1
date	2000.05.25.02.07.13;	author jrobbins;	state Exp;
branches
	1.1.1.1;
next	;

1.1.1.1
date	2001.02.21.00.37.09;	author dlr;	state Exp;
branches;
next	;


desc
@@


1.1
log
@initial checkin
@
text
@Tigris Specification

Draft 0.0.4
Alexei Kosut <akosut@@collab.net>
September 4, 1999

OVERVIEW

The goal of the Tigris project is to design and create a framework for
hosting Internet-based (presumably, but not limited to, open-source)
software development. That is, to facilitate the administration of a
system that encompasses the general facilities needed to manage
Internet-based software development (mailing lists, source code
management, bug tracking, etc...), and to make it easy and reasonable
for both new and existing projects to be made available for
development across the Net in a simple yet scalable manner.

This tool, designed to be easy to use and administrate, will
facilitate participation, by both individual and corporate users, in
Internet-based software development, to allow for a vast improvement
in the methodologies of open-source software projects, resulting in
more such software and of higher quality. This increased influx of
proliferating open-source, Internet-based, software, will result in a
large quantity of new users to these, and existing,
applications.

STRUCTURE

The proposed Tigris architecture operates on three levels of
specificity. For lack of better terms, I will label these as domains,
projects and modules. A domain is a collection of projects, each of
which contains one ore more modules, which correspond roughly to the
CVS concept of the same name.

The Tigris set of tools operates on the domain level. That is, for
each domain there exists a completely separate set of administrative
tools, databases, etc... (as the individual technologies admit). The
idea is to allow for domains to represent sets of projects that are
hosted on the same physical machine(s), but are completely independent
of each other in all respects that concern the users of the system,
and the security of each domain with respect to each other. This
includes separate namespaces for each domain to encompass the naming
of projects, users, etc... (again, as technology permits).

The eventual hope is that many independent domains can be served from
the same host machine, but if this goal is deemed not possible, this
functionality is not considered vital.

Within a domain are placed some number of projects. These are intended
to represent separate activities that, while related and of interest
to each other, follow separate development methodologies and have
different interests. For example, were Mozilla development to be done
under Tigris, the Mozilla domain might include projects for SeaMonkey
(the browser), ElectricFire. Projects are the level at which much of
the Tigris structure is focused.

Because the Tigris system is essentially designed to deal with
projects whose eventual output is *something*, code or otherwise, the
constituent part of each project is said to be the module, which is a
term taken from CVS and corresponds to the CVS notion of the word - a
specific subtree of a managed code repository rooted at some
point. For example, to continue the Mozilla example, the Webtools
project might contain modules for Bugzilla (their bug database),
Bonsai (their CVS repository management tool) and Tinderbox (which
monitors automated builds). It seems useful to give Tigris explicit
knowledge of modules rather than relegate it a subset of the CVS-only
functionality, because there are a number of other project-related
functions (e.g., mailing lists, bug tracking, etc...) that are
relevant. For example, Mozilla Webtools developers may be interested
in Bugzilla, but not Bonsai, and making this distinction first-class
allows better ability to manage this sort of functionality.

INCORPORATED ELEMENTS

The Tigris architecture will contain a number of systems that will
combine to form the full tool. Some of these are independent of each
other, and may not be implemented immediately or at all, but efforts
should be taken to ensure that their eventual implementation remains a
possibility.

These are presented in no particular order. Possible implementation
suggestions, including estimated timeframes for completion, are given
later in this document.

* Source Code Management

Specifically, a easy-to-use and fully-functional groupware version
control system to manage source code and other data that a project
needs to store, either for internal or external purposes. Since the
intent of Tigris is to be used to manage software development, this is
the most important part of Tigris, and the rest of the tools are
really centered around managing and monitoring the code that is stored
in this system.

This system is used and configured at the module level; each module
corresponds to a collection of code that might be individually looked
at and used, with little internal dependence on the others. For
example, in the Apache Server Project, various modules might be
apache-apr and apache-nspr, for development of possible future
versions based on different abstraction libraries.

The versioning system is also used to maintain the Web pages and other
information services provided for a project. These will be contained
in the repository system, and edited in a similar manner to the
source. Each project should contain at least one Web site module,
whose contents will be made available by the Web server for that
project; generally, http://project.domain.org/, although the precise
URL may be configurable. Each domain will also include a domain Web
site module, for http://www.domain.org/. Other domain-related Web
sites may exist (e.g., the Apache Group's http://dev.apache.org/), but
these are outside the scope of this document.

Access to the repositories is on a per-module basis, and is consistent
with being a developer on the project with access to the
module. Although the actual steps to granting someone this privilege
of course depends on the human elements of the project, this is a
feature that will likely be granted to the project leader. Although it
seems somewhat anarchistic to allow project leaders to create
domain-wide users, it is unreasonable to expect that the domain
controller will be responsive enough to satisfy the needs of each
project to add new users. Since the security aspects of Tigris should
ensure that a user cannot do any damage that they are not authorized
to do, and that a project leader cannot grant any permission they do
not have themselves, this should be sufficient. The selection of what
permissions each user has - and the ability to grant new permissions
to other users - is of course an important function of Tigris.

* Mail and Mailing Lists

Although the research into telepathy has made great strides in the
past few years, the best way we've found so far to communicate over
the Internet is through plain text, i.e., email. Tigris will provide
direct support for using email to communicate between and amongst
developers and users of the software development efforts it manages.

At the domain level, Tigris will provide mail aliases for the members
of the domain (i.e., the developers involved in the projects). e.g.,
to continue the Mozilla example, all developers involved with a
Mozilla project would receive an email address user@@mozilla.org,
regardless of which or how many projects they work on. This one of the
ways in which the term "domain" for the Tigris term was
conceived.

Depending on the projects involved, it might also be useful to have
domain-level mailing lists, for overarching announcements, or overall
management (although this is probably better served by a special
"management" project).

The main mail features come at the project level: Each project will
come standard with a number of mailing lists. Mailing list names will
be of the following form: listname@@project.domain.org. Mailing lists
specific to a module will be module-list@@project.domain.org. However,
because the SMTP culture prefers a flat domainspace, each mailing list
list@@project.domain.org will also be available as
project-list@@domain.org.

The standard lists are as follows:

A project development mailing list, for development of the
project. Although dev@@project.domain.org seems a natural name for this
list, it seems based on the existing projects that people enjoy
creativity with the name of this list, so allowing a configurable
suffix for the main development list, to allow for names akin to
perl5-porters and netatalk-drinkers, even though they make no sense,
would be nice.

An announcement mailing list (announce@@project), for obvious reasons:
With a publicly developed software project, many people are interested
in only the output, and not the process, of development. Allowing
people to subscribe to a moderated list containing only announcements
is useful.

A users mailing list (users@@project). Many developers could care less
about the users who use their software, preferring to concentrate on
their own development efforts. So certainly allowing
non-bug/feature-related usage questions on the main development
mailing list is undesired of many projects. However, it is still
useful to address these questions, so a mailing list for users to pose
questions of each other is also useful.

"Technical" mailing lists. By this I mean mailing lists for monitoring
some of the project mechanisms, such as the source repository
(cvs@@project) and bug database (bugs@@project). People interested in
keeping track of the status of the project in this manner can
subscribe to these lists to be kept up to date with these issues. In
addition to project-wide lists, some technical lists (specifically,
source repository lists) will have sublists that are per-module (e.g.,
someone interested in all Jakarta source changes might subscribe to
cvs@@jakarta.apache.org, but those interested only in changes to the
JSP implementation could subscribe to jsp-cvs@@jakarta).

It also will prove necessary to be able to create project mailing
lists on an ad hoc basis, both to provide sublists of the developers
or users mailing list for those who wish to communicate on a
particular subject without disturbing others who don't care (e.g., the
apache-docs mailing list), and to provide a way to communicate with
people not involved in the project proper, but still interested in a
particular subject (e.g., beta testers).

It may be convenient to make some of these mailing lists per-module
instead of per-project. In general, mailing lists for the project
should be highly configurable (although this goal may not be
attainable for the first Tigris prototypes), so long as the lists
remain within the namespace of the project and do not interfere with
other projects. This should be an issue, if the naming of mailing
lists is well-defined. Except for a few cases (such as root or
postmaster), project administrators can control the namespace under
project.domain.org, also by implication giving them control over
project-*@@domain.org.

* Mailing List Archiving and Indexing

Since discussion is the main vehicle of progress in these sorts of
projects, maintaining history and easy browsing of that discussion is
important. Tigris should provide archiving and indexing of all its
mailing lists, and make them available for browsing by the subscribers
and the general public if desired.

* Bug Tracking & Database

Once code has been written, locating and fixing bugs is very
important. A good bug tracking system is important to this effort. It
must make it timely and efficient both for users to submit bugs that
they have found, encouraging them to submit all the needed information
to resolve it, and to allow developers to be kept abreast of the
currently outstanding bugs and their complete status. It also needs to
make it easy to look at the status of closed bug reports, and to allow
users to see if the bug they want to report has already been submitted
and/or fixed.

The bug database probably belongs at the project level, although
allowing bugs to be cross-referenced or moved between projects in a
domain may be handy as well, especially when the projects are very
related (e.g., Mozilla).

* Web Server

Much of the project status information, as well as the Web pages
themselves, will be accessible via the Web. For this, a Web server is
needed.

* Source Browsing

In addition to being available via the repository mechanism directly,
it is useful to be able to have the source code of the various modules
available for direct browsing on the Web, including access to history
and other version control information.

This system can be simple, but can also be highly complex, such as
Mozilla's Bonsai system, which interconnects with their build system
and allows the source to be browsed for a concept of responsibility
(i.e., who broke what, when and why). It is not clear that Tigris will
need this level of control at the initial stage of development.

* Offline and Anonymous Repository Access

There exists a continuum of ways to access the source code to a Tigris
project, with varying degrees of access and network bandwidth
needed. At one end is the completely on-line solution, browsing the
source code via the Web (see "Source Browsing" above). Beyond this is
the 'standard' mechanism for accessing the source, with local
(checked-out) copies of the source, but with meta-information access
(e.g., changelogs and alternate versions/branches) and changes
requiring access to the Tigris server. The other extreme is to allow a
complete copy of the source repository to be present on a remote
machine, to allow that user full access to the data (updated at their
discretion), and all meta-information, without necessitating access to
the Tigris server be available at all times.

Likewise, there is the range of access privileges necessary to access
the source repository. Obviously, write (commit) privileges to a
module should be fairly restricted, to users known and trusted by the
project. However, there is a wide diversity in the read options
available. Some projects might favor a closed model, where only
developers can access the current sources. Others might allow many
users to access the repository, but require those users to register
(e.g., be given domain user accounts with near-zero
privileges). However, for many projects, it is useful to allow fully
anonymous access to the current development repository. This allows
users of the software to remain current, and to merge their own
patches in with the most current development release.

Tools that allow such 'alternate' accesses to module repositories are
available, and should be integrated with Tigris.

* File Distribution

At certain points in any software development project, releases are
made. The software is packaged for consumption by the general public,
possibly with binary releases, release notes, etc... In general, this
sort of file management is too heavyweight for a source management
system, and some other system is needed.

In addition to the simple needs of file distribution - providing
managed WWW and FTP access to a depository of distributed files,
Tigris could provide more advanced access: facilitating the storage
and organization of old releases and patchfiles, providing archiving
and compression facilities (e.g., making the same fileset available in
.tar.Z, .tar.gz., tar.bz2, .zip, etc... formats), managing checksum or
public-key authentication of distributed files, etc...

This system also needs to fit in well with the mirroring strategy (see
below)

* Mirroring

A succesful Tigris-build project may very well become popular enough
that a single server is not sufficient for the project's popular needs
- that is, the delivery of WWW pages and of distribution files
(tarballs of software, documentation, etc...). Although it is not
stipulated that the Tigris mechanism itself (i.e., the administration
interface, the source repositories, the bug database, etc...) will
need to be mirrored between machines, since access to these is mainly
limited to developers, it proves very useful to have a mechanism for
easily mirroring public content (WWW and FTP areas) to other servers.

It should be easy to mirror such content to any server, without
requiring that it run the Tigris system. It should also be possible to
keep track of which mirrors are up to date, and present users browsing
the Web site with a list of mirrors and their locations.

* Build Management

Automated building and testing is a useful feature for any software
developer to have. Although this is probably not a feature to be
implemented immediately in Tigris, the ability to manage and report on
automated builds of each project is a useful capability to allow for
in future development.

* Project Management & Status

Many open-source projects have a similar view of the mechanism of
development - most of them use the same or similar tools to manage the
code, to distribute it, to discuss it. However, what varies greatly is
the administrative process used to manage the project. Whatever this
process is, however, some method of monitoring the project and its
status and direction is needed

Most open-source projects seem to do this on an ad-hoc basis,
especially since they mostly consist of volunteers who are not paid to
do any specific thing. However, it may be useful to provide facilities
within Tigris to manage the engineering the project, even if the
actual management method is unknown.

Although this is likely to be a later addition to the system, some
possible aspects of this might be among the following:

- Voting/poll-taking: Many projects operate on a democratic system,
  where some segment of the population has the ability to vote on what
  should or should not be done with the project. Even those that do
  not may find it useful to be able to get popular (or critical)
  opinion on various topics. Therefore, the ability to easily set up
  votes and monitor their outcome would prove useful.

- TODO/project/wish list: One thing that all projects share is that
  they are unfinished (if they were, there would be little point in a
  development framework). There are, in general, two directions a
  software project expands in: fixing bugs and adding features. Bug
  tracking is dealt with elsewhere in this document, but new and
  revised features (using "feature" in a very loose sense that can
  include documentation, T-shirts, etc.) are at the heart of most
  open-source software development projects.

  Providing a managed list of the current plans for the future of a
  project is something that Tigris could provide. Various lists of
  planned features, prioritized and with current status, would be very
  useful both internally for developers, and externally for
  users. It is often the case that such lists, when maintained on an
  ad hoc manner, become outdated and useless quickly, and are useless
  for the casual observer. Providing a good mechanism for implementing
  these sorts of lists would be a big help in organizing and finding
  direction for any project.

- Patch/contributed code database: Most Internet-based software
  development projects welcome code submissions from outside
  developers (after all, that's often the point), but patches are not
  usually directly applied. They need to be reviewed, to ensure
  correct functionality and style. Their applicability may be
  debated. There may be legal issues that need to be taken care of
  (e.g., the FSF contributer forms). All of this makes it easy for
  contributed code to be lost.

  A database similar in spirit to the bug database, for but code,
  would definitely be a useful addition to Tigris. The database could
  keep track of which patches have been submitted, their status,
  etc...

* Tigris Administrative Tools

The Tigris system is intended to be easily used and administered right
out of the box. To this end, administration of a project
(adding/removing users, mailing lists, projects, modules, etc...)
should be easy. This will be accomplished via a Web-based
administration system that provides an HTML-based GUI for making
changes to the system.

This makes it possible to host a project without having direct (shell)
access to the machine, without having deep and intimate knowledge of
the tools used in Tigris, and minimizes the possibility that the
system can be screwed up by a well-intentioned but clueless user.

ACCESS TO A TIGRIS SYSTEM

Since one of the possible uses of Tigris is in a project hosting
service, it is considered undesirable to give out shell accounts on a
Unix machine for everyone involved in a hosted project. All necessary
access should be contained within the Tigris system itself, and all
necessary tools should be accessible through the Web page.

Each user is afforded a set of permissions at each of the three
"levels" of access to the Tigris system - domain, project and
module. The user can be granted permissions at the domain level, or to
a specific project or just one module. These permissions may include
reading and writing to CVS repositories, adding and removing users
from the system, and granting permissions to other users. A flexible
permission system will allow for Tigris to accomodate a variety of
different management schemes.

Since Tigris is intended mainly for use with open-source software
projects, access by the uninitiated public is also important. This
means that (although there are times when this feature needs to be
able to be turned off) nearly all facets of the Tigris system need to
be readable (although not writable) by the general public, without any
special privileges or connections.

IMPLEMENTATION IDEAS

Since Tigris is intended to be used with open-source software, it
should be comprised of components that are also freely
available.

Nearly all open-source software projects these days seem to be using
CVS to manage their source repositories. Although CVS has some
failings, there seems no better choice available, and it is nearly
perfect. It's also familiar to most developers, having used it or its
cousin RCS.

Mail seems well-suited to be set up by qmail. Qmail is fast and
scalable, and it is easily configured by an external program (unlike
sendmail, which requires all sorts of odd syntaxes that can confuse
each other). Tools are available for qmail that handle most of the
mailing capabilities we need - mailing lists, virtual host aliases,
Web-based stuff. It seems a good fit.

The fastest Web server today is, without a doubt, Microsoft IIS. And
although IIS is free, it unfortunately only runs on Windows NT
Server. As the rest of the tools require a Unix platform, we will have
to settle for the second choice, the Apache Web Server. Although I
have a personal bias, I believe Apache to be well-suited to the
project.

Configuration and management issues aside, the one item that most
projects seem to be lacking is a really good bug tracking
system. Unfortunately, there appears to be no good solution to this
problem. Mozilla's Bugzilla is nicer than most I've seen (certainly
nicer than the GNATS-based system that Apache uses), and it may be the
base for Tigris' solution. But it is not perfect, and some desired
functionality (such as interaction with mailing lists) is not
present. The bug database issue is one I anticipate being a time sink,
but a necessary one. For this reason, bug tracking is an issue that is
not being directly addressed in the initial prototype of Tigris.

Since one of the ideas behind Tigris is to consolidate the
administration of a software development hosting system into a concise
and scalable system, a database for back-end configuration storage
makes a lot of sense. Since many of the tools under consideration can
make use of, or even require, MySQL, it seems a good choice. It is
free, claims to be fast, and well-supported in many programming
languages, including C, Perl and Java.

In fact, use of a database enables the project to be very cleanly
divided into two distinct parts, with the database sitting in
between: the database is used to store configuration and
administration information about the Tigris system, which is pulled in
from a front-end system and pushed out to a back-end system.

The front-end system will allow administrative access to the Tigris
system. It might be in the form of a Java servlet, or a PHP page, or a
Perl script, or a SNMP translator, or a Win32 application, or direct
SQL manipulation. In this manner, users can manipulate the data in the
database with no need to worry about what happens to that data, so
long as they keep within the frameworks of the database schema. This
means that the front-end need not worry about the actual
implementation of what it manipulates - the program backing the Web
page a user uses to change their email alias need know nothing about
how mail works in Tigris, which lowers the total complexity of the
system and the number of things that can go wrong or be broken in
future revisions.

Since the initial applications of Tigris are Web-based, the initial
implementation of a Tigris front end will be a set of WWW
administration pages, likely written in Java; an object-oriented
language like Java is well-suited to the forms of management that are
being dealt with here, and Java's platform-independence and good
server support (the servlet API) and database connectivity (JDBC) make
it well-suited to the task.

An independent back-end system, driven by the database, pushes the
contents of the database into the configuration of the various tools
that make up Tigris (CVS, qmail, etc...) and ensures that they are set
up to match the database. In this way, regardless of how the database
got to be the way that it is, the back-end of Tigris ensures that
reality matches the data.

There are two distinct methods that can be used in implementing this
back-end. The first is to extract the information from the database,
and write it into the flat files normally used to configure each
component of Tigris. This is probably best accomplished by a set of
Perl scripts - Perl is very good at this sort of task, and also has
good database connectivity (DBI), well-suited for reading out data and
inserting it into templates of configuration data. The other method is
to modify the Tigris components to read their configuration directly
from the database itself, instead of their normal configuration
files. This has the advantage of not requiring any intermediate
conversion stage, or awkward translator mechanism. The cons are a very
high complexity to implement, and a likely wide diversion from the
original code base of the tool.

The suggested implementation of the back end is a mixture of the two
methods: Using Perl database-to-flatfile translators in some
instances, and direct database access in others. The choice of which
method to use in each instance is mediated by the complexity of
implementing the database access vs. the utility and speed gained by
direct database access. For example, the configuration of Apache
virtual hosts is probably best done by a converter rather than
converting the Apache configuration mechanism into a database access,
whereas restricting access to the Tigris administration pages is better
suited to directly matching the username and password against the
database, rather than constructing a file with this information, and
using the standard Apache file-based authentication mechanism (in
fact, an Apache module already exists to do this with a MySQL
database, so much the better).

The author of this document believes that the split approach outlined
above is best suited to this project, for both the near and far
timeframes. In the short term, this allows the front or back end to be
worked on aggressively, with a tool appropriate for the job (e.g.,
using Java to output qmail configuration files would be a nightmare,
whereas it is well-suited to assigning permissions to users), without
worrying about the interaction between the two too much - the database
funnels the data between the two halves and 'takes care of
it'. Likewise, in the long term this clear division of labor for
Tigris software leads to a clear division of labor for Tigris
engineers. It will make it possible for those who continue to develop
Tigris beyond its initial versions to understand it easily and extend
it in clean and appropriate ways.

IMPLEMENTATION PLAN

The initial stages of Tigris implementation can be divided into a
number of distinct tasks. They are presented here in rough form, with
estimated durations for each. Note that they need not be completed in
precise order - it may well be useful to do development of some items
in parallel, to ensure that the components integrate smoothly and to
more quickly create a demoable system.

* (done) Design of Specification and Implementation Plan: Examine
  existing Internet-based development projects and available
  Internet-based software engineering tools. Evaluate what
  capabilities Tigris need have and what components should be best
  used to provide these capabilities. Draft a written specification of
  these components and an initial plan for implementation, with
  specific milestones. Estimated time needed: 2 weeks (completed)

* (done) Initial Component and Back-end Implementation: An
  implementation of a number of basic and necessary components of
  Tigris, and the back-end software necessary to drive them from the
  Tigris database. This early components should probably include CVS,
  mail and a Web server. Other components may be included as well, and
  certainly the necessary hooks and extension mechanisms should be
  included to make it easy to add the rest of the Tigris system
  described in this document without invalidating the code
  written. Estimated time needed: 3 weeks (completed)

* (done) Initial Front-end Administration Implementation: A basic
  Web-based administration interface for the administration of the
  Tigris system and the configuration of the components in the initial
  back-end implementation (although this stage should be started after
  the previous one is started, waiting until its completion is
  probably a bad idea). Emphasize functionality over appearance (e.g.,
  HTML, graphics, etc...), but make the code itself clean and
  extensible, for further Tigris implementation. Estimated time
  needed: 3 weeks (completed)

* (done) Documentation, Packaging and Sharing: It is one possible goal
  of Tigris to be made into an open-source development project
  itself. Certainly, development will continue after the inital
  prototype phase, and whatever form this development takes, the
  developers involved will need Tigris in a form they can deal
  with. For this reason, Tigris will need to be well-documented, with
  clear instructions on installation and configuration of the package,
  as well as development methodology. Also, if a larger group is to
  take over development of Tigris, that group needs to be founded and
  members located. Estimated time needed: 2 weeks (completed)

* Usability Testing and Focus Groups: After Tigris progresses into a
  working prototype, it may prove useful to try to use it in a
  real-world setting, to evaluate its usability and what additions or
  changes might be needed. For this purpose, installation of a Tigris
  prototype in a real Internet software development effort and a study
  of how it is used would be useful. This may not be possible in the
  initial phase of development, but should be considered a priority
  soon afterwards. Estimated time needed: ???  

CONCLUSIONS

There are a lot of issues to be resolved in the design and
implementation process for Tigris. This document attempts to make a
first stab at addressing some of them. There are probably quite a few
that this document does not address that, either because the author
has forgotten about them, or that will come up in the development
process. Hopefully these can be resolved in a timely manner and the
Tigris project can go on to fulfill its true purpose: Mastery of time
travel between the seventeen dimensions of the universe.



@


1.1.1.1
log
@Replacing the HEAD with the HELM_PEER_PORT_BRANCH.
@
text
@@

