Merge explore users with explore orgs #12649

Open
opened 2025-11-02 10:17:07 -06:00 by GiteaMirror · 6 comments
Owner

Originally created by @delvh on GitHub (Mar 14, 2024).

Feature Description

I have never understood why Gitea splits the explore page into three parts:
repos, users, orgs.
Wouldn't it suffice to have repos, users (and orgs being a part of users)?
(Alternatively, the distinction could also be repos, owner, however I don't think that's any better either as owner is only a code-internal concept we haven't communicated to our end users, and orgs are on all accounts users too)

In the end, if a user searches for another user, they likely don't know if they are explicitly looking for a user or an organization, they most likely only know the username they are looking for.
As such, it would be more user-friendly to merge the two pages into one that shows both users and orgs simultaneously.

If there is interest, we can still add a toggle later on, that when activated only searches for users XOR orgs, but not both.
But as a first step, I'd suggest merging both explore pages together and getting rid of the (unnecessary) distinction.

Screenshots

No response

Originally created by @delvh on GitHub (Mar 14, 2024). ### Feature Description I have never understood why Gitea splits the explore page into three parts: `repos, users, orgs`. Wouldn't it suffice to have `repos, users` (and `orgs` being a part of `users`)? (Alternatively, the distinction could also be `repos, owner`, however I don't think that's any better either as owner is only a code-internal concept we haven't communicated to our end users, and orgs are on all accounts users too) In the end, if a user searches for another user, they likely don't know if they are explicitly looking for a user or an organization, they most likely only know the username they are looking for. As such, it would be more user-friendly to merge the two pages into one that shows both users and orgs simultaneously. If there is interest, we can still add a toggle later on, that when activated only searches for users XOR orgs, but not both. But as a first step, I'd suggest merging both explore pages together and getting rid of the (unnecessary) distinction. ### Screenshots _No response_
GiteaMirror added the type/proposal label 2025-11-02 10:17:07 -06:00
Author
Owner

@denyskon commented on GitHub (Mar 15, 2024):

The underlying code and templates are absolutely the same, so it would make sense.

@denyskon commented on GitHub (Mar 15, 2024): The underlying code and templates are absolutely the same, so it would make sense.
Author
Owner

@delvh commented on GitHub (Mar 15, 2024):

Mostly.
While working on it, I've already noticed one inconsistency between org and user explore pages that borders on buggy behavior that I'll fix at the same time.

@delvh commented on GitHub (Mar 15, 2024): Mostly. While working on it, I've already noticed one inconsistency between org and user explore pages that borders on buggy behavior that I'll fix at the same time.
Author
Owner

@delvh commented on GitHub (Mar 15, 2024):

Correction: Two bugs.

@delvh commented on GitHub (Mar 15, 2024): Correction: Two bugs.
Author
Owner

@delvh commented on GitHub (Mar 15, 2024):

@lunny moving the discussion here.

How can it be more confusing to have both in the same place?
It is completely confusing as it is now: I need to know if I'm looking for a user or an organization which I often don't know when looking at the explore page.
I agree, we can improve the display to make it more obvious who is a user, and who is an organization.
Still, I think it is plain wrong to separate them as we do at the moment.
We can add things like a little icon whether someone is a person or an organization, or filter by users/orgs only, but on the same page.

Additionally, I'd like to keep the refactoring clean, so that we add in these enhancements afterward.
What do you think?

And after all, /explore/users already behaves differently than /explore/organizations which is making me crazy.
See the PR description for what I mean.

@delvh commented on GitHub (Mar 15, 2024): @lunny moving the discussion here. How can it be more confusing to have both in the same place? It is completely confusing as it is **now**: I need to know if I'm looking for a user or an organization which I often don't know when looking at the explore page. I agree, we can improve the display to make it more obvious who is a user, and who is an organization. Still, I think it is plain wrong to separate them as we do at the moment. We can add things like a little icon whether someone is a person or an organization, or filter by `users/orgs only`, but on the same page. Additionally, I'd like to keep the refactoring clean, so that we add in these enhancements afterward. What do you think? And after all, `/explore/users` already behaves differently than `/explore/organizations` which is making me crazy. See the PR description for what I mean.
Author
Owner

@silverwind commented on GitHub (Mar 15, 2024):

I tend to agree on the part that users and orgs are mostly treated the same. They both share the same primary key (their name). It's a similar situation with issues and pulls, they share the same primary key as well. Many places in Gitea treat issues and pulls the same, so I think it makes sense to clean this up for user/org as well.

@silverwind commented on GitHub (Mar 15, 2024): I tend to agree on the part that users and orgs are mostly treated the same. They both share the same primary key (their name). It's a similar situation with issues and pulls, they share the same primary key as well. Many places in Gitea treat issues and pulls the same, so I think it makes sense to clean this up for user/org as well.
Author
Owner

@lunny commented on GitHub (Mar 16, 2024):

Yes, I think your example is an evidence that I'm right. We have issues and pulls two different UI even though they shared the part of database. Only fewer places we will mix them.(Only milestones if I'm not wrong)

I still think they are different and we may encounter unresolvable conflicts after merging the two pages. This will become a limitation about how this page is being improved.

@lunny commented on GitHub (Mar 16, 2024): Yes, I think your example is an evidence that I'm right. We have issues and pulls two different UI even though they shared the part of database. Only fewer places we will mix them.(Only milestones if I'm not wrong) I still think they are different and we may encounter unresolvable conflicts after merging the two pages. This will become a limitation about how this page is being improved.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/gitea#12649