I found xxx on the net. Can I use it in my project?
I found xxx which is basically the whole project. Can I use it and turn that in?
Project 1 was a disaster. Do I still have a chance to pass this class?
Everyone on my team is working really hard except xxx, who is letting us down. What can we do?
Can you provide some good examples of user manuals to imitate?
I not only allow but encourage you to reuse software and other things you find on the net, provided you use them legally and ethically.
Using them legally means that you must comply with whatever licensing conditions are attached to them. In practice, this means that you can almost always use open source software components (provided of course that your own project is open source), and you can almost never use any commercial components.
If you don't find the licensing conditions, that does not mean that the software is fair game. On the contrary, you must assume that the software's author retains all rights (and grants you none) unless you find an explicit notice otherwise. That's not just my rule, that's the law.
Remember that images, sound clips, etc. are all protected by the same copyright law. If it doesn't say you can use it, you can't. Fortunately, there is an awful lot out there with explicit open-source licenses that grant you permission to use them as long as you abide by open source principles. Sourceforge (http://sourceforge.net) is a great place to look.
Using open source materials ethically includes, in addition to abiding by the license conditions, giving fair credit to the authors of what you use. I insist that you document clearly and prominently the source of all materials, even if you modify them substantially. In addition to documenting sources in the materials themselves, I require you to list all external sources of materials in the manifest of materials you turn in with your project.
Important: Failing to properly and adequately credit a source is plagiarism, and I will treat it in accordance with University of Oregon policies on academic dishonesty. Penalties may include flunking the course (yes, really), and a permanent record of your transgression in the Office of Student Judicial Affairs.
Got that? So be careful, be honest, but don't be afraid to build on the work of others.
[top]
Occasionally students find an existing open source project which is essentially a complete solution to the project. I will allow you to use and turn in such a project if (and only if) you contribute some substantial enhancement to it. In other words, you can't just turn it in without improvements, but you may very well improve an existing project rather than building a new one from scratch. It is best to talk to me about this before making a decision; we can negotiate what a "substantial enhancement" would mean for this particular project.
[top]
These are graded as team projects, and you are graded by the performance of the team as a whole. Your job is not to make your part great. Your job is to make the whole project great, by doing whatever you need to do --- not only in your own part, but in coordinating with your team, motivating your team, stepping in to help a teammate, whatever.
[top]
Yes, you still have a chance if you do well on project 2. You can probably still earn a good grade, although you'll need to do particularly well on the second project. If I see a marked improvement from project 1 to project 2, I sometimes weight project 2 more heavily on an individual basis rather than using a straight weighted average.
Note: It's much harder to do well if project 2 is a disaster, because even if project 1 was successful, a success followed by a failure doesn't look much like progress.
[top]
About all you can do is reorganize the work, reallocating parts of xxx's work to other members of your team. Before you do that, you should have a team meeting (including xxx, if at all possible) in which you discuss the problem. (I am willing to participate in the meeting to try to mediate.)
It is always important to design and plan a project as a series of incremental builds, with a few core features built first and more added later. This becomes particularly important when you need to reorganize the work in this way. You need to think very carefully about what you can trim from the original project plan, in order to reallocate some of your effort to tasks that were originally assigned to xxx.
[top]
For a small project, with one documentation page serving as tutorial and reference manual for installation as well as use, I think the Gretel documentation (written by Carl Howells) is quite nice.
For a much larger, more professional documentation effort, with a tutorial separate from a reference manual, the Adobe PostScript manuals are exceptional. Older versions of Adobe products like Illustrator and Photoshop came with separate tutorials and reference manuals, but in version 10 of Illustrator they are combined in a single user guide (which seems to be more like a tutorial in the first few chapters, and more like a reference in later chapters).
Two anti-examples: Online help for Microsoft products like Word and Excel is terrible (badly organized, incomplete, often incomprehensible). Apple has outdone Microsoft with even worse online help in Mac OS X, and they've managed to make it not only incomplete and poorly organized but also incredibly slow. A much better example of online documentation (albeit offputtingly idiosyncratic) is the online manual packaged with Gnu Emacs and Xemacs.
[top]