By creating the CedarChest directory we hope to encourage Cedar users to share software; we also hope to reduce the current bulk of a Cedar release. The Mesa developers have used a similar mechanism with success; many of the rules here are derived from theirs. (Their mechanism is called MesaHacks. Ours was briefly called CedarHacks, but the name was changed by popular demand.) Much of what follows is directed to writers of CedarChest packages, but users should also be aware of the rules in order to have reasonable expectations.

Wherever the ® symbol appears, it stands for the version number of the current Cedar release. Thus if the current release is Cedar 6.0, <CedarChest®> means <CedarChest6.0>. All directories mentioned here reside on the [Cedar] file server. All the forms cited can be found via <CedarChest®>Top>Forms.df.

A CedarChest package is a useful (or semi-useful) program which is made available to the community of Cedar users as a public service. Some CedarChest packages are large systems; others are simple, one-module hacks. But CedarChest is not shoddy software; it is software made available outside the regular release channels.

CedarChest packages must be easily distinguishable from Cedar release components. In particular, the name of a CedarChest package must not match that of a release component. (If a release component is updated between releases, it belongs on <PostCedar®>, not on <CedarChest®>). A CedarChest package may depend on Cedar release components or on other CedarChest packages, but a release component must not depend on CedarChest. Cedar implementors must be particularly careful not to allow released software to become dependent on CedarChest.

Occasionally a CedarChest package may become so useful that it becomes part of some release and is thereafter supported under the release mechanism. If this occurs, the Cedar administrators must ensure that it depends on no other CedarChest packages, or that such packages also become part of the release.

A CedarChest package remains the "property" of the submitter. Others may not make modifications (except for their own private use) without negotiating with the owner (who may already be making similar or incompatible modifications). In general, modification of a CedarChest package directory implies a willing transfer of ownership.

As the owner of a CedarChest package, you are not required to fix bugs, but you must be willing to transfer ownership (permanently!) to someone who volunteers to fix them. Of course the ownership may pass back and forth among several people as long as they agree.

The directory and DF-file structure for <CedarChest®> is the same as that for <Cedar®>. Each package should be entirely described by a DF-file on <CedarChest®>Top>. This DF-file should pass VerifyDF with no errors or warnings. Imports should come only from <Cedar®> or <CedarChest®>. Use CedarChestDF.form as a sample DF file.

When you are ready to announce a package, use CedarChestMsg.form as the standard announcement form. (Cedar implementors updating the new CedarChest prior to a release should use PreCedarChestMsg.form instead, to avoid bothering CedarUsers^ with irrelevant messages.) Try not to flood your user community with a constant flow of new versions (or messages). If your package is undergoing continual changes, adopt a release strategy of regularly spaced, well tested releases. Your users will thank you.

Testing is important. If you make significant changes to a package, enlist some of your friends as alpha testers. Try to avoid having to rerelease a package within hours of its announcement because of fatal bugs.

Do not announce packages stored on your own or some other directory to CedarUsers^. If your package is worthy of being announced to and used by people you have never met, it deserves to be treated with some seriousness. Get your act together and get it onto the <CedarChest®> directory.

Consider using the CedarUsers^ list to request packages (within reason, of course). It is hoped that this will increase sharing of software. If you're about to implement a new package, why not see if someone else already has one, or is also thinking of implementing nearly the same thing?

Every, repeat, every CedarChest package should have a documentation file. It need not be large — in some cases a paragraph will do — but it should exist. Package.df should store PackageDoc.tioga on <CedarChest®>Documentation>, as CedarChestDF.form suggests.

Use CedarDoc.form as a template. This will make it easier for you to produce the document, and easier for the catalog builder to build the catalog.

Periodically, the administrator of CedarChest will create a catalog of the current packages. This catalog extracts its information for each package automatically from the DF-file on <CedarChest®>Top> and the documentation file. A sample catalog entry looks like this:

The DF file entry comes from enumerating <CedarChest®>Top>*.DF. The Commands are discovered by enumerating the ".Load" files in the DF-file. If the ".Load" files aren't there, then the commands are not included in the catalog — sorry. The Author, Keywords, and Abstract entries come from examining the documentation file mentioned in the DF-file. Certain heuristics are used to discover these entries so please use the CedarDoc.form to create your documentation. Short documentation is acceptable, so create an abstract for the catalog entry even if you have nothing more to document.