Sharing information between parent project and sub projects

[anishTP]

Overview

Linking projects to a parent project helps organise and aggregate audiences within an organisation account. Right now this link is superficial, i.e, a sub project is made accessible to a parent project and vice-versa through a project card listed within the project page. No information is shared between parent and sub-projects beyond this. The need for creating multiple projects with a single parent arises when a new topic or series is being curated for a audience segment within the account. This helps in better audience targeting and engagement metrics across different topics within an account.

Proposal

A feature that allows updates from the parent project to reach all participants within child projects (de-duplicated list). This helps target the specific audience in case of new projects relevant to the audience. All updates that are sent out from the child project go out only to the participants of that project, i.e., zoom links and other links that are relevant only to that project.

[jace]

Which way should roles flow?

• [ ] crew in project -> crew in sub-project
• [ ] participant in project -> participant in sub-project
• [ ] crew in sub-project -> crew in project
• [ ] participant in sub-project -> participant in project

Sub-projects originated as a way to independently curate tracks in a large event, allowing editors to exercise full control over their sub-project, but showing a consolidated schedule in the main project and aggregating an audience in the main project.

[jace]

Sub-projects are also hidden on the account landing page as they are assumed to only be relevant within a main project.

[anishTP]

Which way should roles flow?

• [X] crew in project -> crew in sub-project
• [ ] participant in project -> participant in sub-project
• [ ] crew in sub-project -> crew in project
• [X] participant in sub-project -> participant in project

Sub-projects originated as a way to independently curate tracks in a large event, allowing editors to exercise full control over their sub-project, but showing a consolidated schedule in the main project and aggregating an audience in the main project.

The use case of curating separate events/projects for a large project makes it a valid reason to have participants of the sub-project listed as participants of the main project. Right now there is no consequence to adding any project as a parent project. But giving the parent project crew the power to communicate to sub-project audience will ensure fair usage of this feature.

[jace]

This should be doable, although it recasts main projects as a category, rather than as a main entry point. Which brings up a question:

Should the main project be allowed to have its own registrations?

When a sub-project participant receives an update and visits the main project where the update is, what do they see in the registration box?

• [ ] An option to register for the main project
• [ ] A notice that registrations are not allowed
• [ ] A list of sub-projects they're participants in (could be large)
• [ ] Just a notice that they're a participant from elsewhere

[jace]

IMO the main+sub-project hierarchy is confusingly similar to the account+project hierarchy, so why not just move those projects to a new account?

[anishTP]

This should be doable, although it recasts main projects as a category, rather than as a main entry point. Which brings up a question:

Should the main project be allowed to have its own registrations?

When a sub-project participant receives an update and visits the main project where the update is, what do they see in the registration box?

• [x] An option to register for the main project
• [ ] A notice that registrations are not allowed
• [ ] A list of sub-projects they're participants in (could be large)
• [ ] Just a notice that they're a participant from elsewhere

The main project should have registrations open to anyone coming in from the sub-project. The sub-project becomes more like an entry point for users into the main project.

Total list of project participants = participants in parent project + participants in all sub-projects

Updates sent from the parent project will reach this total number of participants even if they are registered or not. A separate registration in the parent project is useful mostly for deciding if its time to move that audience into a new account. Making a new account for every large project will become tedious and can result in fragmentation of the audience.

[jace]

We cannot have the participant role coming from two places. It makes role discovery inefficient, causing page load to be very slow. The past few weeks have gone into consolidation -- AccountMembership in #2005 represents both admins and followers. The next change will be to merge Rsvp into ProjectMembership so that projects have a single source for roles.

IMO, there is insufficient distinction here between account+project and main-project+sub-project, especially from the participant's point of view.

There was a use-case for sub-projects in large in-person events with restricted access. Unless there is a further case for that business models, sub-project support should be removed.