eXperimental Computing Facility (XCF)

Introduction

This note describes the how and why of writing an XCF project proposal. If you do not know about the XCF or XCF projects, check out the XCF purpose. The project proposal, obviously, begins with a project idea. If you do not have an idea for a project, you can check out the available projects page. Ideas are not very easy to think up, so those that we have may not be inspiring. We have noticed that people that come up with their own projects seem to do better. Once you have written a proposal (2 or 3 pages is typical), or if you have questions or comments, email director@xcf. We may also be able to help if you have an idea but need help refining it. Finally, note that the guidelines here can be stretched.

Purpose of XCF projects

The objective of an XCF project is to enhance the education of motivated students by providing resources and direction in pursuing a programming idea, and also to produce something useful for the campus computing community. The following is a set of guidelines. If there is a good, clear reason, exceptions can be made. In general we are more interested in positive results than anything else, and nothing compares to a finished project.

Purpose of a proposal

A project proposal has three objectives: To describe the project so that it can be evaluated for approval by the current XCF membership. You are selling your idea, so be sure to explain it clearly an concisely. Don't get sidetracked; it is helpful to start with an outline. Ensure that the project has been well thought out to the point where a clear summary can be written. This will help as an exercise in writing (you will have to write documentation for your project) and as an exercise in planning a software project (you will never have a project approved by someone in either industry or academia without a clear plan). Provide a summary for our sponsors. For this reason the proposal must be clearly written. Also, game projects must be kept to a low proportion if we are to be taken seriously. We have developed a standard format (see below) for proposals so that they can be reviewed quickly.

Sections of an XCF project proposal

Keep your writing style simple and to the point. Humor should be used sparingly and only in good taste, if at all. The following is the accepted format for a proposal.

Title

Give it a descriptive title so that everyone can refer to the project in the same manner. You do not need to come up with a "name" yet; it is more important to have a one sentence description.

Summary

The summary should be one paragraph that indicates briefly the what and why of this project. Do not go into detail.

Description

This section should fill in the details of what, why, and how for the project. The "why" part should describe a problem that could be solved with the project (perhaps a "background and purpose" subsection). The "how" should discuss the mechanisms that need to be built for the project (e.g. garbage collection, an X interface, etc.). A section on possible extensions should list ideas that would be nice but are not part of the basic project; you are not signing up to work on the extensions, but you should try to structure the project such that the extensions could be added easily later.

Time line

This section should be a list of intermediate goals in the project, along with your best guess as to how many hours it takes to complete each goal. You should be able to check off each goal in order. We request hours and not weeks for the following reasons: as a student, your first priority is class work; class work can take up more time than anticipated, and frequently projects are put off. Delaying a project is not so bad if you have a clear reason behind it (i.e. "goal #3 took 28 hours instead of the planned 16, where I have put in four hours per week, resulting in a three week delay" or "due to midterms, I could put in only eight hours on my project for the month of March"). Secondly, it is a good exercise to think through how much time you think the project will take. If you do not have a basis for making these estimates, than the only way you will learn is to start now by making guesses. Once these guesses are written down, you can come back and watch your progress and get feedback. Estimating time is a valuable skill, and part of the educational aspect of an XCF project. Note also that it is generally accepted that any estimate will turn out low, so don't worry too much about being accurate. Remember, in the end it's for your benefit. (I could go on if you are not convinced, but I will spare you for now.)

Resources required

We assume that a reasonable amount of disk space, CPU cycles, access to a console, and a C compiler and libraries are required; This section should highlight any exceptional requirements that might be involved. For example, a project requiring a large database should list the best estimate of disk space (or simply "enough disk to hold the dictionary"). Another project may require a lisp interpreter, access to the INGRES database system, or a collection of typical electrical circuit schematics. All resources required should be listed whether or not they are supplied by the XCF (e.g. you have a large database elsewhere that could not fit on the XCF machines); this indicates to our sponsors how effectively our resources meet the goals of the XCF.

Applicant's Qualifications and University Affiliation

The XCF can only provide resources for registered students (grad or undergrad) or UC staff. Please indicate which (and year). List CS course-work or other course-work that may be relevant to the project (please do _not_ include grades). List work experience, if any, and finally list any projects that you have worked on or completed (even class projects if you like). Note also that your ability to come up with a good project proposal reflects on your general organizational skills.

Relevance

This describes your view of how this project can be useful to the campus computing community (or the computing community in general) or other reasons you think this project has merit. This is a good place to address possible weaknesses in the project goals. The following information will be added to the project proposal then it is approved (then it becomes the "project description"): Sponsors Name There will be a single XCF member assigned as a sponsor. They are responsible for helping you out with programming problems, pointing you to other people who might help you, creating your account, introducing you to new members, etc. In the past this has not actually made much of a difference, as questions are usually answered by whom ever is available. Applicants Name (Obvious). Date Started And/or date approved.

Approval of a project proposal

The approval of an XCF project is made by general consensus of the membership and based on the following two criteria: Utility or creativity: The XCF wants to see projects that will be useful to the campus community (or the general programming community) once they are complete. This is a stated goal of the XCF. If there is no obvious utility, a notably interesting or creative project idea may gain support. Note that games present a problem in that they have very little real utility, reflect poorly on the XCF to our sponsors, and tend to have a negative affect on the working environment within the XCF. Probability of success: It is not worth anyone's time or effort to start a project that will not be finished. The general membership will examine the complexity and size of a project and compare it with your qualifications and their own experience. If the project seems particularly ambitious, you may be asked to trim it down, leaving portions as "possible extensions". On the other hand, a particularly simple project given your qualification may not be appropriate either, and you would be asked to add to the proposal.

Miscellaneous comments

Some projects have built-in negatives; in particular, game projects and new programming language projects. Game playing in the XCF is usually banned during the semester for several reasons; it is obviously inconsistent to have a game project while game playing is banned. [The following paragraph is the personal opinion of one XCF member and may or may not reflect the opinions of other XCF members.] As for new programming languages, everyone seems to have their own idea of what should or should not be in a programming language. Unfortunately, most have not really researched the topic very well. It turns out to be very difficult to do something innovative in this area, especially considering the time you are expected to spend on the project. As for the utility of a new programming language, so many programming languages exist that it is unlikely that a new language will be accepted. Implementations of existing programming languages (which are not commonly available) are a different matter. If you do present a language proposal (either new or old), it would help considerably to have taken CS 164 (programming languages and compilers). The time to approve a proposal can vary widely; the most time is spent collecting feedback from current members and getting the proposal revised. It helps to try to minimize the number of times a proposal is revised (that is why this note was written). During finals is the worst time to submit a proposal; during breaks many people will be on vacation. The best time to submit a proposal is at the beginning of a semester, ideally a week or two before the semester starts. Doing a project with the XCF implies that it can be used by the campus computing community. Beyond that, we do not care if you take your project afterwards to improve and sell for profit (University rules not withstanding). Finally, once a proposal has been accepted, you are expected to help maintain a good working environment in the XCF.