Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2025 - E2563. Review tableau

2025-12-03T05:00:32Z

Apimbert:

This page contains information about E2563.Review calibration, which was a project in CSC517 Fall 2025.

Please see below for a description of the design of the project.

== Background ==
Expertiza is an open-source application based on the Ruby on Rails framework. Instructors can create and manage assignments, and students can form teams for each one, as well as peer review other teams’ work. The frontend is written in TypeScript, and the backend is written in Ruby. The current codebase can be found here (FRONTEND, BACKEND), as well as in the external info section below. This work is part of an ongoing reimplementation effort of the following old Expertiza repository.

== Problem Statement ==
Instructors need to be able to view the responses made by a student during rounds of peer review in order to accurately assign a grade for that review. To streamline this process, our goal is to design and implement a dedicated page that allows instructors to view all grading reviews submitted by a given student. This page, named the '''review tableau page''', should organize and present the reviews in a clear, structured, and accessible manner. Specifically, the page must display all student grading reviews, grouped by assignment, round, and topic, with each group being rendered as a separate table.

== Requirements ==
=== Core Requirements ===
* A user with the '''Instructor''' role can view the review tableau(s) for a given student from a dedicated page (the ‘tableau page’) of the Expertiza site.
* The tableau page can be accessed by clicking a “Summary” link under the “Reviews Done” column when viewing students in the instructor’s rewiew-grading dashboard.
* The tableau page has the following contents:
** A header, displaying the text “Review by Student, “ followed by the student’s ID.
** Individual tables (‘tableaus’), each corresponding to a round of reviewing from a specific assignment with a specific rubric used during the review.
*** Tableaus are displayed in a single column on the tableau page.
*** Tableaus are sorted first by the '''round in which the review was made''', and then finally by the rubric used for review. This ensures that topics made chronologically close together are displayed sequentially. In the usual case, where the '''same''' rubric is used for all submissions, there will be only a single tableau. If rubric varies by topics, there may be multiple tableaus, reflecting the fact that the rubric may be different for different submissions reviewed by this reviewer.
* An individual tableau has the following contents:
** A label for the course number, semester, and year in which the review was made.
** A label for the assignment for which the review was made.
** A label for the round number for which the review was made.
** The primary table, which contains:
*** A highlighted column, populated with questions asked on the rubric.
*** An arbitrary number of additional columns, each corresponding to a review for that assignment and round that uses the rubric. Each of these is labelled after the team being reviewed and annotated with the date/time the review was submitted.
**** Each row of these columns is populated with the student’s responses for the corresponding review and question.
** Note that a single tableau records the results of all reviews made using the same rubric for a particular round. If a student provided reviews for topics (frontend, backend, full stack) with varying rubrics, then a tableau will be created for each type of rubric filled out.
* Creating a backend API that can retrieve the student’s grading reviews and sort them per each assignment, round, and topic. ''(Functional and local development)''

=== Design Requirements ===
[[File:Sample_of_the_review_tableau_layout.png|500px]]
* Follow the same design guidelines as reimplementation-front-end (https://github.com/AnvithaReddyGutha/reimplementation-front-end/blob/main/design_document.md).
* Use the same widgets (circles with numbers inside) that are used on the Response views.

== Implementation ==
There are three key components to the implementation of the review tableau:
* A new front end page, <code>ReviewTableau.tsx</code>, which consists of the view shown to the user accessing the review records.
* A new front end service, <code>gradesService.ts</code>, which converts the results of API calls into parameters for the view.
* A new back end API GET endpoint in <code>grades_controller.rb</code>, called <code>get_review_tableau_data</code>.

The intended flow, once integration is complete with [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2568._Finish_tabbed_view_for_Assignments,_including_Topics_and_Calibration_tabs E2568's work], is for admins and instructors to view a dashboard of participants for a given assignment, select one participant whose reviews are to be displayed, and then the review tableau page is loaded with the appropriate information. Because this dashboard does not yet exist, and to avoid redundant work, we have left the review tableau page inaccessible except via manually inputting the corresponding URL. This is for demonstration purposes: authorization still occurs as if the current user had requested the tableau.

The get_review_tableau_data endpoint accepts two parameters: an assignment_id and a participant_id. The Assignment identifier is used to search the <code>AssignmentQuestionnaires</code> table for all Questionnaires corresponding to each round of review in the target Assignment. The corresponding Items ("questions" on a standard rubric) are retrieved from the <code>Items</code> table, and hashed with their identifiers into the resulting JSON. The function then searches the <code>ResponseMaps</code> table for all Responses made for the target assignment by the target participant (the reviewer), and cross-references them with the <code>Responses</code> table to obtain the round in which the Response was submitted. Finally, the <code>Answers</code> table is consulted for each response identifier, and the value / comment associated with each answer is stored in the same hash. The JSON output is received by the front end and displayed in tables, one for each round.

[[File:e2563_tableau_api_logic.png|800px]]

'''NOTE: The current implementation assumes that there is only one Questionnaire associated with each round of a particular Assignment. Although association of several rubrics within a single round of review is an intended feature, and unused support exists for it in both the front end and back end components being introduced, there is currently no way to disambiguate which Response objects correspond to which associated Questionnaires outside of looking at the round number. As such, the feature as described cannot be implemented until changes are made to the database as part of work by the "multiple rubrics per topic" team(s).'''

The API payload adheres to the following structure, before being read and turned into parameters usable by the front end view:
<code>
{
"responses_by_round": {
"1": {
"min_answer_value": 0,
"max_answer_value": 5,
"items": {
"1": {
"description": "Criterion 1",
"question_type": "Checkbox",
"answers": {
"values": [
1,
3,
4
],
"comments": [
"Auto-generated answer 1",
"Reviewer note 1: The response meets expectations. A small suggestion for criterion 1: be more specific about implementation details.",
"Reviewer note 1: Strong submission — add more explanation for criterion 1 to increase clarity."
]
}
},
"2": {
"description": "Criterion 2",
"question_type": "Scale",
"answers": {
"values": [
4,
4,
5
],
"comments": [
"Auto-generated answer 2",
"Reviewer note 1: Strong submission — add more explanation for criterion 2 to increase clarity.",
"Reviewer note 1: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 2."
]
}
}
}
},
"2": {
"min_answer_value": 0,
"max_answer_value": 5,
"items": {
"1": {
"description": "Criterion 1",
"question_type": "Checkbox",
"answers": {
"values": [
3,
3,
4
],
"comments": [
"Round 2: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 1.",
"Reviewer note 2: The response meets expectations. A small suggestion for criterion 1: be more specific about implementation details.",
"Reviewer note 2: Strong submission — add more explanation for criterion 1 to increase clarity."
]
}
},
"2": {
"description": "Criterion 2",
"question_type": "Scale",
"answers": {
"values": [
3,
4,
5
],
"comments": [
"Round 2: Good work on criterion 2. Clear and well-structured.",
"Reviewer note 2: Strong submission — add more explanation for criterion 2 to increase clarity.",
"Reviewer note 2: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 2."
]
}
}
}
},
"3": {
"min_answer_value": 0,
"max_answer_value": 5,
"items": {
"1": {
"description": "Criterion 1",
"question_type": "Checkbox",
"answers": {
"values": [
5,
3,
4
],
"comments": [
"Round 3: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 1.",
"Reviewer note 3: The response meets expectations. A small suggestion for criterion 1: be more specific about implementation details.",
"Reviewer note 3: Strong submission — add more explanation for criterion 1 to increase clarity."
]
}
},
"2": {
"description": "Criterion 2",
"question_type": "Scale",
"answers": {
"values": [
5,
4,
5
],
"comments": [
"Round 3: Good work on criterion 2. Clear and well-structured.",
"Reviewer note 3: Strong submission — add more explanation for criterion 2 to increase clarity.",
"Reviewer note 3: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 2."
]
}
}
}
}
},
"participant": {
"id": 1,
"user_id": 4,
"user_name": "alton_mckenzie",
"full_name": "Prof. Tyler Keebler",
"handle": "alton_mckenzie"
},
"assignment": {
"id": 1,
"name": "ponder"
}
}
</code>

The finalized UI looks like this:
[[File:results_e2563.png|800px]]

== Test Plan ==
=== Manual Testing ===
# Login to Expertiza with an admin or instructor account.
# If the review dashboard exists:
## Navigate to the review dashboard for the desired assignment. Scroll to the desired participant, and click on the “summary” link.
# If the review dashboard is unimplemented:
## Navigate directly to http://localhost:3000/review-tableau?assignmentId=1&participantId=1, with both values replaced with the desired assignment/participant identifiers.
# Confirm that each table contains the items and answers for individual rubrics, arranged by individual responses and separate rounds of review.

=== Automated Testing ===
* npm tests for the new get_review_tableau_data endpoint (Review_Tableau.test.tsx).
** Parameter Validation - Ensures the component properly handles missing required URL parameters (assignmentId and participantId) by displaying an appropriate error message and preventing unnecessary API calls.
** Successful Data Loading - Verifies the complete data flow from API call to UI rendering, including proper display of reviewer information, course details, assignment name, and round headers.
** Error Handling - Tests graceful handling of API failures by mocking network errors and confirming error messages are displayed while hiding the main content.
** Loading States - Validates that loading indicators appear during data fetch operations and disappear once data is loaded, ensuring good user experience during async operations.
** Question Types - Tests the component's ability to handle multiple question types (Scale, Criterion, Dropdown) within a single rubric, verifying proper data transformation and rendering of mixed question formats.
== Team Members ==
Adam Imbert (apimbert)
‎<br />
Bestin Lalu (blalu)
‎<br />
Yumo Shen (jshen23)

File:Results e2563.png

2025-12-03T04:59:41Z

Apimbert:

CSC/ECE 517 Fall 2025 - E2563. Review tableau

2025-12-03T04:57:57Z

Apimbert:

This page contains information about E2563.Review calibration, which was a project in CSC517 Fall 2025.

Please see below for a description of the design of the project.

== Background ==
Expertiza is an open-source application based on the Ruby on Rails framework. Instructors can create and manage assignments, and students can form teams for each one, as well as peer review other teams’ work. The frontend is written in TypeScript, and the backend is written in Ruby. The current codebase can be found here (FRONTEND, BACKEND), as well as in the external info section below. This work is part of an ongoing reimplementation effort of the following old Expertiza repository.

== Problem Statement ==
Instructors need to be able to view the responses made by a student during rounds of peer review in order to accurately assign a grade for that review. To streamline this process, our goal is to design and implement a dedicated page that allows instructors to view all grading reviews submitted by a given student. This page, named the '''review tableau page''', should organize and present the reviews in a clear, structured, and accessible manner. Specifically, the page must display all student grading reviews, grouped by assignment, round, and topic, with each group being rendered as a separate table.

== Requirements ==
=== Core Requirements ===
* A user with the '''Instructor''' role can view the review tableau(s) for a given student from a dedicated page (the ‘tableau page’) of the Expertiza site.
* The tableau page can be accessed by clicking a “Summary” link under the “Reviews Done” column when viewing students in the instructor’s rewiew-grading dashboard.
* The tableau page has the following contents:
** A header, displaying the text “Review by Student, “ followed by the student’s ID.
** Individual tables (‘tableaus’), each corresponding to a round of reviewing from a specific assignment with a specific rubric used during the review.
*** Tableaus are displayed in a single column on the tableau page.
*** Tableaus are sorted first by the '''round in which the review was made''', and then finally by the rubric used for review. This ensures that topics made chronologically close together are displayed sequentially. In the usual case, where the '''same''' rubric is used for all submissions, there will be only a single tableau. If rubric varies by topics, there may be multiple tableaus, reflecting the fact that the rubric may be different for different submissions reviewed by this reviewer.
* An individual tableau has the following contents:
** A label for the course number, semester, and year in which the review was made.
** A label for the assignment for which the review was made.
** A label for the round number for which the review was made.
** The primary table, which contains:
*** A highlighted column, populated with questions asked on the rubric.
*** An arbitrary number of additional columns, each corresponding to a review for that assignment and round that uses the rubric. Each of these is labelled after the team being reviewed and annotated with the date/time the review was submitted.
**** Each row of these columns is populated with the student’s responses for the corresponding review and question.
** Note that a single tableau records the results of all reviews made using the same rubric for a particular round. If a student provided reviews for topics (frontend, backend, full stack) with varying rubrics, then a tableau will be created for each type of rubric filled out.
* Creating a backend API that can retrieve the student’s grading reviews and sort them per each assignment, round, and topic. ''(Functional and local development)''

=== Design Requirements ===
[[File:Sample_of_the_review_tableau_layout.png|500px]]
* Follow the same design guidelines as reimplementation-front-end (https://github.com/AnvithaReddyGutha/reimplementation-front-end/blob/main/design_document.md).
* Use the same widgets (circles with numbers inside) that are used on the Response views.

== Implementation ==
There are three key components to the implementation of the review tableau:
* A new front end page, <code>ReviewTableau.tsx</code>, which consists of the view shown to the user accessing the review records.
* A new front end service, <code>gradesService.ts</code>, which converts the results of API calls into parameters for the view.
* A new back end API GET endpoint in <code>grades_controller.rb</code>, called <code>get_review_tableau_data</code>.

The intended flow, once integration is complete with [https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2025_-_E2568._Finish_tabbed_view_for_Assignments,_including_Topics_and_Calibration_tabs E2568's work], is for admins and instructors to view a dashboard of participants for a given assignment, select one participant whose reviews are to be displayed, and then the review tableau page is loaded with the appropriate information. Because this dashboard does not yet exist, and to avoid redundant work, we have left the review tableau page inaccessible except via manually inputting the corresponding URL. This is for demonstration purposes: authorization still occurs as if the current user had requested the tableau.

The get_review_tableau_data endpoint accepts two parameters: an assignment_id and a participant_id. The Assignment identifier is used to search the <code>AssignmentQuestionnaires</code> table for all Questionnaires corresponding to each round of review in the target Assignment. The corresponding Items ("questions" on a standard rubric) are retrieved from the <code>Items</code> table, and hashed with their identifiers into the resulting JSON. The function then searches the <code>ResponseMaps</code> table for all Responses made for the target assignment by the target participant (the reviewer), and cross-references them with the <code>Responses</code> table to obtain the round in which the Response was submitted. Finally, the <code>Answers</code> table is consulted for each response identifier, and the value / comment associated with each answer is stored in the same hash. The JSON output is received by the front end and displayed in tables, one for each round.

[[File:e2563_tableau_api_logic.png|800px]]

'''NOTE: The current implementation assumes that there is only one Questionnaire associated with each round of a particular Assignment. Although association of several rubrics within a single round of review is an intended feature, and unused support exists for it in both the front end and back end components being introduced, there is currently no way to disambiguate which Response objects correspond to which associated Questionnaires outside of looking at the round number. As such, the feature as described cannot be implemented until changes are made to the database as part of work by the "multiple rubrics per topic" team(s).'''

The API payload adheres to the following structure, before being read and turned into parameters usable by the front end view:
<code>
{
"responses_by_round": {
"1": {
"min_answer_value": 0,
"max_answer_value": 5,
"items": {
"1": {
"description": "Criterion 1",
"question_type": "Checkbox",
"answers": {
"values": [
1,
3,
4
],
"comments": [
"Auto-generated answer 1",
"Reviewer note 1: The response meets expectations. A small suggestion for criterion 1: be more specific about implementation details.",
"Reviewer note 1: Strong submission — add more explanation for criterion 1 to increase clarity."
]
}
},
"2": {
"description": "Criterion 2",
"question_type": "Scale",
"answers": {
"values": [
4,
4,
5
],
"comments": [
"Auto-generated answer 2",
"Reviewer note 1: Strong submission — add more explanation for criterion 2 to increase clarity.",
"Reviewer note 1: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 2."
]
}
}
}
},
"2": {
"min_answer_value": 0,
"max_answer_value": 5,
"items": {
"1": {
"description": "Criterion 1",
"question_type": "Checkbox",
"answers": {
"values": [
3,
3,
4
],
"comments": [
"Round 2: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 1.",
"Reviewer note 2: The response meets expectations. A small suggestion for criterion 1: be more specific about implementation details.",
"Reviewer note 2: Strong submission — add more explanation for criterion 1 to increase clarity."
]
}
},
"2": {
"description": "Criterion 2",
"question_type": "Scale",
"answers": {
"values": [
3,
4,
5
],
"comments": [
"Round 2: Good work on criterion 2. Clear and well-structured.",
"Reviewer note 2: Strong submission — add more explanation for criterion 2 to increase clarity.",
"Reviewer note 2: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 2."
]
}
}
}
},
"3": {
"min_answer_value": 0,
"max_answer_value": 5,
"items": {
"1": {
"description": "Criterion 1",
"question_type": "Checkbox",
"answers": {
"values": [
5,
3,
4
],
"comments": [
"Round 3: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 1.",
"Reviewer note 3: The response meets expectations. A small suggestion for criterion 1: be more specific about implementation details.",
"Reviewer note 3: Strong submission — add more explanation for criterion 1 to increase clarity."
]
}
},
"2": {
"description": "Criterion 2",
"question_type": "Scale",
"answers": {
"values": [
5,
4,
5
],
"comments": [
"Round 3: Good work on criterion 2. Clear and well-structured.",
"Reviewer note 3: Strong submission — add more explanation for criterion 2 to increase clarity.",
"Reviewer note 3: Well done. One minor improvement is to illustrate your point with a concrete example for criterion 2."
]
}
}
}
}
},
"participant": {
"id": 1,
"user_id": 4,
"user_name": "alton_mckenzie",
"full_name": "Prof. Tyler Keebler",
"handle": "alton_mckenzie"
},
"assignment": {
"id": 1,
"name": "ponder"
}
}
</code>

== Test Plan ==
=== Manual Testing ===
# Login to Expertiza with an admin or instructor account.
# If the review dashboard exists:
## Navigate to the review dashboard for the desired assignment. Scroll to the desired participant, and click on the “summary” link.
# If the review dashboard is unimplemented:
## Navigate directly to http://localhost:3000/review-tableau?assignmentId=1&participantId=1, with both values replaced with the desired assignment/participant identifiers.
# Confirm that each table contains the items and answers for individual rubrics, arranged by individual responses and separate rounds of review.

=== Automated Testing ===
* npm tests for the new get_review_tableau_data endpoint (Review_Tableau.test.tsx).
** Parameter Validation - Ensures the component properly handles missing required URL parameters (assignmentId and participantId) by displaying an appropriate error message and preventing unnecessary API calls.
** Successful Data Loading - Verifies the complete data flow from API call to UI rendering, including proper display of reviewer information, course details, assignment name, and round headers.
** Error Handling - Tests graceful handling of API failures by mocking network errors and confirming error messages are displayed while hiding the main content.
** Loading States - Validates that loading indicators appear during data fetch operations and disappear once data is loaded, ensuring good user experience during async operations.
** Question Types - Tests the component's ability to handle multiple question types (Scale, Criterion, Dropdown) within a single rubric, verifying proper data transformation and rendering of mixed question formats.
== Team Members ==
Adam Imbert (apimbert)
‎<br />
Bestin Lalu (blalu)
‎<br />
Yumo Shen (jshen23)

CSC/ECE 517 Fall 2025 - E2563. Review tableau

2025-12-02T21:18:00Z

Apimbert:

File:E2563 tableau api logic.png

2025-12-02T21:13:26Z

Apimbert: The logic flows for the get_review_tableau_data GET endpoint.

== Summary ==
The logic flows for the get_review_tableau_data GET endpoint.

CSC/ECE 517 Fall 2025 - E2563. Review tableau

2025-12-02T21:11:49Z

Apimbert:

CSC/ECE 517 Fall 2025 - E2563. Review tableau

2025-12-02T20:54:28Z

Apimbert:

CSC/ECE 517 Fall 2025

2025-11-12T17:07:35Z

Apimbert:

* [[CSC/ECE 517 Fall 2025 - E2550. Response hierarchy and responses_controller back end]]
* [[CSC/ECE 517 Fall 2025 - E2551. Reimplementing SubmittedContentController]]
* [[CSC/ECE 517 Fall 2025 - E2552. ProjectTopic and SignedUpTeam]]
* [[CSC/ECE 517 Fall 2025 - E2553. Heatgrid and Grades Controller (Frontend + Backend)]]
* [[CSC/ECE 517 Fall 2025 - E2554. Front end for View Submissions Page]]
* [[CSC/ECE 517 Fall 2025 - E2555. Front end for Participants Page]]
* [[CSC/ECE 517 Fall 2025 - E2556. Front ends for Create Teams and Assign Reviewers]]
* [[CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types]]
* [[CSC/ECE 517 Fall 2025 - E2558. Tabbed view for creating and editing assignments]]

== Final Projects ==
* [[CSC/ECE 517 Fall 2025 - E2561. Finish up SubmittedContentController]]
* [[CSC/ECE 517 Fall 2025 - E2562. Review grading dashboard]]
* [[CSC/ECE 517 Fall 2025 - E2563. Review tableau]]
* [[CSC/ECE 517 Fall 2025 - E2564. Review calibration]]
* [[CSC/ECE 517 Fall 2025 - E2565. Integration of JoinTeamRequests]]
* [[CSC/ECE 517 Fall 2025 - E2566. Finish DueDates]]
* [[CSC/ECE 517 Fall 2025 - E2567. Review rubrics varying by round]]
* [[CSC/ECE 517 Fall 2025 - E2568. Finish tabbed view for Assignments, including Topics and Calibration tabs]]

CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types

2025-10-30T02:37:13Z

Apimbert:

= CSC/ECE 517 Fall 2025 – E2557. Specialized Rubrics for Different Topic Types =

== Overview ==
In the current Expertiza system, all projects within a course share a single rubric. This means that projects of different types — such as refactoring projects, testing projects, or front-end projects — must be evaluated using the same criteria.

The goal of this project is to enable instructors to assign '''different rubrics to different project topics''', allowing for more accurate and flexible assessment methods.

== Motivation ==
Expertiza supports a variety of project types across CSC/ECE 517 courses. However, because only one rubric can be assigned to a course at present, instructors cannot tailor rubrics to the distinct expectations of each project type.

By implementing specialized rubrics per topic, the evaluation process can better reflect the unique goals and deliverables of each project type.

== Functional Requirements ==
Note that several of these functional requirements were shared by the E2552 group, particularly any that rely on frontend implementation.

* By default, each course project uses the rubric specified on the '''Rubrics''' tab.
* On the '''Topics''' tab (in the Assignment Edit page), a '''dropdown''' should appear next to each topic.
** This dropdown allows instructors to choose a rubric specific to that topic.
** If no rubric is selected, the assignment’s default rubric is used.
* The '''signup sheet''' interface should display the rubric chosen for each topic.
* The '''rubric-selection logic''' should not reside within the `signup_sheet_controller`.
** Any non-topic-related logic should instead be handled in another controller or helper.
* A new column, `topic_id`, must be added to the `assignment_questionnaires` table to link a questionnaire to a specific topic.

== Implementation Details ==
To implement the requirements, we have made the following changes to the backend repository:
* Implemented rubric_list, a new GET API endpoint in sign_up_topics_controller.rb, which returns the topics and rubrics associated with a specific assignment. These are serialized into a readable JSON format to facilitate frontend use.
* Inserted "topic_id" as a foreign key assignment_questionnaire.rb, and added a "questionnaire" field to sign_up_topic.rb. These allow topics to be assigned on a per-assignment, per-round basis.
* Implemented rubric_for_review, a function in the sign_up_topic.rb model that returns the appropriate questionnaire for a topic given a specific round number that questionnaire corresponds to.
* Implemented has_specific_rubric?, a function in the sign_up_topic.rb model that returns whether or not the topic has an associated rubric for the given round.
* Introduced topic_rubrics_helper.rb, a helper class designed to carry the assign_rubric_to_topic function. This associates the given assignment, topic, questionnaire, and round number with each other in the database in an unobtrusive way that does not gunk up other classes.
* Created sign_up_topic_spec.rb, a testing class designed to test the aforementioned new functions in the SignUpTopic class.

== Integration of AI ==
Artificially intelligent LLM models (ChatGPT, Claude.ai) were leveraged to streamline development and consult regarding critical design decisions.

Firstly: [https://claude.ai/share/fbd40465-86ae-498c-bb22-1b719784a928 unspecific, project-encompassing] conversations served to give us a high-level understanding of what tasks needed to be completed, and what components might comprise a completed implementation. Having this overview is important for project planning, especially with the shorter time window we gave ourselves to complete implementation. While we did not have access to Issues to populate a GitHub project page, we were able to break the implementation into tasks for our own internal production management.

Secondly: [https://chatgpt.com/c/690227fe-a6c4-832d-a485-e284f1a457f0 troubleshooting] or [https://chatgpt.com/share/6902cda2-364c-8007-b18d-d804023b73d1 class-specific] conversations allowed us to isolate a component of the implementation and (hopefully) keep everything modular, extensible, and maintainable. And, of course, promptly fix any bugs we encountered in setup or execution of our implementation!

== Future Work ==
Due to unfortunate time constraints, both circumstantial and self-imposed, the implementation as it stands is lacking in a number of key categories. Chiefly, our rspec tests are undertested due to issues running the rspec test suite. As such, we recommend careful code review is applied to the resulting PR before it is considered for merging. The PR is set to "DRAFT" to reflect this.

With that being said, here are a few action steps for future teams tackling this problem:
* Finalize the API integration with the front-end dropdown component.
* Implement logic to persist rubric–topic associations.
* Ensure that current automated test coverage for the new functionality is sufficient and correct.
* Conduct usability testing and gather instructor feedback, as always!

== Useful Links ==
* [https://github.com/Prismly/reimplementation-back-end/tree/main Team GitHub Repository]
* [https://github.com/expertiza/reimplementation-back-end/pull/226 Backend Pull Request]
* [https://docs.google.com/presentation/d/1dltJz9vOSq-tDVyGDUtLTfuC5gVlylsdjNs7TPJTQBk/edit?usp=sharing Demo Slide Deck] (requires NCSU Google Account)

== Team Information ==
* Adam Imbert (apimbert)
* Iman Khan (ikhan7)
* Niranjan Rajendran (nrajend4)
* '''Mentor''': Ed Gehringer (efg)

== References ==
* Original codebase feature page: [[CSC/ECE 517 Spring 2020 - E2026. Specialized rubrics for different topic types|Project E2026 Wiki Page]]
* Reimplementation precedent feature page: [[CSC/ECE_517_Spring_2025_-_E2513._Reimplement_sign_up_topic.rb_as_project_topic.rb|Project E2513 Wiki Page]]

----

CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types

2025-10-30T02:34:56Z

Apimbert:

= CSC/ECE 517 Fall 2025 – E2557. Specialized Rubrics for Different Topic Types =

== Overview ==
In the current Expertiza system, all projects within a course share a single rubric. This means that projects of different types — such as refactoring projects, testing projects, or front-end projects — must be evaluated using the same criteria.

The goal of this project is to enable instructors to assign '''different rubrics to different project topics''', allowing for more accurate and flexible assessment methods.

== Motivation ==
Expertiza supports a variety of project types across CSC/ECE 517 courses. However, because only one rubric can be assigned to a course at present, instructors cannot tailor rubrics to the distinct expectations of each project type.

By implementing specialized rubrics per topic, the evaluation process can better reflect the unique goals and deliverables of each project type.

== Functional Requirements ==
Note that several of these functional requirements were shared by the E2552 group, particularly any that rely on frontend implementation.

* By default, each course project uses the rubric specified on the '''Rubrics''' tab.
* On the '''Topics''' tab (in the Assignment Edit page), a '''dropdown''' should appear next to each topic.
** This dropdown allows instructors to choose a rubric specific to that topic.
** If no rubric is selected, the assignment’s default rubric is used.
* The '''signup sheet''' interface should display the rubric chosen for each topic.
* The '''rubric-selection logic''' should not reside within the `signup_sheet_controller`.
** Any non-topic-related logic should instead be handled in another controller or helper.
* A new column, `topic_id`, must be added to the `assignment_questionnaires` table to link a questionnaire to a specific topic.

== Implementation Details ==
To implement the requirements, we have made the following changes to the backend repository:
* Implemented rubric_list, a new GET API endpoint in sign_up_topics_controller.rb, which returns the topics and rubrics associated with a specific assignment. These are serialized into a readable JSON format to facilitate frontend use.
* Inserted "topic_id" as a foreign key assignment_questionnaire.rb, and added a "questionnaire" field to sign_up_topic.rb. These allow topics to be assigned on a per-assignment, per-round basis.
* Implemented rubric_for_review, a function in the sign_up_topic.rb model that returns the appropriate questionnaire for a topic given a specific round number that questionnaire corresponds to.
* Implemented has_specific_rubric?, a function in the sign_up_topic.rb model that returns whether or not the topic has an associated rubric for the given round.
* Introduced topic_rubrics_helper.rb, a helper class designed to carry the assign_rubric_to_topic function. This associates the given assignment, topic, questionnaire, and round number with each other in the database in an unobtrusive way that does not gunk up other classes.
* Created sign_up_topic_spec.rb, a testing class designed to test the aforementioned new functions in the SignUpTopic class.

== Integration of AI ==
Artificially intelligent LLM models (ChatGPT, Claude.ai) were leveraged to streamline development and consult regarding critical design decisions.

Firstly: [https://claude.ai/share/fbd40465-86ae-498c-bb22-1b719784a928 unspecific, project-encompassing] conversations served to give us a high-level understanding of what tasks needed to be completed, and what components might comprise a completed implementation. Having this overview is important for project planning, especially with the shorter time window we gave ourselves to complete implementation. While we did not have access to Issues to populate a GitHub project page, we were able to break the implementation into tasks for our own internal production management.

Secondly: [https://chatgpt.com/c/690227fe-a6c4-832d-a485-e284f1a457f0 troubleshooting] or [https://chatgpt.com/share/6902cda2-364c-8007-b18d-d804023b73d1 class-specific] conversations allowed us to isolate a component of the implementation and (hopefully) keep everything modular, extensible, and maintainable. And, of course, promptly fix any bugs we encountered in setup or execution of our implementation!

== Future Work ==
Due to unfortunate time constraints, both circumstantial and self-imposed, the implementation as it stands is lacking in a number of key categories. Chiefly, our rspec tests are undertested due to issues running the rspec test suite. As such, we recommend careful code review is applied to the resulting PR before it is considered for merging. The PR is set to "DRAFT" to reflect this.

With that being said, here are a few action steps for future teams tackling this problem:
* Finalize the API integration with the front-end dropdown component.
* Implement logic to persist rubric–topic associations.
* Ensure that current automated test coverage for the new functionality is sufficient and correct.
* Conduct usability testing and gather instructor feedback, as always!

== Useful Links ==
* [https://github.com/Prismly/reimplementation-back-end/tree/main Team GitHub Repository]
* [https://github.com/expertiza/reimplementation-back-end/pull/226 Backend Pull Request]
* TODO: Demo Recording

== Team Information ==
* Adam Imbert (apimbert)
* Iman Khan (ikhan7)
* Niranjan Rajendran (nrajend4)
* '''Mentor''': Ed Gehringer (efg)

== References ==
* Original codebase feature page: [[CSC/ECE 517 Spring 2020 - E2026. Specialized rubrics for different topic types|Project E2026 Wiki Page]]
* Reimplementation precedent feature page: [[CSC/ECE_517_Spring_2025_-_E2513._Reimplement_sign_up_topic.rb_as_project_topic.rb|Project E2513 Wiki Page]]

----

CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types

2025-10-30T02:31:51Z

Apimbert:

= CSC/ECE 517 Fall 2025 – E2557. Specialized Rubrics for Different Topic Types =

== Overview ==
In the current Expertiza system, all projects within a course share a single rubric. This means that projects of different types — such as refactoring projects, testing projects, or front-end projects — must be evaluated using the same criteria.

The goal of this project is to enable instructors to assign '''different rubrics to different project topics''', allowing for more accurate and flexible assessment methods.

== Motivation ==
Expertiza supports a variety of project types across CSC/ECE 517 courses. However, because only one rubric can be assigned to a course at present, instructors cannot tailor rubrics to the distinct expectations of each project type.

By implementing specialized rubrics per topic, the evaluation process can better reflect the unique goals and deliverables of each project type.

== Functional Requirements ==
Note that several of these functional requirements were shared by the E2552 group, particularly any that rely on frontend implementation.

* By default, each course project uses the rubric specified on the '''Rubrics''' tab.
* On the '''Topics''' tab (in the Assignment Edit page), a '''dropdown''' should appear next to each topic.
** This dropdown allows instructors to choose a rubric specific to that topic.
** If no rubric is selected, the assignment’s default rubric is used.
* The '''signup sheet''' interface should display the rubric chosen for each topic.
* The '''rubric-selection logic''' should not reside within the `signup_sheet_controller`.
** Any non-topic-related logic should instead be handled in another controller or helper.
* A new column, `topic_id`, must be added to the `assignment_questionnaires` table to link a questionnaire to a specific topic.

== Implementation Details ==
To implement the requirements, we have made the following changes to the backend repository:
* Implemented rubric_list, a new GET API endpoint in sign_up_topics_controller.rb, which returns the topics and rubrics associated with a specific assignment. These are serialized into a readable JSON format to facilitate frontend use.
* Inserted "topic_id" as a foreign key assignment_questionnaire.rb, and added a "questionnaire" field to sign_up_topic.rb. These allow topics to be assigned on a per-assignment, per-round basis.
* Implemented rubric_for_review, a function in the sign_up_topic.rb model that returns the appropriate questionnaire for a topic given a specific round number that questionnaire corresponds to.
* Implemented has_specific_rubric?, a function in the sign_up_topic.rb model that returns whether or not the topic has an associated rubric for the given round.
* Introduced topic_rubrics_helper.rb, a helper class designed to carry the assign_rubric_to_topic function. This associates the given assignment, topic, questionnaire, and round number with each other in the database in an unobtrusive way that does not gunk up other classes.
* Created sign_up_topic_spec.rb, a testing class designed to test the aforementioned new functions in the SignUpTopic class.

== Integration of AI ==
Artificially intelligent LLM models (ChatGPT, Claude.ai) were leveraged to streamline development and consult regarding critical design decisions.

Firstly: [https://claude.ai/share/fbd40465-86ae-498c-bb22-1b719784a928 unspecific, project-encompassing] conversations served to give us a high-level understanding of what tasks needed to be completed, and what components might comprise a completed implementation. Having this overview is important for project planning, especially with the shorter time window we gave ourselves to complete implementation. While we did not have access to Issues to populate a GitHub project page, we were able to break the implementation into tasks for our own internal production management.

Secondly: [https://chatgpt.com/c/690227fe-a6c4-832d-a485-e284f1a457f0 troubleshooting] or [https://chatgpt.com/share/6902cda2-364c-8007-b18d-d804023b73d1 class-specific] conversations allowed us to isolate a component of the implementation and (hopefully) keep everything modular, extensible, and maintainable. And, of course, promptly fix any bugs we encountered in setup or execution of our implementation!

== Future Work ==
* Finalize the API integration with the front-end dropdown component.
* Implement logic to persist rubric–topic associations.
* Ensure that current automated test coverage for the new functionality is sufficient and correct.
* Conduct usability testing and gather instructor feedback, as always!

== Useful Links ==
* [https://github.com/Prismly/reimplementation-back-end/tree/main Team GitHub Repository]
* [https://github.com/expertiza/reimplementation-back-end/pull/226 Backend Pull Request]
* TODO: Demo Recording

== Team Information ==
* Adam Imbert (apimbert)
* Iman Khan (ikhan7)
* Niranjan Rajendran (nrajend4)
* '''Mentor''': Ed Gehringer (efg)

== References ==
* Original codebase feature page: [[CSC/ECE 517 Spring 2020 - E2026. Specialized rubrics for different topic types|Project E2026 Wiki Page]]
* Reimplementation precedent feature page: [[CSC/ECE_517_Spring_2025_-_E2513._Reimplement_sign_up_topic.rb_as_project_topic.rb|Project E2513 Wiki Page]]

----

''This page will be updated as development progresses to reflect new commits, API changes, and testing results.''

CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types

2025-10-30T02:24:01Z

Apimbert:

= CSC/ECE 517 Fall 2025 – E2557. Specialized Rubrics for Different Topic Types =

== Overview ==
In the current Expertiza system, all projects within a course share a single rubric. This means that projects of different types — such as refactoring projects, testing projects, or front-end projects — must be evaluated using the same criteria.

The goal of this project is to enable instructors to assign '''different rubrics to different project topics''', allowing for more accurate and flexible assessment methods.

== Motivation ==
Expertiza supports a variety of project types across CSC/ECE 517 courses. However, because only one rubric can be assigned to a course at present, instructors cannot tailor rubrics to the distinct expectations of each project type.

By implementing specialized rubrics per topic, the evaluation process can better reflect the unique goals and deliverables of each project type.

== Functional Requirements ==
Note that several of these functional requirements were shared by the E2552 group, particularly any that rely on frontend implementation.

* By default, each course project uses the rubric specified on the '''Rubrics''' tab.
* On the '''Topics''' tab (in the Assignment Edit page), a '''dropdown''' should appear next to each topic.
** This dropdown allows instructors to choose a rubric specific to that topic.
** If no rubric is selected, the assignment’s default rubric is used.
* The '''signup sheet''' interface should display the rubric chosen for each topic.
* The '''rubric-selection logic''' should not reside within the `signup_sheet_controller`.
** Any non-topic-related logic should instead be handled in another controller or helper.
* A new column, `topic_id`, must be added to the `assignment_questionnaires` table to link a questionnaire to a specific topic.

== Implementation Details ==
To implement the requirements, we have made the following changes to the backend repository:
* Implemented rubric_list, a new GET API endpoint in sign_up_topics_controller.rb, which returns the topics and rubrics associated with a specific assignment. These are serialized into a readable JSON format to facilitate frontend use.
* Inserted "topic_id" as a foreign key assignment_questionnaire.rb, and added a "questionnaire" field to sign_up_topic.rb. These allow topics to be assigned on a per-assignment, per-round basis.
* Implemented rubric_for_review, a function in the sign_up_topic.rb model that returns the appropriate questionnaire for a topic given a specific round number that questionnaire corresponds to.
* Implemented has_specific_rubric?, a function in the sign_up_topic.rb model that returns whether or not the topic has an associated rubric for the given round.
* Introduced topic_rubrics_helper.rb, a helper class designed to carry the assign_rubric_to_topic function. This associates the given assignment, topic, questionnaire, and round number with each other in the database in an unobtrusive way that does not gunk up other classes.
* Created sign_up_topic_spec.rb, a testing class designed to test the aforementioned new functions in the SignUpTopic class.

== Future Work ==
* Finalize the API integration with the front-end dropdown component.
* Implement logic to persist rubric–topic associations.
* Ensure that current automated test coverage for the new functionality is sufficient and correct.
* Conduct usability testing and gather instructor feedback, as always!

== Useful Links ==
* [https://github.com/Prismly/reimplementation-back-end/tree/main Team GitHub Repository]
* [https://github.com/expertiza/reimplementation-back-end/pull/226 Backend Pull Request]
* TODO: Demo Recording

== Team Information ==
* Adam Imbert (apimbert)
* Iman Khan (ikhan7)
* Niranjan Rajendran (nrajend4)
* '''Mentor''': Ed Gehringer (efg)

== References ==
* Original codebase feature page: [[CSC/ECE 517 Spring 2020 - E2026. Specialized rubrics for different topic types|Project E2026 Wiki Page]]
* Reimplementation precedent feature page: [[CSC/ECE_517_Spring_2025_-_E2513._Reimplement_sign_up_topic.rb_as_project_topic.rb|Project E2513 Wiki Page]]

----

''This page will be updated as development progresses to reflect new commits, API changes, and testing results.''

CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types

2025-10-30T02:22:42Z

Apimbert:

= CSC/ECE 517 Fall 2025 – E2557. Specialized Rubrics for Different Topic Types =

== Overview ==
In the current Expertiza system, all projects within a course share a single rubric. This means that projects of different types — such as refactoring projects, testing projects, or front-end projects — must be evaluated using the same criteria.

The goal of this project is to enable instructors to assign '''different rubrics to different project topics''', allowing for more accurate and flexible assessment methods.

== Motivation ==
Expertiza supports a variety of project types across CSC/ECE 517 courses. However, because only one rubric can be assigned to a course at present, instructors cannot tailor rubrics to the distinct expectations of each project type.

By implementing specialized rubrics per topic, the evaluation process can better reflect the unique goals and deliverables of each project type.

== Functional Requirements ==
Note that several of these functional requirements were shared by the E2552 group, particularly any that rely on frontend implementation.

* By default, each course project uses the rubric specified on the '''Rubrics''' tab.
* On the '''Topics''' tab (in the Assignment Edit page), a '''dropdown''' should appear next to each topic.
** This dropdown allows instructors to choose a rubric specific to that topic.
** If no rubric is selected, the assignment’s default rubric is used.
* The '''signup sheet''' interface should display the rubric chosen for each topic.
* The '''rubric-selection logic''' should not reside within the `signup_sheet_controller`.
** Any non-topic-related logic should instead be handled in another controller or helper.
* A new column, `topic_id`, must be added to the `assignment_questionnaires` table to link a questionnaire to a specific topic.

== Implementation Details ==
To implement the requirements, we have made the following changes to the backend repository:
* Implemented rubric_list, a new GET API endpoint in sign_up_topics_controller.rb, which returns the topics and rubrics associated with a specific assignment. These are serialized into a readable JSON format to facilitate frontend use.
* Inserted "topic_id" as a foreign key assignment_questionnaire.rb, and added a "questionnaire" field to sign_up_topic.rb. These allow topics to be assigned on a per-assignment, per-round basis.
* Implemented rubric_for_review, a function in the sign_up_topic.rb model that returns the appropriate questionnaire for a topic given a specific round number that questionnaire corresponds to.
* Implemented has_specific_rubric?, a function in the sign_up_topic.rb model that returns whether or not the topic has an associated rubric for the given round.
* Introduced topic_rubrics_helper.rb, a helper class designed to carry the assign_rubric_to_topic function. This associates the given assignment, topic, questionnaire, and round number with each other in the database in an unobtrusive way that does not gunk up other classes.
* Created sign_up_topic_spec.rb, a testing class designed to test the aforementioned new functions in the SignUpTopic class.

== Future Work ==
* Finalize the API integration with the front-end dropdown component.
* Implement logic to persist rubric–topic associations.
* Ensure that current automated test coverage for the new functionality is sufficient and correct.
* Conduct usability testing and gather instructor feedback, as always!

== Useful Links ==
* [https://github.com/Prismly/reimplementation-back-end/tree/main Team GitHub Repository]
* [ Backend Pull Request]
* TODO: Demo Recording

== Team Information ==
* Adam Imbert (apimbert)
* Iman Khan (ikhan7)
* Niranjan Rajendran (nrajend4)
* '''Mentor''': Ed Gehringer (efg)

== References ==
* Original codebase feature page: [[CSC/ECE 517 Spring 2020 - E2026. Specialized rubrics for different topic types|Project E2026 Wiki Page]]
* Reimplementation precedent feature page: [[CSC/ECE_517_Spring_2025_-_E2513._Reimplement_sign_up_topic.rb_as_project_topic.rb|Project E2513 Wiki Page]]

----

''This page will be updated as development progresses to reflect new commits, API changes, and testing results.''

CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types

2025-10-30T02:17:08Z

Apimbert:

= CSC/ECE 517 Fall 2025 – E2557. Specialized Rubrics for Different Topic Types =

== Overview ==
In the current Expertiza system, all projects within a course share a single rubric. This means that projects of different types — such as refactoring projects, testing projects, or front-end projects — must be evaluated using the same criteria.

The goal of this project is to enable instructors to assign '''different rubrics to different project topics''', allowing for more accurate and flexible assessment methods.

== Motivation ==
Expertiza supports a variety of project types across CSC/ECE 517 courses. However, because only one rubric can be assigned to a course at present, instructors cannot tailor rubrics to the distinct expectations of each project type.

By implementing specialized rubrics per topic, the evaluation process can better reflect the unique goals and deliverables of each project type.

== Functional Requirements ==
Note that several of these functional requirements were shared by the E2552 group, particularly any that rely on frontend implementation.

* By default, each course project uses the rubric specified on the '''Rubrics''' tab.
* On the '''Topics''' tab (in the Assignment Edit page), a '''dropdown''' should appear next to each topic.
** This dropdown allows instructors to choose a rubric specific to that topic.
** If no rubric is selected, the assignment’s default rubric is used.
* The '''signup sheet''' interface should display the rubric chosen for each topic.
* The '''rubric-selection logic''' should not reside within the `signup_sheet_controller`.
** Any non-topic-related logic should instead be handled in another controller or helper.
* A new column, `topic_id`, must be added to the `assignment_questionnaires` table to link a questionnaire to a specific topic.

== Implementation Details ==
To implement the requirements, we have made the following changes to the backend repository:
* Implemented rubric_list, a new GET API endpoint in sign_up_topics_controller.rb, which returns the topics and rubrics associated with a specific assignment. These are serialized into a readable JSON format to facilitate frontend use.
* Inserted "topic_id" as a foreign key assignment_questionnaire.rb, and added a "questionnaire" field to sign_up_topic.rb. These allow topics to be assigned on a per-assignment, per-round basis.
* Implemented rubric_for_review, a function in the sign_up_topic.rb model that returns the appropriate questionnaire for a topic given a specific round number that questionnaire corresponds to.
* Implemented has_specific_rubric?, a function in the sign_up_topic.rb model that returns whether or not the topic has an associated rubric for the given round.
* Introduced topic_rubrics_helper.rb, a helper class designed to carry the assign_rubric_to_topic function. This associates the given assignment, topic, questionnaire, and round number with each other in the database in an unobtrusive way that does not gunk up other classes.

== Required Modifications ==
* Extend the functionality introduced in Project E2513 to support rubric–topic associations.
* Introduce `topic_id` to the `assignment_questionnaires` table.
* Implement API endpoints to retrieve rubrics per assignment, including their associated topics.
* Write automated tests to ensure the correctness of the new features.

== Progress So Far ==
* Identified and verified prior functionality from the '''E2552''' team:
** Added the rubric dropdown to the assignment topics page.
** Introduced the `topic_id` field to the `assignment_questionnaires` table.
* Added an '''API endpoint''' that retrieves rubrics for a given assignment, serialized together with their assigned topics.
* Implemented and tested the `topic_id` field integration.
* Additional backend logic and tests are in progress.

== Future Work ==
* Finalize the API integration with the front-end dropdown component.
* Implement logic to persist rubric–topic associations.
* Extend automated test coverage for the new functionality.
* Conduct usability testing and gather instructor feedback.

== Useful Links ==
* [https://github.com/Prismly/reimplementation-back-end/tree/main Team GitHub Repository]
* [ Backend Pull Request]
* TODO: Demo Recording

== Team Information ==
* Adam Imbert (apimbert)
* Iman Khan (ikhan7)
* Niranjan Rajendran (nrajend4)
* '''Mentor''': Ed Gehringer (efg)

== References ==
* Original codebase feature page: [[CSC/ECE 517 Spring 2020 - E2026. Specialized rubrics for different topic types|Project E2026 Wiki Page]]
* Reimplementation precedent feature page: [[CSC/ECE_517_Spring_2025_-_E2513._Reimplement_sign_up_topic.rb_as_project_topic.rb|Project E2513 Wiki Page]]

----

''This page will be updated as development progresses to reflect new commits, API changes, and testing results.''

CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types

2025-10-29T21:29:47Z

Apimbert:

CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types

2025-10-29T19:44:14Z

Apimbert:

CSC/ECE 517 Fall 2025 - E2557. Specialized rubrics for different topic types

2025-10-29T19:41:10Z

Apimbert: Created page with "= CSC/ECE 517 Fall 2025 – E2557. Specialized Rubrics for Different Topic Types = == Overview == In the current Expertiza system, all projects within a course share a single rubric. This means that projects of different types — such as refactoring projects, testing projects, or front-end projects — must be evaluated using the same criteria. The goal of this project is to enable instructors to assign **different rubrics to different project topics**, allowing for..."