馃帹 Design: Explore possibility of a community page
Problem
As described in Organization rollout - Migrate GitLab into sepa... (#418228), organizations are by design isolated. This means:
- Users who want to contribute to public projects of an Organization have to become members of that project.
- Groups and projects cannot be discovered via a global Explore. The existing Explore functionality will only work within the constraints of the Organization.
This change affects both the public groups and projects hosted by GitLab the company, but also other open source projects. As long as they are assigned to the default Organization, they will remain discoverable via the Explore in the default Organization. Once these groups and projects move into a separate Organization, they will only be discoverable by knowing the URL. Reduced discoverability might lead to a reduction in community contributions for GitLab the company and might make collaboration on open source projects more difficult.
One of the options discussed to potentially mitigate this problem is the possibility of a community page:
We build a community page, that is not pulling data, but is its own database and really just links to public projects. The community page becomes part of the product. In the long-term, we could introduce a setting for public groups and projects to automatically be published on the community page. This would leave control of whether or not someone would like to appear there in the hands of the user. The advantage would be that self-managed public groups and projects could also appear there. This page can already be built independent of the Organization MVC.
Let's use this issue to start exploring the idea of a community page!
Design
The written content below is also summarized in this video, if you prefer that format.
Draft job statements
- When I host an open source project and am looking for contributors, I want my project to be discoverable, so that people can easily find my project and the right task to work on.
- When I am looking for a new open source project, I want to understand a project鈥檚 subject matter and activity level, so I can decide it it鈥檚 a good fit for me to contribute to.
- When I鈥檓 helping to manage a community of contributors, I want to surface important and timely content and messaging to that community, so they feel supported and engaged.
Workflow sketches
We'll primarily focus on the discovery piece of workflow three in this issue.
Wireframe for the "discovery" list
Community page | Expanded issue list |
---|---|
![]() |
![]() |
- Currently suggesting this page could live on about.gitlab.com but, placement is still TBC.
- In future, this page could be more of a "community hub". While we could start with the "explore projects" tab, our intention would be to build out the additional tabs, in future. For example, the content in the current community resources page could perhaps live in a tab on this community page. Another possibility is an events/announcements tab, where we could perhaps promote things like hackathons for people to participate in. For the activity tab: How this would work or look is still TBD (and highly dependent on where this page ultimately lives) but, it could be a way to surface contributors or projects with a lot of contributions/activity, to give this page more of a "real time update"/"social" feel.
- The ability to filter and search projects by language and topic will be important. Additional filters are open for discussion; another suggestion is to filter by top-level group. The appearance of the filters will change depending on location.
- The explore projects page would contain all the projects that are open source and/or looking for contributions. This means both GitLab itself, and the open source projects hosted on GitLab, ideally even those that are hosted on their own instance. How we choose which projects would show up on this page is something that will need further exploration, but it certainly feels like we could highlight partner projects on this list. Project overviews on this page will be updated to include more information by default, including tags for topic and language, and a way to see a sample of available issues so people are able to get an immediate sense of how active the project is, and what kind of issues are available to work on, without leaving this page.
- Example expanded issue list. What's shown here would be the most recent 5 (number TBD) issues in that project, perhaps only those that have a "seeking community contributions" label (or similar) applied. Having issue labels here would be helpful, as well, so there's more immediate context about the issue, too.
- Clicking the "see full issue list" would take you to the project's issue list, potentially filtered by the label, "seeking community contributions" (or similar).
- Again, it would be great if we can surface all public, open source projects that are looking for contributions on this list. But, we could also start with highlighting partner projects for a first pass.
Next steps
The biggest decision that needs to be made is where the community page should live, as that will impact how things work/look/function, as well as which team would be responsible for building the page out. We are currently discussing two possible options for the community page: within the product (for example at gitlab.com/explore) or outside of the product (for example at about.gitlab.com).
Pros/cons for locating it within the product
- Pro is that, once people are within the product, they won't have to leave it to find new projects to contribute to. It might also help mitigate some of the isolation impacts within the product that will be a consequence of introducing cells and organizations, and will ensure a continuity of experience within the product.
- Cons are that all of the existing community contribution resources are on about.gitlab.com so, it is separating the contribution support from the issue list; the content will likely be more difficult to quickly update (meaning it would probably be harder to use it as a comms/social tool); people might have different access to/visibility of projects and issues on the list depending on whether or not they have an existing GitLab account or membership to the projects on the list; and dropping people directly into the GitLab UI might be overwhelming for people who are first time contributors/not familiar with the product.
Pros/cons for locating it outside the product
- Pros are that the content will likely be easier to modify by marketing and other teams on about.gitlab.com and that it means the list would be co-located with the rest of the resources for contributors. Also, since it's outside of the product, it will let people focus on the projects and issues themselves without being distracted by the other features within the product (what's "build"?).
- Con would be that we'd likely still have a gap within the product for exploring projects cross-organizationally. Is that important?
Additional, related work
As part of discussing the community page, we discovered that additional improvements can be made to the existing search/filter experiences in the product. We'll examine those experiences as part of separate issues:
- Improving global search for the contribution workflows will be considered separately as part of Improving global search for organizational work... (#424393).
- Improving the explore page experience will be considered in Add filtering to the explore page (#424392).
There is also some additional feedback on the design that we can look at when we get around to producing higher fidelity designs.
Related links
- Discussion guide
- Dovetail
- Notes doc
- Figma working file
- Current community page on about.gitLab.com
- Activitypub effort