Open HanB1n opened 2 weeks ago
This is indeed something that we could have included to aid reader comprehension, and we will take note of it. However, the link and unlink commands are only a small component of the features that we have added, not one of the major features. The biggest component of our application is the ability to track events, as well as their schedules. Additionally, the omission does not disrupt functionality; it reduces clarity in the documentation.
Team chose [severity.Low
]
Originally [severity.Medium
]
Reason for disagreement: Severity Low should apply only to rare cases. In this case, it is more appopriate for the severity to be Medium as all readers who reads the documentation would be subjected to this documentation bug.
However, as a Developer trying to improve or redesign the application, the lack of documentation makes it hard for the reader to actually understand how this link and unlink is implemented and how it is stored in the storage. Furthermore, there is no additional elaboration for the implementation of this feature anywhere in the DG.
It is also stated that this is the main challenge the group faced but no supporting documentation is provided for future developers.
I would also disagree with the team's argument that this is not a major component given the fact that they have mentioned the feature as one of their value propositions.
Given the substantial lack of information provided in the DG supporting this feature, the severity should be at least Medium.
There is no mention of linkedPersonsEntries in the UML class diagram for Storage which is a crucial part of your implementation. As a Developer, I have no idea how the link between a Person and a Event is stored when this is one of the biggest component of your application.
UML Diagram:
addressbook.json: