This is incomplete, obviously. I just wanted something in place for people to mock.

Please add any comments to the bottom of the doc. (I may remove them as I update the doc, but the feedback will be helpful).

-- CoKe 09 Sep 2003

Goal

The goal is to make it as easy as possible for people to contribute: ideas, code, and documentation.

History

lilyCore is written in moo, which by its nature makes it very easy to post incremental updates on a live server.

One of the downsides to this is that it can make it somewhat difficult to manage the process of development.

The User Community

Should comment about xian's design notes

The Developer Community

Some of the roles in the community _usable for

Senior Server Developer

• has written at least one large subsystem, new feature, etc.
• is familiar with most of the core.

Junior Server Developer

* has contributed in some fashion to the server.

Client Developer

• A stakeholder in server development - has a vested interest in insuring that the client interface(s) to lily are sane and usable.

Kibbitzer

• Able to contribute to generic CMC design issues, but not actually familiar with the guts of lilyCore. Typically has lots of experience using CMCs, and may have even written one (or more) of their own.

The User

• The person stuck using the system. Generates bug reports, feature requests.

The CIO

A stakeholder for the deployment of lily. Very interested in security, footprint, admin "costs", etc. Primarily a consumer of documentation.

Analysis

Architecture

Design

Design Review

Remember, lily is a community project

Implementation

This document is probably going to assume you're using tigerlily to edit your code _I expect developers familiar with other moo development tools to spruce this section up_

Coding Standards

Use argument scattering. User level commands should never throw an exception. Utility methods should use exceptions as appropriate. While there is a trend at the moment to have each exception also potentially notify the player, this should be discouraged. The handler should determine what message, if any, is appropriate to display to the user.

Comments

Verb headers: All verbs that correspond to a user level command should be documented as such. Until the help project is undertaken, the usage should be listed here. (as well as in the help). Other verbs should explicitly list any arguments they take.

Code Review

Test

Documentation

lowering the barrier to entry on documentation contribution:

There are currently many sources of documentation. An effort should be made to c onsolidate. I think everything can go into the wiki except for the actual help. While much of the wiki can be for discussion, areas will be set aside for docume ntation. documentation will start out as "proposed" and will eventually be upgra ded by an editor to "effective" (I'd want final, but on a wiki, nothing's final) .

Types of Work

Bug Fixes

Feature Request

Project

-- CoKe - 09 Sep 2003
to top