Disable repo units by default #1318
Labels
No Label
bug
Codeberg
contribution welcome
docs
duplicate
enhancement
infrastructure
legal
licence / ToS
public relations
question
s/Gitea/Forgejo
s/Pages
s/Weblate
s/Woodpecker
security
service
spam
upstream
wontfix
No Milestone
No Assignees
6 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Codeberg/Community#1318
Loading…
Reference in New Issue
There is no content yet.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may exist for a short time before cleaning up, in most cases it CANNOT be undone. Continue?
Comment
Currently, all repo units are enabled by default. If you browse a new repo, you'll see
However, most of them are probably empty.
I propose to improve the UX for visitors of repos Is the wiki present? Any projects?
I recommend to disable the units by default and make repo admins enable them when they are used (wiki, projects, releases?). Or a better way would actually be to hide them when empty and not actionable (e.g. if you have read access only and the wiki is empty, why show the tab?)
I wonder if disabling repo units would also improve Codeberg's performance?
I don't think so.
Is there any way that this could be done on Codeberg's fork without too much hasle for Forgejo people? I mean, they might not want to do this change.
I remember seeing a more detailed answer on Codeberg's Mastodon post for the same question but I can't find it again.
There's a option for that
DEFAULT_REPO_UNITS, https://forgejo.org/docs/latest/admin/config-cheat-sheet/#repository-repositoryDidn't know about this, thanks!
Maybe we can just make the Releases tab invisible for anyone other than the people in a position to modify it from the main repository page, and then add an indicator saying that this unit is only visible to those people until it actually starts getting used? (And providing a proper error message through the web UI / API, as some third-party programs may try to get files using that endpoint.)
For improving the user experience within Forgejo itself, I see the following options:
A: Repo units without content are hidden to visitors automatically, no need to disable them. A criterion could include: No release / tags. No wiki page. No release. This likely involves larger changes to the codebase, because for performance reasons it requires a cache instead of counting the content at every request. People with permission to act on them (e.g. create releases, projects, wiki pages) always see the tabs.
B: Repo units are hidden by default (using the config suggested above which already exists). However, people with sufficient privilege to enable the repo units see a button in the UI to do so. Again, there are two options: We either display a + button which opens a dropdown (Releases, Projects, WIki). Or, we display each disabled unit after another, but need to find a good indication that these can be enabled (also think of how to label them for accessibility reasons). The single "+" button is likely more convenient for hardcore Forgejo users, because it is less intrusive, but the individual buttons might be more intuitive for new users (but probably larger to design from a UX perspective).
I intuitively prefer option B with Plus-Style dropdown to enable the additional units. Releases, Projects, Wiki, Package Registry and Actions are hidden by default and available in the dropdown.
I would also prefer the option B, but I see the dropdown a bit unnecessary, since that config is already available at the "Settings" of a given repository.
Nevertheless, option B seems to be a better choice here.
I think
Ais way too complicated, and puts too much logic into the presentation layer, thus,Bfeels like both a simpler, and more correct choice. I'd offer a third variant of it: if there are disabled units when an administrator is viewing the repo, show a+sign (or even better, something likeConfigure repo units). It wouldn't be a dropdown, but would simply take one to the repo settings page. We could add an anchor to the "Advanced Settings" section, and take the user directly there.Come to think of it, the entire "Advanced Settings" section is really about repo units, so perhaps changing its name would make it even clearer what it is for? I kinda like "Configure repo units". We can add an explanatory text like there's one for the mirror settings section.
The motivation for the +-button and dropdown style was an easy representation for "See, you can add more tabs". The settings page is already linked, but I think people are not sure that there is more to enable. "Configure repo units" sounds cumbersome to me, but I won't insist on the plus button.
Good spot with the section. I think it would even make sense to declutter the long setting page and consider moving the unit part to a separate page, accessible via the sidebar?
Understood!
Indeed, it is, but explicitly linking to the section where you can enable more units, with a label that makes that clearer would be helpful to, well, make it clear that you can add more tabs!
I just figured that if there's no dropdown, a more descriptive label would help. "+ Add more tabs" or something along those lines would be equally good.
Another reason I'm not a fan of the dropdown is that it duplicates what can be done in Settings, in a more limited way. I'd rather make it easier to both discover the appropriate settings parts, and to use them - no duplication then, and especially not with a more limited feature set.
I like that idea. We can even use sub-pages like in the user settings page (the Actions part of the sidebar, which can be expanded, and then shows two sub-sections), so there's existing precedent for this kind of hierarchical preferences.
Tried to implement this, small complicating factor: Very easy in theory (just gotta check if a user has repository access and add a tooltip), but not consistently (disabling releases won't work because it's also used for the git tags, unless if we dynamically change the "Releases" tab into a "Tags" tab, and there is no package counter in the UI, and we don't know if the Wiki has any content in it)