whats-cooking-rubric.md

Rubric

Group: name and name

Functional Expectations

• 4: Application fulfills all expectations of user stories, and has functionality that goes above and beyond an MVP.
• 3: Application demonstrates a fully functional MVP, and group members can articulate choices for prioritizing certain pieces of functionality.
• 2: Application is usable, but has some missing functionality and no clear MVP.
• 1: Application crashes during normal usage.

Fundamental JavaScript & Style

• 4: Application demonstrates excellent knowledge of JavaScript syntax, style, and refactoring.
• 3: Class methods use array and object prototypes - for loops are not used in the application. Application shows strong effort towards organization, content, and refactoring.
• 2: Class methods use a mix of array and object prototypes and for loops. Application runs but the code has long methods, unnecessary or poorly named variables, and needs significant refactoring.
• 1: Application generates syntax error or crashes during execution.

Test-Driven Development

• 4: Application is broken into components which are well tested in both isolation and integration using appropriate data. Test feature many sad paths for methods as well.
• 3: All classes and methods are tested. Application is well tested but does not balance isolation and integration tests, using only the data necessary to test the functionality. Tests use smaller, sample data files as input rather than the large, original data files.
• 2: Application makes some use of tests, but the coverage is insufficient given project requirements.
• 1: Application does not demonstrate strong use of TDD.

Encapsulation / Breaking Logic into Components

• 4: Application is expertly divided into logical components each with a clear, single responsibility.
• 3: Application effectively breaks logical components apart, but breaks the principle of SRP.
• 2: Application shows some effort to break logic into components, but the divisions are inconsistent or unclear.
• 1: Application logic shows poor decomposition with too much logic mashed together.

User Interface

• 4: The application is pleasant, logical, and easy to understand. There are no holes in functionality and the application stands on its own to be used by the instructor without guidance from the developer.
• 3: The application has many strong displays/interactions, but a few holes in lesser-used displays.
• 2: The application shows effort in the interface, but the result is not effective. The evaluator has some difficulty using the application when reviewing the features in the users' needs.
• 1: The application is confusing or difficult to use.

Workflow

• 4: The team effectively uses Git branches and pull requests for meaningful code review. The evolution of the project is evident through conversation done via code reviews and pull requests.
• 3: The team makes a series of small, atomic commits that document the evolution of their application. The team conducts a DTR (define the relationship) and utilizes GitHub issues and best pairing practices. Team members utilize a kanban-style project board and git branches.
• 2: The team makes large commits covering multiple features that make it difficult for the evaluator to determine the evolution of the application. The team does not utilize a planning tool or equitable pairing practices. One or both members do not contribute meaningfully to the application.
• 1: The team committed the code to version control in only a few commits. The evaluator cannot determine the evolution of the application.

Score: ? / 24