By creating the CedarHacks 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. Much of what follows is directed to hack writers, but hack 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 5.2, <CedarHacks®> means <CedarHacks5.2>. All directories mentioned here reside on the file server that holds the Cedar release, currently [Indigo]. This document and the forms mentioned below can be found on <CedarHacks®>Documentation>.

A "hack" is a useful (or semi-useful) program which is made available to the community of Cedar users as a public service. Don't think of "hack" as a four-letter word. A hack is not shoddy software; it is software made available outside the regular release channels.

Hacks must be easily distinguishable from released software. In particular this means that hacks may not have the same name as released software, and should be somehow different in appearance. Updated versions of released software belong on <PostCedar®>, not on <CedarHacks®>. Hacks may depend on the Cedar release or on other hacks, but the Cedar release must not depend on any hacks. Hack users who are also Cedar implementors must be particularly careful not to allow released software to become dependent on hacks.

A hack may become so useful that it becomes part of some release and is thereafter supported. If this occurs, the Cedar administrators must ensure that any other hacks that it depends on also become part of the release.

No warranty of suitability or responsibility for errors is implied by the author of a hack. As the owner of a hack, 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.

A hack stored on <CedarHacks®> 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 hack on the <CedarHacks®> directory implies a willing transfer of ownership.

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

When you are ready to announce a hack, use CedarHacksMsg.form as the standard announcement form. Try not to flood your user community with a constant flow of new versions (or messages). If your hack 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 hack, enlist some of your friends as alpha testers. Try to avoid having to rerelease a hack within hours of its announcement because of fatal bugs.

Do not announce hacks stored on your own or some other directory to CedarUsers^. If your hack 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 <CedarHacks®> 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 hack 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 <CedarHacks®>Documentation>, as CedarHacksPackageDF.form suggests.

Use CedarPackageDoc.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 CedarHacks will create a catalog of the hacks. This catalog extracts its information for each package automatically from the DF-file on <CedarHacks®>Top> and the documentation file. A sample catalog entry looks like this:

The DF file entry comes from enumerating <CedarHacks®>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 CedarPackageDoc.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.