Since part of the goal of these projects is to teach you how to write papers, here are some pointers. Some of the problems with the writeups stem from the fact that this is both a project writeup and a (simulated) paper submission. These are fundamentally different beasts, and you had to make some hard choices.

Be kind to your reader

Remember, your goal in writing a paper is to make people want to read it, the two ways to do this are (1) do interesting research and (2) make the reader's life as easy as possible. Very often, someone is doing a lit. search and needs to decide quickly if the paper is pertinent to their needs. It's common to read an abstract and then decide if the paper is worth reading, so put enough information in the abstract for someone to make that judgement, while keeping it short. It's also common to read the introduction, and then the conclusion to confirm that topic of the paper is what the reader wants to learn about. So the introduction should tell enough to understand the basic idea of the paper, and the conclusion should summarize the major contributions. Next the reader may skim through the figures (particularly the evaluation) to determine if the results are strong enough to be worthwhile, so the figures should stand on their own. Captions should entirely explain how to read the figure. (While analysis of what the figure "means" goes in the paper.) Finally, the paper is read in full. Pay close attention to organization and level of detail to make the paper easy to read.

Organization

Think carefully about how to organize your paper. It should flow so that each section leads naturally to the next. Your reader should not need to go back and forth looking for information that is used together but presented separately. Even more importantly, you should avoid forward references, that is, references to terms or concepts which have not yet been introduced. To help with the flow of your paper, think about the storyline. E.g. Present a problem, present an existing solution, show that the solution is lacking in some way, give some intution about why the solution is lacking, perhaps support the intution with experimental results, use the intuition to derive a proposed improvement, show the proposed improvement really is an improvement." Typically, you'll break out your sections as follows:
Abstract
Should say what problem you're solving, and, in broad terms, what your solution is.
Introduction
Should state the problem, briefly describe current approaches (if appropriate), describe problems with these approaches that are addressed by the research (if appropriate) and briefly describe the proposed solution. It should also contain a roadmap to the rest of the paper.
Following section(s)
Should further describe the problem and current approaches in just enough detail to make the proposed solution understandable, and then present the research.
Evaluation
Show that the solution works, or investigate why it doesn't. You need to describe your methodology, unless you're using something really standard (and you still need to say what you're doing.)
Related work section
Should describe other similar methods, and how each differs with the proposed solution.
Discussion/conclusion
Should recap, summarize the contributions of the paper and possibly propose further extensions.

Figure and Table Captions

Tables and figures should have explanatory captions. The reader should be able to look at the figure and its caption and know exactly how to read it. This also means all axes on graphs should be labeled, including units. If something isn't obvious (e.g. "c/v ratio"), explain it in the caption (e.g. "The x axis is the ratio of clauses to variables in the formula.") Of course, the analysis of the figure or table belongs in the paper.

Concise, complete explanations

Take a few moments to step back and read your paper with the eyes of an outside reader. Make sure you're not using concepts or terminology which aren't explained. Make sure you aren't needlessly describing things in more detail than is needed. For example, when describing an algorithm you're extending, present the psuedo-code and describe how it works briefly, then cite the original work so the reader can find out more if they want to.

References

You should have complete and correct references and consistent citations. Citations should appear:

What to include/exclude

This is one of the areas where paper submissions differ most from project writeups. First of all, in a paper submission, you don't always write about everything you did.

One of the big mistakes many groups did was to spend a lot of time talking about the work they did to reproduce previous results (e.g. finding a critical value near 4.3 - "here are several pages of graphs showing our findings about the critical value") and not much time talking about what they did that was different or involved making choices ("we came up with a novel way of tuning the algorithm which resulted in a p value of .6, here's a two line table to show that that value works well.") The reasoning behind design decisions should be explained (either by reference to another paper, by experimentation or argumentation).

This is where it's important to keep your target audience in mind. Don't be overly verbose about things they can be expected to know, and do explain things they might not know.

Proper support

Back up your statements. Any time you make a claim, be prepared to back it up. You can do this either with data, with a citation to previous research, or by arguing from first principles. The last strategy is fine, if the arguement holds, but remember, an intuition isn't an argument.

Informal language

Many of the papers had language which is fine for a project report but just doesn't work in a paper submission. The only way to really get a feel for what type of language is expected is to read, read, read. Also, plan to do revisions and rewrites. A good paper doesn't happen on the first try.