Skip to content

Instantly share code, notes, and snippets.

@stevekinney

stevekinney/rubric.md

Created January 11, 2016 21:56
Show Gist options
  • Save stevekinney/63c74dcc43e86e2f4f39 to your computer and use it in GitHub Desktop.
Save stevekinney/63c74dcc43e86e2f4f39 to your computer and use it in GitHub Desktop.
Download ZIP
Raw
rubric.md

Detailed Rubric

Subjective evaluation will be made on your work/process according to the following criteria:

1. Satisfactory Progress

  • 4: Developer completes iterations 1 through 6 as well as an additional supporting feature
  • 3: Developer completes iterations 1 through 6 (this includes one supporting feature) with few bugs and no missing functionality.
  • 2: Developer completes iterations 1 through 5 with some bugs or missing functionality.
  • 1: Developer fails to complete iterations 1 through 4, or there are significant issues with delivered functionality.

2. Ruby Syntax & Style

  • 4: Developer is able to write Ruby demonstrating a broad/deep understanding of available language features. Application demonstrates great understanding of Object-Oriented modeling. Developer can speak to choices made in the code and knows what every line of code is doing.
  • 3: Developer is able to write idiomatic and effective Ruby. Application makes good use of Object-Oriented modeling with few gaps in class identification and component extraction. Developer can speak to choices made in the code and knows what every line of code is doing.
  • 2: Developer is able to accomplish tasks with Ruby code, but lacks attention to broader design and organizational concepts. Developer is not confident in what every line of the code is doing or cannot speak to the choices made.
  • 1: Developer is generally able to write Ruby, but code is sloppy, disorganized, or poorly factored.

3. Rails Style & API

  • 4: Developer is able to craft Rails features that follow the principles of MVC, push business logic down the stack, and skillfully utilizes ActiveRecord to model application state. Developer can speak to choices made in the code and knows what every line of code is doing.
  • 3: Developer generally writes clean Rails features that make smart use of Ruby, with some struggles in pushing logic down the stack. The application displays good judgement in modeling the problem as data. Developer can speak to choices made in the code and knows what every line of code is doing.
  • 2: Developer struggles with some concepts of MVC. Developer is not confident in what every line of the code is doing or cannot speak to the choices made.
  • 1: Developer struggles with MVC and pushing logic down the stack
  • 0: Developer shows little or no understanding of how to craft Rails applications

4. Javascript Syntax & Style

  • 4: Developer uses elegant and idiomatic Javascript to accomplish common tasks. Demonstrates solid understanding of function passing and manipulation. Developer can speak to choices made in the code and knows what every line of code is doing.
  • 3: Developer writes solid Javascript code using common patterns and idioms. Code is organized appropriately within objects and functions. Developer can speak to choices made in the code and knows what every line of code is doing.
  • 2: Developer can accomplish basic tasks with Javascript but implementation is largely copy/pasted or non-idiomatic. Developer is not confident in what every line of the code is doing or cannot speak to the choices made.
  • 1: Developer can manipulate Javascript syntax but implementation is buggy or inconsistent.
  • 0: Developer shows little or no understanding of Javascript syntax and idioms

5. Testing

  • 4: Developer excels at taking small steps and using the tests for both design and verification. Developer uses integration tests, controller tests, and model tests where appropriate.
  • 3: Developer writes tests that are effective validation of functionality, but don't drive the design. Developer uses integration tests, controller tests, and model tests where appropriate.
  • 2: Developer uses tests to guide development, but implements more functionality than the tests cover. Application is missing tests in a needed area such as model, integration, or controller tests.
  • 1: Developer is able to write tests, but they're written after or in the middle of implementation.
  • 0: Developer does not use tests to guide development.

6. User Interface

  • 4: The application is pleasant, logical, and easy to use
  • 3: The application has many strong pages/interactions, but a few holes in lesser-used functionality
  • 2: The application shows effort in the interface, but the result is not effective
  • 1: The application is confusing or difficult to use

7. Delivery Deadlines

  • 4: The project was completed by 5pm of the day it was assigned.
  • 3: The project was completed by 9pm of the day it was assigned.
  • 2: The project was completed by 9am the next morning.
  • 1: The project was not completed.

8. Workflow

  • 4: The developer effectively uses Git branches and many small, atomic commits that document the evolution of their application.
  • 3: The developer makes a series of small, atomic commits that document the evolution of their application. There are no formatting issues in the code base.
  • 2: The developer makes large commits covering multiple features that make it difficult for the evaluator to determine the evolution of the application.
  • 1: The developer commited the code to version control in only a few commits. The evaluator cannot determine the evolution of the application.
  • 0: The application was not checked into version control.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment