We have about 150 internal users on an installation with about 400 projects. All of them are "internal", e.g open to access for all of the users.
When new users start using GitLab, they are always surprised that there are so few projects and so little activity. That is because when they choose to "explore", they end up on "trending projects", which is empty. It shows only public projects, of which there are none.
It would be great if trending projects would include internal projects, for internal users.
Proposal
We have installed our internal GitLab to try to recreate some of the dynamics of GitHub, on an internal site. Project visibility is an important part of that.
INSERT INTO #{table_name} (project_id) SELECT project_id FROM notes INNER JOIN projects ON projects.id = notes.project_id WHERE notes.created_at >= #{timestamp} AND notes.system IS FALSE AND projects.visibility_level = #{Gitlab::VisibilityLevel::PUBLIC} GROUP BY project_id ORDER BY count(*) DESC LIMIT #{PROJECTS_LIMIT};
The problem with this is the PROJECTS_LIMIT at the end. We'd need to do this twice: once for public projects, and once for public + internal, to avoid having the same problem in reverse (if all of the trending projects on an instance are internal, but there are public projects too, then anonymous users should still see public trending projects when they view the list).
Implementation Guide
Explore > Projects > Trending should list all projects a user has access to, including internal and private projects. Private projects should only be listed if the user is a member of these projects. Internal projects should be listed if the user is a member of these projects, or if they have access to see them because they are an internal user.
Unauthenticated users should see public projects listed, if available
If no projects are available, users should see an empty state
Note: The focus of this issue is merely to include internal and private projects in the calculations. Updating the algorithm that determines what is trending is tackled in #442693.
@elygre Thanks for your feedback. That makes sense to me
Mark Fletcherchanged title from "Trending issues" should include internal projects, for internal users to "Trending projects" should include internal projects, for internal users
changed title from "Trending issues" should include internal projects, for internal users to "Trending projects" should include internal projects, for internal users
We would like to do the same for inner sourcing in our company. It would be great for internal users to be able to discover internal trending projects.
@ivan.fourie That is our exact use case, too. 150 internal users using GitLab for inner sourcing; only about 10 external users with access to specific projects.
Yes the scenario is:
As a new Internal user, I want see trending internal projects so that I can discover what internal projects are popular in my organisation.
Current experience:
When an internal users logs on for the first time, the welcome landing page gives them the option to explore projects stating that a number of projects visible to them (in our case there are several, none of them are public). When the user clicks Explore the first page that comes up is Trending and it shows "No projects found." For new users not entirely familiar with the product, it appears that something is wrong.
Expected experience:
When the internal user clicks on explore on the welcome landing page after seeing they have a number of projects visible to them as an internal user, the trending page displays trending internal as well as public (if available) projects.
As an organisation we would like to promote inner sourcing with one of the objectives being discovery of popular projects that are very active.
@tauriedavis I'm not sure what the criteria are for the trending list to be populated. On my private server with a number of projects most of which are private but some of which are public, I've found that committing data to projects (both public and private) does nothing to have them show up as trending. Now, there is not a lot going on with that server, but knowing what triggers things showing up would help us figure out what is going on and why multiple people are seeing (or in this case not seeing) the same thing.
INSERT INTO #{table_name} (project_id) SELECT project_id FROM notes INNER JOIN projects ON projects.id = notes.project_id WHERE notes.created_at >= #{timestamp} AND notes.system IS FALSE AND projects.visibility_level = #{Gitlab::VisibilityLevel::PUBLIC} GROUP BY project_id ORDER BY count(*) DESC LIMIT #{PROJECTS_LIMIT};
The key line seems to be this projects.visibility_level = #{Gitlab::VisibilityLevel::PUBLIC}. It would be great if this could support internal projects as well.
The problem with this is the PROJECTS_LIMIT at the end. We'd need to do this twice: once for public projects, and once for public + internal, to avoid having the same problem in reverse (if all of the trending projects on an instance are internal, but there are public projects too, then anonymous users should still see public trending projects when they view the list).
@philcamillo given how i've seen issues moving across releases, I wouldn't want to commit to any sooner than 9.4 - so August time frame, if the customer know it's coming by then, is that helpful to you?
@jramsay The visibility picker on the Trending page doesn't actually do anything useful; we only consider Public projects to calculate "Trending projects", so the Internal and Private lists are just empty. We would need to calculate both public and internal trending projects, and make sure we only show the internal ones to authenticated users.
@DouweM thanks for clarifying that. Trending private projects would be different per user and doesn't really make sense. So I'd propose actually adding an empty state if the user filters to Private projects explaining that trending projects aren't calculated for private projects.
@lohrc I think we have scheduled for design in %16.9, but I don't think there is any design work to be done here. I think the proposal is good as it stands. LMK if anything additional is needed.
@mnichols1 I have added a few points to the proposal, but was wondering if we have an empty state for this tab for the case that no projects are available? This could be the case for an unauthenticated user accessing the tab, but the projects available would only be internal or private. In that case nothing would be listed. If that is not available, we should add it, but it could be in a separate issue. For the rest, I'll line this up for backend refinement. It's possible that we hit performance limitations for this improvement. If that is the case, we might need to wait until the Organization is available.