From 49563eae18424f07b8f9f84436524ca4c76199bd Mon Sep 17 00:00:00 2001 From: David Ormsbee Date: Tue, 26 Feb 2013 11:59:51 -0500 Subject: [PATCH] Delete course_grading.md and xml-format.md (moved to doc/public) --- doc/course_grading.md | 165 --------------- doc/xml-format.md | 482 ------------------------------------------ 2 files changed, 647 deletions(-) delete mode 100644 doc/course_grading.md delete mode 100644 doc/xml-format.md diff --git a/doc/course_grading.md b/doc/course_grading.md deleted file mode 100644 index 5c668df5d9..0000000000 --- a/doc/course_grading.md +++ /dev/null @@ -1,165 +0,0 @@ -# Course Grading - -This document is written to help professors understand how a final grade for a -course is computed. - -Course grading is the process of taking all of the problems scores for a student -in a course and generating a final score (and corresponding letter grade). This -grading process can be split into two phases - totaling sections and section -weighting. - -## Totaling sections - -The process of totaling sections is to get a percentage score (between 0.0 and -1.0) for every section in the course. A section is any module that is a direct -child of a chapter. For example, psets, labs, and sequences are all common -sections. Only the *percentage* on the section will be available to compute the -final grade, *not* the final number of points earned / possible. - - -**For a section to be included in the final grade, the policies file must set -graded = True for the section.** - -For each section, the grading function retrieves all problems within the -section. The section percentage is computed as (total points earned) / (total -points possible). - - -### Weighting Problems -In some cases, one might want to give weights to problems within a section. For -example, a final exam might contain 4 questions each worth 1 point by default. -This means each question would by default have the same weight. If one wanted -the first problem to be worth 50% of the final exam, the policy file could specify -weights of 30, 10, 10, and 10 to the 4 problems, respectively. - -Note that the default weight of a problem **is not 1.** The default weight of a -problem is the module's max_grade. - -If weighting is set, each problem is worth the number of points assigned, regardless of the number of responses it contains. - -Consider a Homework section that contains two problems. - - - ... - - -and - - - ... - ... - ... - - - - - - -Without weighting, Problem 1 is worth 25% of the assignment, and Problem 2 is worth 75% of the assignment. - -Weighting for the problems can be set in the policy.json file. - - "problem/problem1": { - "weight": 2 - }, - "problem/problem2": { - "weight": 2 - }, - -With the above weighting, Problems 1 and 2 are each worth 50% of the assignment. - -Please note: When problems have weight, the point value is automatically included in the display name *except* when “weight”: 1.When “weight”: 1, no visual change occurs in the display name, leaving the point value open to interpretation to the student. - - - -## Section Weighting - -Once each section has a percentage score, we must total those sections into a -final grade. Of course, not every section has equal weight in the final grade. -The policies for weighting sections into a final grade are specified in the -grading_policy.json file. - -The grading_policy.json file specifies several sub-graders that are each given -a weight and factored into the final grade. There are currently two types of -sub-graders, section format graders and single section graders. - -We will use this simple example of a grader with one section format grader and -one single section grader. - - - "GRADER" : [ - { - "type" : "Homework", - "min_count" : 12, - "drop_count" : 2, - "short_label" : "HW", - "weight" : 0.4 - }, - { - "type" : "Final", - "name" : "Final Exam", - "short_label" : "Final", - "weight" : 0.6 - } - ] - -### Section Format Graders - -A section format grader grades a set of sections with the same format, as -defined in the course policy file. To make a vertical named Homework1 be graded -by the Homework section format grader, the following definition would be in the -course policy file. - - - "vertical/Homework1": { - "display_name": "Homework 1", - "graded": true, - "format": "Homework" - }, - - -In the example above, the section format grader declares that it will expect to -find at least 12 sections with the format "Homework". It will drop the lowest 2. -All of the homework assignments will have equal weight, relative to each other -(except, of course, for the assignments that are dropped). - -This format supports forecasting the number of homework assignments. For -example, if the course only has 3 homeworks written, but the section format -grader has been told to expect 12, the missing 9 will have an assumed 0% and -will still show up in the grade breakdown. - -A section format grader will also show the average of that section in the grade -breakdown (shown on the Progress page, gradebook, etc.). - - -### Single Section Graders - -A single section grader grades exactly that - a single section. If a section -is found with a matching format and display name then the score of that section -is used. If not, a score of 0% is assumed. - - -### Combining sub-graders - -The final grade is computed by taking the score and weight of each sub grader. -In the above example, homework will be 40% of the final grade. The final exam -will be 60% of the final grade. - -## Displaying the final grade - -The final grade is then rounded up to the nearest percentage point. This is so -the system can consistently display a percentage without worrying whether the -displayed percentage has been rounded up or down (potentially misleading the -student). The formula for the rounding is - - rounded_percent = round(computed_percent * 100 + 0.05) / 100 - -The grading policy file also specifies the cutoffs for the grade levels. A -grade is either A, B, or C. If the student does not reach the cutoff threshold -for a C grade then the student has not earned a grade and will not be eligible -for a certificate. Letter grades are only awarded to students who have -completed the course. There is no notion of a failing letter grade. - - - - diff --git a/doc/xml-format.md b/doc/xml-format.md deleted file mode 100644 index f387de1f52..0000000000 --- a/doc/xml-format.md +++ /dev/null @@ -1,482 +0,0 @@ -# edX xml format tutorial - -## Goals of this document - -* This was written assuming the reader has no prior programming/CS knowledge and has jumped cold turkey into the edX platform. -* To educate the reader on how to build and maintain the back end structure of the course content. This is important for debugging and standardization. -* After reading this, you should be able to add content to a course and make sure it shows up in the courseware and does not break the code. -* __Prerequisites:__ it would be helpful to know a little bit about xml. Here is a [simple example](http://www.ultraslavonic.info/intro-to-xml/) if you've never seen it before. - -## Outline - -* First, we will show a sample course structure as a case study/model of how xml and files in a course are organized to introductory understanding. - -* More technical details are below, including discussion of some special cases. - - -## Introduction - -* The course is organized hierarchically. We start by describing course-wide parameters, then break the course into chapters, and then go deeper and deeper until we reach a specific pset, video, etc. - -* You could make an analogy to finding a green shirt in your house - front door -> bedroom -> closet -> drawer -> shirts -> green shirt - - -## Case Study - -Let's jump right in by looking at the directory structure of a very simple toy course: - - toy/ - course - course.xml - problem - policies - roots - -The only top level file is `course.xml`, which should contain one line, looking something like this: - - - -This gives all the information to uniquely identify a particular run of any course--which organization is producing the course, what the course name is, and what "run" this is, specified via the `url_name` attribute. - -Obviously, this doesn't actually specify any of the course content, so we need to find that next. To know where to look, you need to know the standard organizational structure of our system: _course elements are uniquely identified by the combination `(category, url_name)`_. In this case, we are looking for a `course` element with the `url_name` "2012_Fall". The definition of this element will be in `course/2012_Fall.xml`. Let's look there next: - -`course/2012_Fall.xml` - - - - - - - - - -Aha. Now we found some content. We can see that the course is organized hierarchically, in this case with only one chapter, with `url_name` "Overview". The chapter contains a `videosequence` and a `video`, with the sequence containing a problem and another video. When viewed in the courseware, chapters are shown at the top level of the navigation accordion on the left, with any elements directly included in the chapter below. - -Looking at this file, we can see the course structure, and the youtube urls for the videos, but what about the "warmup" problem? There is no problem content here! Where should we look? This is a good time to pause and try to answer that question based on our organizational structure above. - -As you hopefully guessed, the problem would be in `problem/warmup.xml`. (Note: This tutorial doesn't discuss the xml format for problems--there are chapters of edx4edx that describe it.) This is an instance of a _pointer tag:_ any xml tag with only the category and a url_name attribute will point to the file `{category}/{url_name}.xml`. For example, this means that our toy `course.xml` could have also been written as - -`course/2012_Fall.xml` - - - - - -with `chapter/Overview.xml` containing - - - - - - - -In fact, this is the recommended structure for real courses--putting each chapter into its own file makes it easy to have different people work on each without conflicting or having to merge. Similarly, as sequences get large, it can be handy to split them out as well (in `sequence/{url_name}.xml`, of course). - -Note that the `url_name` is only specified once per element--either the inline definition, or in the pointer tag. - -## Policy files - -We still haven't looked at two of the directoies in the top-level listing above: `policies` and `roots`. Let's look at policies next. The policy directory contains one file: - - policies: - 2012_Fall.json - -and that file is named {course-url_name}.json. As you might expect, this file contains a policy for the course. In our example, it looks like this: - - 2012_Fall.json: - { - "course/2012_Fall": { - "graceperiod": "2 days 5 hours 59 minutes 59 seconds", - "start": "2015-07-17T12:00", - "display_name": "Toy Course" - }, - "chapter/Overview": { - "display_name": "Overview" - }, - "videosequence/Toy_Videos": { - "display_name": "Toy Videos", - "format": "Lecture Sequence" - }, - "problem/warmup": { - "display_name": "Getting ready for the semester" - }, - "video/Video_Resources": { - "display_name": "Video Resources" - }, - "video/Welcome": { - "display_name": "Welcome" - } - } - -The policy specifies metadata about the content elements--things which are not inherent to the definition of the content, but which describe how the content is presented to the user and used in the course. See below for a full list of metadata attributes; as the example shows, they include `display_name`, which is what is shown when this piece of content is referenced or shown in the courseware, and various dates and times, like `start`, which specifies when the content becomes visible to students, and various problem-specific parameters like the allowed number of attempts. One important point is that some metadata is inherited: for example, specifying the start date on the course makes it the default for every element in the course. See below for more details. - -It is possible to put metadata directly in the xml, as attributes of the appropriate tag, but using a policy file has two benefits: it puts all the policy in one place, making it easier to check that things like due dates are set properly, and it allows the content definitions to be easily used in another run of the same course, with the same or similar content, but different policy. - -## Roots - -The last directory in the top level listing is `roots`. In our toy course, it contains a single file: - - roots/ - 2012_Fall.xml - -This file is identical to the top-level `course.xml`, containing - - - -In fact, the top level `course.xml` is a symbolic link to this file. When there is only one run of a course, the roots directory is not really necessary, and the top-level course.xml file can just specify the `url_name` of the course. However, if we wanted to make a second run of our toy course, we could add another file called, e.g., `roots/2013_Spring.xml`, containing - - - -After creating `course/2013_Spring.xml` with the course structure (possibly as a symbolic link or copy of `course/2012_Fall.xml` if no content was changing), and `policies/2013_Spring.json`, we would have two different runs of the toy course in the course repository. Our build system understands this roots structure, and will build a course package for each root. (Dev note: if you're using a local development environment, make the top level `course.xml` point to the desired root, and check out the repo multiple times if you need multiple runs simultaneously). - -That's basically all there is to the organizational structure. Read the next section for details on the tags we support, including some special case tags like `customtag` and `html` invariants, and look at the end for some tips that will make the editing process easier. - ----------- - -# Tag types - -* `abtest` -- Support for A/B testing. TODO: add details.. -* `chapter` -- top level organization unit of a course. The courseware display code currently expects the top level `course` element to contain only chapters, though there is no philosophical reason why this is required, so we may change it to properly display non-chapters at the top level. -* `conditional` -- conditional element, which shows one or more modules only if certain conditions are satisfied. -* `course` -- top level tag. Contains everything else. -* `customtag` -- render an html template, filling in some parameters, and return the resulting html. See below for details. -* `discussion` -- Inline discussion forum -* `html` -- a reference to an html file. -* `error` -- don't put these in by hand :) The internal representation of content that has an error, such as malformed xml or some broken invariant. You may see this in the xml once the CMS is in use... -* `problem` -- a problem. See elsewhere in edx4edx for documentation on the format. -* `problemset` -- logically, a series of related problems. Currently displayed vertically. May contain explanatory html, videos, etc. -* `sequential` -- a sequence of content, currently displayed with a horizontal list of tabs. If possible, use a more semantically meaningful tag (currently, we only have `videosequence`). -* `vertical` -- a sequence of content, displayed vertically. Content will be accessed all at once, on the right part of the page. No navigational bar. May have to use browser scroll bars. Content split with separators. If possible, use a more semantically meaningful tag (currently, we only have `problemset`). -* `video` -- a link to a video, currently expected to be hosted on youtube. -* `videosequence` -- a sequence of videos. This can contain various non-video content; it just signals to the system that this is logically part of an explanatory sequence of content, as opposed to say an exam sequence. - -## Tag details - -### Container tags - -Container tags include `chapter`, `sequential`, `videosequence`, `vertical`, and `problemset`. They are all specified in the same way in the xml, as shown in the tutorial above. - -### `course` - -`course` is also a container, and is similar, with one extra wrinkle: the top level pointer tag _must_ have `org` and `course` attributes specified--the organization name, and course name. Note that `course` is referring to the platonic ideal of this course (e.g. "6.002x"), not to any particular run of this course. The `url_name` should be the particular run of this course. - -### `conditional` - -`conditional` is as special kind of container tag as well. Here are two examples: - - - - - - - - -The condition can be either `require_completed`, in which case the required modules must be completed, or `require_attempted`, in which case the required modules must have been attempted. - -The required modules are specified as a set of `tag`/`url_name`, joined by an ampersand. - -### `customtag` - -When we see ``, we will: - -* look for a file called `custom_tags/special` in your course dir. -* render it as a mako template, passing parameters {'animal':'unicorn', 'hat':'blue'}, generating html. (Google `mako` for template syntax, or look at existing examples). - -Since `customtag` is already a pointer, there is generally no need to put it into a separate file--just use it in place: - -### `discussion` - -The discussion tag embeds an inline discussion module. The XML format is: -``` - -``` -The meaning of each attribute is as follows: -* `for`: A string that describes the discussion. Purely for descriptive purposes (to the student). -* `id`: The identifier that the discussion forum service uses to refer to this inline discussion module. Since the `id` must be unique and lives in a common namespace with all other courses, the preferred convention is to use `__` as in the above example. The `id` should be "machine-friendly", e.g. use alphanumeric characters, underscores. Do **not** use a period (e.g. `6.002x_Fall_2012_Overview`). -* `discussion_category`: The inline module will be indexed in the main "Discussion" tab of the course. The inline discussions are organized into a directory-like hierarchy. Note that the forward slash indicates depth, as in conventional filesytems. In the above example, this discussion module will show up in the following "directory": -``` -Week 1 / Overview / Course overview -``` - -Further discussion on `discussion_category`: -Note that the `for` tag has been appended to the end of the `discussion_category`. This can often lead into deeply nested subforums, which may not be intended. In the above example, if we were to use instead: - -``` - -``` - -this discussion module would show up in the main forums as: -``` -Week 1 / Course overview -``` - -which is more succinct. - -### `html` - -Most of our content is in xml, but some html content may not be proper xml (all tags matched, single top-level tag, etc), since browsers are fairly lenient in what they'll display. So, there are two ways to include html content: - -* If your html content is in a proper xml format, just put it in `html/{url_name}.xml`. -* If your html content is not in proper xml format, you can put it in `html/{filename}.html`, and put `` in `html/{filename}.xml`. This allows another level of indirection, and makes sure that we can read the xml file and then just return the actual html content without trying to parse it. - -### `video` - -Videos have an attribute youtube, which specifies a series of speeds + youtube videos id: - -