Return-Path: lccheung@usc.edu Delivery-Date: Thu Sep 11 16:08:04 2008 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on merlot.usc.edu X-Spam-Level: X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_40,HTML_MESSAGE, LOCALPART_IN_SUBJECT autolearn=no version=3.2.3 Received: from msg-scanner1.usc.edu (msg-scanner1.usc.edu [128.125.137.210]) by merlot.usc.edu (8.14.1/8.14.1) with ESMTP id m8BN84su010877 for ; Thu, 11 Sep 2008 16:08:04 -0700 Received: from msg-mx10.usc.edu ([128.125.137.28]) by msg-scanner1.usc.edu (Sun Java System Messaging Server 6.2-7.05 (built Sep 5 2006)) with ESMTP id <0K7200EYS0EBF6O0@msg-scanner1.usc.edu> for cs551@merlot.usc.edu; Thu, 11 Sep 2008 16:11:54 -0700 (PDT) Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.169]) by msg-mx10.usc.edu (Postfix) with ESMTP id 7177E2B96 for ; Thu, 11 Sep 2008 16:11:55 -0700 (PDT) Received: by wf-out-1314.google.com with SMTP id 28so516934wfa.27 for ; Thu, 11 Sep 2008 16:11:55 -0700 (PDT) Received: by 10.142.201.3 with SMTP id y3mr1176718wff.279.1221174715293; Thu, 11 Sep 2008 16:11:55 -0700 (PDT) Received: by 10.142.158.11 with HTTP; Thu, 11 Sep 2008 16:11:55 -0700 (PDT) Date: Thu, 11 Sep 2008 16:11:55 -0700 From: Leslie Cheung Subject: cs551: readme and grading guidelines To: cs551@merlot.usc.edu Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_Part_57225_19062825.1221174715286" ------=_Part_57225_19062825.1221174715286 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi class, During my office hour, a few of you have asked what you should write in readme. It's under the "README requirement" section in the project spec. For example, some of you told me the client is slow when it processes certain kind of requests. It's a good idea to document this in README, so the grader knows what to expect. However, by documenting this in README, you may still lose points. It's always a good idea to write the best code you can write, but if you are out of time, document any defect in README. Another question I often get is if it's "ok" to get this output when I run a certain test case in the grading guildeines. I think we have given you enough information for you to determine if your output is ok. If you are not convinced that you have done your best, fix your code to do the best you can do. We cannot tell you what the "answer" is supposed to be, nor how much partial credit you'd get if you can get it "partly right". --Leslie ------=_Part_57225_19062825.1221174715286 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline
Hi class,
 
During my office hour, a few of you have asked what you should write in readme. It's under the "README requirement" section in the project spec. For example, some of you told me the client is slow when it processes certain kind of requests. It's a good idea to document this in README, so the grader knows what to expect. However, by documenting this in README, you may still lose points. It's always a good idea to write the best code you can write, but if you are out of time, document any defect in README.
 
Another question I often get is if it's "ok" to get this output when I run a certain test case in the  grading guildeines. I think we have given you enough information for you to determine if your output is ok. If you are not convinced that you have done your best, fix your code to do the best you can do. We cannot tell you what the "answer" is supposed to be, nor how much partial credit you'd get if you can get it "partly right".
 
 
--Leslie
------=_Part_57225_19062825.1221174715286--