sam-theman88 / pe

0 stars 0 forks source link

Limited options for possible grades to assign for a module #2

Open sam-theman88 opened 1 week ago

sam-theman88 commented 1 week ago

Currently, only the following grades are allowed to be assigned to a module in the EduContacts app. Acceptable grades: A+, A, A-, B+, B, B-, C+, C, D+, D, F

However, the specified target users of this app are educators in tertiary institutions in Singapore. With this given context, tertiary institutions in Singapore often use the grades S and U as well. Hence these options should also be provided for users to make the app more useful and appealing for them.

Screenshot 1: specificTargetAudience.png

Screenshot 2: limitedGrades.png

soc-pe-bot commented 1 week ago

Team's Response

The development team has considered this in our planning but decided against including this after feature freeze for the following reason:

  1. We based our grading system on well known letter-based grading system, which follows the scale we have implemented.
  2. Not all tertiary institution support S/U grades.
  3. Adding arbitrary grades (like S/U) raises the argument for how much customisability our development team needs to support in terms of grades. Suppose a user wants to add a esoteric grading system for their own use case. Does this mean they should bombard the development team with requests to add this feature? Therefore we have decided to update this feature as part of our planned enhancements to the module utility (planned enhancement #9), whereby users are able to customise their use of the the "grade" functionality depending on the customisable "module" utility. This will support user-customisable grading systems, as well as changing the "grade" utility to something else entirely, such as "Attendance" for example.

Therefore, as this is part of our planned enhancements, this bug is rejected.

Items for the Tester to Verify

:question: Issue response

Team chose [response.Rejected]

Reason for disagreement: I think the logic about the developer team being bombarded if they were to be open and adhere to multiple requests from clients makes sense and I agree with that point. However, I disagree about the update already being part of the team's planned enhancements.

As per the course website guidelines (you may refer to the screenshot below), planned enhancements should be specific but their planned enhancement regarding "Enhanced Module Utility" is broad and covers multiple tweaks, especially if they want to stretch it to include customising the "grade" functionality.

Currently, the team's DG states the following: DGPlannedEnhance.png

The enhancement states renaming Module to Assignment which is already a tweak to the feature. But each enhancement should only be a single specific tweak. Hence this was the enhancement I considered and not the customisation of the "grade" functionality which the developer team stated in their response. Therefore I think the bug I reported is valid and should not be rejected. Thank you for your consideration.

Course website guidelines for planned enhancements: plannedEnhancementGuide.png