Feature #1.2 - Group Creation and Organizational Structuring

[Nyero2023]

Description:

The Group Creation and Organizational Structuring functionality empowers users to seamlessly establish and manage groups, fostering a structured and collaborative environment. This feature enables the effortless creation of diverse groups tailored to specific project requirements and community or organizational goals. Users can efficiently organize and allocate tasks, streamline communication, and enhance productivity by customizing group structures to align with their unique workflow.

User Story:

As a group admin, I want to be able to create groups and organize them within a structured hierarchy so that I can efficiently manage team collaboration and communication.

Acceptance Criteria:

• Given that the user has created or registered as a "Group account" on the platform and is logged in, the user sees a "CTA" prompting them to complete their profile setup with the following details:

  • Contact & Location

  • Contact Email (Required)

  • Contact Number (Optional)

  • Website URL (Optional)

  • Physical Address (Optional)

  • City/Region (Optional)

  • Country (Optional)

  • Membership & Privacy

  • Membership Type (e.g., Open, By Invitation Only, Requires Approval)

  • Privacy Setting (e.g., Public, Private)

  • Member Roles & Permissions (Define roles and what actions each role can perform)

  • Group Categories & Interests

  • Primary Category (e.g., Education, Health, Environment)

  • Secondary Categories (Optional, e.g., Advocacy, Community Service)

  • Tags/Keywords (To help in search and categorization)

  • Group Activities & Events

  • Regular Meeting Schedule (Optional, e.g., Every Tuesday at 6 PM)

  • Upcoming Events (Optional, can be added later)

  • Past Events (Optional, can be added later)

  • Social Media & External Links

  • Facebook Page (Optional)

  • Twitter Handle (Optional)

  • LinkedIn Profile (Optional)

  • Other Social Media Links (Optional)

  • External Resources (e.g., Related articles, publications, websites)

  • Additional Information

  • Group Objectives/Mission Statement

  • Group History/Background (Optional)

• Consider incorporating a progress indicator to show users how far they are in completing their group profile.

• Users can organize groups into a hierarchical structure. The hierarchy supports multiple levels (parent-child relationships) to represent different organizational levels or departments.

  • Each subgroup displays relevant details, including its name, description, and the number of members. The user (Group Admin) can edit the details of any group within the structure.

• Users (Group Admin) can send group requests and also receive friend requests.

• Users (Group Admin) can also remove members from a group or subgroup.

• Users can easily search for specific groups within the hierarchy. The search results display relevant details, making it simple to identify the desired group. ???????????

• The system allows users to set permissions for each group.

  • Permissions include the ability to create subgroups, add or remove members, and manage group details.

• Users (Group Admins) receive notifications for any updates or changes related to the groups they manage or are a part of.

  • Notifications include new group creations, membership changes, and updates to group details.

Edge Cases

• Duplicate Group Names:
  • The system should prevent the creation of groups with duplicate names within the same hierarchy.
• Maximum Hierarchy Depth:
  • Ensure that the system handles the maximum allowed depth of the hierarchy gracefully and provides clear messaging if the user attempts to exceed this limit.
• Adding Non-existent Members:
  • If attempting to add a member who does not exist in the system, provide an error message and guide the user on adding valid members.
• Editing Group Details:
  • Ensure that changes to group details are immediately reflected in the system and that users see updated information without the need for manual refresh.
• Permission Validation:
  • Verify that users attempting to perform actions within a group have the necessary permissions, and prevent unauthorized actions.
• Concurrent Edits:
  • Handle scenarios where multiple users are editing the same group simultaneously to avoid conflicts and ensure data integrity.

Technical Requirements (if applicable):

List any technical requirements or specifications for this feature. Include details like APIs, data models, or architectural considerations.

Design Specifications:

Attach or link to any design mockups, wireframes, or UI/UX specifications related to this feature.

Dependencies:

List any dependencies that this feature story has on other tasks, user stories, or Epics.

• Registration and Log In/Out

Resources Needed:

• Product Manager
• Frontend Developer
• Backend Developer
• QA Engineer

Related Issues/Epics:

• [ ] [Link to related Epic #197]
• [ ] [Link to related issue #10]
• [ ] [Link to related issue #11]
• [ ] [Link to related issue #200]
• [ ] [Link to related issue #201]
• [ ] [Link to related issue #202] (Add as many as necessary)

Notes:

Add any additional notes or comments that can provide more context to the team members working on this feature story.

[quakermiss]

Hi @Nyero2023! This is my first attempt at using GitHub, so please allow me a bit of leniency as I try to understand the purpose of a Feature.

Will this ticket be used to track the development through testing/implementation for everything listed under this feature? And, QA would be expected to test everything listed under the Acceptance Criteria and Edge Cases under this one ticket?

[Nyero2023]

Hi @Nyero2023! This is my first attempt at using GitHub, so please allow me a bit of leniency as I try to understand the purpose of a Feature.

Will this ticket be used to track the development through testing/implementation for everything listed under this feature? And, QA would be expected to test everything listed under the Acceptance Criteria and Edge Cases under this one ticket?

Hi @quakermiss! It's alright, I totally understand.

Yeah, this ticket will be used to track the development of this feature. The QA team is expected to test everything listed under the AC and Edge Cases, but in case I miss an important task or anything related to the QA team, please feel free to add or bring it to my notice. Thank you!

[quakermiss]

Thanks, @Nyero2023 thanks for the clarification. You have done an excellent job in fleshing out this feature! From a testing standpoint, may I make a suggestion? Imho, categorically, we need to break down large features such as these into individual subtasks.

My concern is that testing and notes may become unmanageable and confusing quickly. This also will allow different testers to test pieces of extensive features, and potentially the same on the dev side: have multiple devs working concurrently.

Please review this document for details of how I'd break down this feature into 19 sub-tasks or tickets (not sure what we'd call them?). https://docs.google.com/document/d/1_q3XlsSkOIkcMnO_Ro_-zozv5PgLOYj16FFzeQJtd4M/edit

Acceptance Criteria:

• 1i would be tested in sub-tasks (tickets).
• Same with 1ii through 1iv.
• Total of 6 for 1
• 2 through 8 would be tested in sub-tasks. - Sub-Total of 13

Edge Cases:

• 9 through 14 would be tested in sub-tasks. - Sub-Total of 6 - TOTAL 19

Please let me know if I'm off base or if we need to have a brainstorming session(s) to ensure we're all (QAs, PMs, UX/UI, devs, and Graphic Designers).

[quakermiss]

@Nyero2023 The links did not work due to my lack of experience with this tool. UPDATE: I figured out there are reserved characters, which I have now fixed. The link works now. Listed below, too.

^^^ Please see the Shared/Quality Assurance folder Feature 1.2 - Group Creation and Organizational Structuring 198 doc

[Nyero2023]

@quakermiss Well!! I understand what you are saying here. if we are to treat each of the subtasks as issues or tickets, that means we will have a total of 19 issues to create, which is a lot to track and manage. I'm thinking of using a checklist format where the team can tick off any subtasks they've worked on or completed tests on, does it make any sense? Which other better way can we track the subtasks related to feature 1.2 and other features?

I will be using the doc as a guide to create these subtasks.

[quakermiss]

@Nyero2023 Thanks for your feedback! It does make sense from the Project Manager's point of view. However, from a testing standpoint, checking off a box to show that something has been tested is not standard operating procedure. There's a lot more to testing than that.

For example, when something fails (and it often does on a new project multiple times), there are repro steps, screenshots, and other information, such as OS and browser version, so the dev can delve into the issue(s).

Maybe I'm being overly concerned or perhaps this project does not need the level of detail I'm used to providing?

I think it would be prudent to have the key players talk about what the requirements and expectations are, at least from a testing standpoint. If only a checkbox is needed, then maybe my concern is a moot point. Thoughts?

[Nyero2023]

@quakermiss Okay, I see! As you mentioned, let's have every key stakeholder meet to discuss and brainstorm on this topic. Tomorrow would be great. From what you just said, I think there may be a need to create a QA project or a separate board for the QA team since your work involves so many details.

[quakermiss]

@Nyero2023 I am definitely amenable to whatever the team feels is necessary. The sooner the better so we're all on the same page to avoid rework.

I'm available tomorrow and/or mostly through the 31st. I'm thinking @mufniarz would need to set up a special Zoom meeting and invite the specific key players? Maybe we can chat in board-of-advisors in Slack to coordinate. Whatever works best for everyone. Thanks!

[Nyero2023]

@quakermiss Okay! That sounds good. I hope Marcin can follow our chat on here.

Maybe I didn't mention it to you when responding to your messages, but Marcin and I discussed that the Group Creation for this feature will be the focus for now, and the other part which is the Organizational Structuring will be attended to later, I think it would be a lot of work to implement the Organizational Structuring functionality from a research, product, dev and design standpoint. Just decided to share this. I am looking forward to the brainstorming session with key players or stakeholders though.

[mufniarz]

@Nyero2023 @quakermiss Can we move these types of discussions to Slack. It's just easier to keep everyone in the loop, as not everyone gets notified when you're commenting on a specific ticket. Moreover this comment thread should be specific to this ticket and not the our process. I'm going to move this conversation to Slack. Thanks all!