Rubrics structure and known limitations

If unfamiliar with Classroom Rubrics, see these Help Center articles to learn about the general structure of a rubric and how rubric grading is done in the Classroom UI.

Rubrics structure

There are some important concepts that may be worth highlighting when using the API to interact with rubrics:

  • There is (at most) a single rubric associated with a CourseWork and that rubric is unique to that CourseWork (it is not shareable across CourseWork resources).
  • The rubric consists of criteria, which consist of levels. A rubric must always have at least one criteria, and a criterion must always have at least one level.
  • Levels can be scored (have points) or unscored (no points). Levels must be entirely scored or entirely unscored in a rubric.
    • If the levels are scored, all levels in a criterion must have a unique points value set. Points can be integers (like 10) or floating point values (like 9.99). This can include 0. Null values are not accepted. Additionally, a rubric can't have a single criteria with a single level that is 0 points.
    • If the levels are unscored, the points field should be omitted; null values are not accepted.
  • The order for criteria and levels is meaningful and reflects the order they are represented in the Classroom UI.
    • Scored levels in particular must always be sorted by points in either increasing or decreasing order.
  • There can be up to 50 criteria per rubric and up to 10 performance levels per criterion.

Student submission objects are also changing:

  • In addition to the existing draftGrade and assignedGrade properties, a student submission graded with a rubric has draftRubricGrades and assignedRubricGrades properties. These represent the rubric grades (levels selected and point values) the student receives during grading from the rubric, in the draft and assigned states, respectively.
  • For now, these properties are read-only. This means that the API can't be used to grade submissions, but you can read submissions graded in the Classroom UI.
  • Student submissions with an associated rubric contain a rubricId field. This field represents the latest rubric associated with the CourseWork, and this value might change if teachers delete and recreate a rubric.

Rubrics behaviors

The API aims to mirror the Classroom UI whenever possible for consistency, but this can lead to behaviour that may be unintuitive for developers and is worth mentioning:

  • Rubrics are intended to guide grading without constraining teachers. As a result, a teacher can do the following when grading a submission with a rubric:
    • Completely ignore the rubric when grading.
    • Override the points for a criterion, irrespective of the points available in the criterion's levels.
    • Select levels for only a subset of criteria.
    • Assign points for a criteria without selecting a corresponding level.
    • Override the assignment's total points, irrespective of the points that would come from the rubric.

Additionally, the API isn't introducing any new product capabilities. In other words, the API doesn't support behavior the Classroom UI doesn't already have. For example, the API doesn't enable enforcing rubrics usage on assignments or overriding a teacher's ability to edit rubrics and submissions as they can today.

Limitations during grading

Similarly, there are some additional limitations place on editing rubrics once a teacher has started grading with it. Only the following edits are possible after grading as started:

  • Text edits are allowed for criterion and level titles and descriptions.
  • Level ordering can change within criteria.

Additional scopes

Rubrics can be manually exported to Google Spreadsheets for re-use by teachers.

If you create or update a rubric from these spreadsheets (see an example in the guide), your application needs to request the or scope. Be aware that the spreadsheets scopes are considered sensitive and may require your application to be verified.