Open PrishaVP opened 1 week ago
The issue described, where a group can have 0 members through removal, aligns with the behavior stated in the UG and does not constitute a functionality bug. The UG specifies that at least one index (person) must be added during group creation. This ensures that a group cannot initially be created as empty. However, it does not explicitly restrict the removal of all members after creation.
This behaviour is working as designed and is consistent with the UG.
--
Furthermore, we acknowledge that allowing empty groups to be created could enhance user flexibility. As outlined in the Planned Enhancements section of our documentation, we have already identified this as an area for improvement and plan to officially allow empty group creation in future updates.
Team chose [response.Rejected
]
Reason for disagreement: While your UG does not "explicitly restrict the removal of all members after creation" it also does not explicitly state that this is allowed either. Instead of basing arguments on what's missing, let's focus on what's actually present in the UG and what implications it has and what assumptions a user who is reading the UG will make (assumptions are unavoidable when the UG is not sufficiently thorough).
As stated in your UG and in your response, the creation of groups specifies that there must be at least one member in a group. This strongly implies to the user that a group must have people in it (plus, nothing contrary to this is stated anywhere else in the UG for the current version of your app). This is pretty sensible, although a future version could enable empty groups to be created, as stated in your planned enhancements. But for now, a user would read your UG on group creation and reach the conclusion that currently, groups must have people (since your UG is strict on group creation requiring at least one person currently).
Therefore, following the current implied principle that a group must have people, it seems incorrect and "buggy" that such a seemingly strict rule can be broken through a "loophole" by removing all members of the group, leaving an empty (seemingly "invalid") group. Since the user is lead to assume that groups cannot be empty in the current version of your app, the removal of all members should gracefully handle empty groups and remove such groups rather than allowing such an "invalid" group to remain. Due to your strict wording for the creation of groups, it feels like you promised that groups must have people in it and then your remove members feature sneakily causes the promise to be broken, thus I still believe this is a functionality bug.
Your planned enhancement is a future goal for allowing the creation of empty groups. After you eventually enact this, then only would it be logical and meaningful for empty groups to exist and then only should you enable a feature that allows for removal of all members to cause a continued existence of an empty group. For now, it seems incorrect that such a group should continue to exist and the removal of members should be gracefully handled to either prevent all members from being removed or removing the group itself after it becomes empty/obsolete (i.e. after it violates the strongly implied principle that groups must have members).
The UG states that there must be at least one person in a group (an empty group is not allowed to be created). However, all members of the group can be deleted but the group will still exist.