Related projects section

[anishTP]

Feature overview

The project page is semantically related to a folder inside a file explorer. It houses content of a certain kind in the form of submissions and all other contextual information. This 'folder' is located within an account that has many such 'folders'. Some of them are related to each more than others. Currently there is no means of associating the projects/folders that have related content. Project pages are more or less an endpoint on the website as far as content discovery is concerned. However users who land on a project page are going to be interested in other projects that have related content. This brings up the need for displaying information about related projects in the project landing page.

Information Hierarchy

As far as information hierarchy on the project page is concerned a 'related project' section would come lower down the hierarchy when compared to the other project-specific information on the page. Hence it reasonable to assume that this section would appear lower down the page. As a secondary point of navigation, all related project can be listed inside a separate tab in the sub-navbar on the project page. The pieces of information from the related projects that are of interest to the user are mostly present in the project card component. So, this component can be reused for the purpose of listing all related projects in this section.

Affordances

Users The 'related projects' section enables the user to navigate to various project pages listed in this section. In case the number of related projects exceeds four, 'view all' button takes the user to the 'related projects' page where all related projects will be visible.

Editorial The project editor can choose from any public accounts, the projects they wish to list under the 'related projects' section. The projects will be displayed in the order in which they are listed by the editor. These actions will be available to the editor in the projects settings menu.

[jace]

Folders are a relatively poor form of categorization and should be avoided:

1. Folders imply a single exclusive container in which an item can exist.
2. Ergo, items are invisible outside of their folder.
3. Relocating an item will break its discovery.
4. If folders appear in a URL, relocating or renaming will also break permalinks.
5. The exclusivity requires pre-planned and rigid hierarchies. These do not age well. There's a famous example for this, the Dewey Decimal system used by libraries.

There are better ways to organize content, discussed in #1421.

[anishTP]

1. This was based on the discussion on the telegram channel about sub-projects. The overview was connecting back to this conversation context: 'Think of projects as just category folders. These three terms are interchangeable in our use case when projects do not have dates: project, folder & category'. I've called it related-projects instead of sub-projects to avoid another level of hierarchy beyond account>projects. This helps to connect different projects across accounts and topics instead of having a strict hierarchy based on topic or activity.
2. There is no relocation required. Only links to related projects either past or upcoming.

[jace]

My bad, I misread the implication of the term "folder" here. Nevertheless, #1421 discusses how this can be achieved. Community editors cannot be expected to list related related projects as an operational flow -- if there was existing intent to do this, they would have already been doing this in the project description, as we've seen for listing sponsors before formal support was added.

[anishTP]

Additional context: An operational flow that was requested was to have sub-projects within a parent project. This was mainly to avoid creating accounts as line-extensions of existing accounts. But sub-projects implies some kind of hierarchy in the chain - account>project>sub-project. And it also opens up issues of participant information sharing between parent and sub-projects. The sub-project in its current implementation is more of a navigational link between projects than one where there is information sharing. Hence, it makes more sense to rename this to related projects and allow editors to list projects that are related by topic or format. Having content tagging in place is no doubt a better way to do this. But it would be better to have manual workflow in place that renders the content in a proper hierarchy before we get the automated version in place.

[jace]

Sub-projects were introduced as a way to isolate the workspace for track editors in a multi-track event. This requirement faded before Funnel had participant management, and Boxoffice never used it, so sub-projects remain under-specced. #2006 proposes to use sub-projects for participant isolation, removing the many redundant models introduced for Boxoffice.

Sub-projects are not a suitable mechanism for topic categorisation. Since a sub-project can only have one parent project, the parent project is effectively a folder. This makes sub-projects unsuitable for expressing relatedness. They can only be used to represent exclusive containment -- such as tracks within a larger event.

[anishTP]

Issue: The current implementation of sub-projects allows any number of projects to link to a project as a parent. However the parent project lists only one child as a 'Related event'. Inside parent project page(with 3 child projects):

Inside child project

Instances that are exclusive containment would also include projects that are made for session rehearsals, workshops that need participant isolation, pre-event seminars or meetups etc? In such cases there is no difference in having them as a separate project or listing them as a sub-project since participant isolation is the main requirement. But linking them to a parent does make sense.

[jace]

However the parent project lists only one child as a 'Related event'

This is a bug. Since sub-projects were intended to represent tracks, all sub-projects should be listed with equal priority, ordered by date if they start at different times. Pre-events were not originally expected, but if they are part of the use case now, they should be de-prioritised in display. I'm not comfortable adding pre-events as an expected use case though as it will lead to abuse of sub-projects for topic categorisation.

Instances that are exclusive containment would also include projects that are made for session rehearsals, workshops that need participant isolation, pre-event seminars or meetups etc? In such cases there is no difference in having them as a separate project or listing them as a sub-project since participant isolation is the main requirement. But linking them to a parent does make sense.

Yes. In addition, marking a project as a sub-project should hide it from the account's list of projects (expected current behaviour; if deviating, that's a bug). This design could be revised to instead show the parent project as a panel with a header, with the sub-projects listed as cards within.