UX issues around disabled pull mirrors feature #1005

neuschaefer commented 2023年04月28日 10:05:24 +02:00

This is related to #568 and #760 but not quite a duplicate. I know now that pull mirrors have been disabled, but how I got there could be improved.

My overall first impression of codeberg is pretty positive, though!

The journey

Yesterday I decided to set up one of my projects on Codeberg. The repo list in UI shows a category "mirrors", suggesting that such a thing exists.

screenshot showing "mirrors" category

After creating a repo, I checked the settings page, and saw that it mentions mirroring:

screenshow showing mirroring options in the settings page

Set up your project to automatically push and/or pull changes to/from another repository. Branches, tags, and commits will be synced automatically. 🔗 How do I mirror repositories?

So, it says that mirrors can pull or push. Push mirrors can be configured right there, but pull mirrors have no controls. The link points to the relevant section in the official Gitea documentation, which has a step-by-step guide on how to set up a pull mirror, all very nice.

But the checkbox it promises simply does not exist.

screenshow of the migration wizard

At this point, I suspected a bug, and checked the bug tracker. The word "mirror" did not show any open issues that applied to my problem, so I was about to write one, but I also check the closed issues, where I found #760. This is when I finally learned that pull mirrors had been disabled intentionally.

Conclusion

It took me way too long to discover that the pull mirrors feature exists and is not broken, but is disabled intentionally. The fact that there are duplicates of #568 suggests that I'm not alone with this UX issue.

There are several points along the way where I could have discovered this fact earlier:

• In the repo settings page there could be a box that says "Pull mirrors have been disabled on this instance"
• In the migration wizard, in the place where there would normally be the "This repository will be a mirror" checkbox, there could be a informational alert that informs the user that the option would normally be there, but has been disabled on this instance
• If Codeberg maintained its own copy of the Gitea documentation, it could also document this fact there, but I can see advantages of pointing to the official Gitea documentation instead¹ .

Request

Please implement some UI changes to improve the UX around learning that pull mirrors are disabled. If a UX flow involves the codeberg.org bug tracker, it is IMHO not good enough.

This is related to #568 and #760 but not quite a duplicate. I know now that pull mirrors [have been disabled](https://blog.codeberg.org/mirror-repos-easily-created-consuming-resources-forever.html), but how I got there could be improved. My overall first impression of codeberg is pretty positive, though! ## The journey Yesterday I decided to set up one of my projects on Codeberg. The repo list in UI shows a category "mirrors", suggesting that such a thing exists.  After creating a repo, I checked the settings page, and saw that it mentions mirroring:  > Set up your project to automatically push and/or pull changes to/from another repository. Branches, tags, and commits will be synced automatically. 🔗 How do I mirror repositories? So, it says that mirrors can pull or push. Push mirrors can be configured right there, but pull mirrors have no controls. The link points to the [relevant section](https://docs.gitea.io/en-us/usage/repo-mirror/) in the official Gitea documentation, which has a step-by-step guide on how to set up a pull mirror, all very nice. But the checkbox it promises _simply does not exist_.  At this point, I suspected a bug, and checked the bug tracker. The word "mirror" did not show any _open_ issues that applied to my problem, so I was about to write one, but I also check the closed issues, where I found #760. This is when I finally learned that pull mirrors had been disabled intentionally. ## Conclusion It took me way too long to discover that the pull mirrors feature exists and is not broken, but is disabled intentionally. The fact that there are duplicates of #568 suggests that I'm not alone with this UX issue. There are several points along the way where I could have discovered this fact earlier: - In the repo settings page there could be a box that says "Pull mirrors have been disabled on this instance" - In the migration wizard, in the place where there would normally be the "This repository will be a mirror" checkbox, there could be a informational alert that informs the user that the option would normally be there, but has been disabled on this instance - If Codeberg maintained its own copy of the Gitea documentation, it could also document this fact there, but I can see advantages of pointing to the official Gitea documentation instead[^1]. ## Request Please implement some UI changes to improve the UX around learning that pull mirrors are disabled. If a UX flow involves the codeberg.org bug tracker, it is IMHO not good enough. [^1]: lower maintenance burden; users will only learn Gitea, instead of different, slightly contradictory versions of it.

n0toose commented 2023年04月28日 11:20:12 +02:00

Welcome, nice seeing you around here! It's true that we actually have a lot of inconsistencies like the one you just brought up. I personally spend most of the time working on them (both w/ the Gitea and the Forgejo upstreams) and also try to spend some extra time figuring out how it's not going to be a problem again (e.g. rebasing the same commits over and over again, when upstream would accept such a patch).

It took me way too long to discover that the pull mirrors feature exists and is not broken, but is disabled intentionally.

In the repo settings page there could be a box that says "Pull mirrors have been disabled on this instance"

In the migration wizard, in the place where there would normally be the "This repository will be a mirror" checkbox, there could be a informational alert that informs the user that the option would normally be there, but has been disabled on this instance

Excellent recommendations. This is actually a setting that can be enabled or disabled in the config (aka. something that is built in Gitea (and Forgejo) itself and not something that we just patched away in our fork, maintaining a fork that mostly consists of branding-related changes is enough trouble already), and we can make the UI behave differently depending on whether those settings are enabled or disabled, so this shouldn't be extraordinarily difficult to implement.

Being explicit (as in, not just hiding the boxes away but being transparent to the user) about this feature being disabled is also super important.

lower maintenance burden; users will only learn Gitea, instead of different, slightly contradictory versions of it. https://docs.codeberg.org/

Just something to add: Many users actually use Codeberg as some sort of a gateway to the whole Gitea / Forgejo ecosystem, and heavily depend on the documentation that we link in our footer too.

Welcome, nice seeing you around here! It's true that we actually have a lot of inconsistencies like the one you just brought up. I personally spend most of the time working on them (both w/ the Gitea and the Forgejo upstreams) and also try to spend some extra time figuring out how it's not going to be a problem again (e.g. rebasing the same commits over and over again, when upstream would accept such a patch). > It took me way too long to discover that the pull mirrors feature exists and is not broken, but is disabled intentionally. > In the repo settings page there could be a box that says "Pull mirrors have been disabled on this instance" > In the migration wizard, in the place where there would normally be the "This repository will be a mirror" checkbox, there could be a informational alert that informs the user that the option would normally be there, but has been disabled on this instance Excellent recommendations. This is actually a setting that can be enabled or disabled in the config (aka. something that is built in Gitea (and Forgejo) itself and not something that we just patched away [in our fork](https://codeberg.org/codeberg/forgejo), maintaining a fork that mostly consists of branding-related changes is enough trouble already), and we can make the UI behave differently depending on whether those settings are enabled or disabled, so this shouldn't be extraordinarily difficult to implement. Being explicit (as in, not just hiding the boxes away but being *transparent* to the user) about this feature being disabled is also super important. > lower maintenance burden; users will only learn Gitea, instead of different, slightly contradictory versions of it. https://docs.codeberg.org/ Just something to add: Many users actually use Codeberg as some sort of a gateway to the whole Gitea / Forgejo ecosystem, and heavily depend on the [documentation](https://docs.codeberg.org/) that we link in our footer too.

n0toose commented 2023年04月30日 00:00:48 +02:00

Upstream PR: https://github.com/go-gitea/gitea/pull/24433

This change has taken me precisely 100 minutes so far today. (Figuring out how all of this works, remembering that you can't actually modify anything involving pull mirrors right now and particularly trying to foresee every single edge case was a hard task.)

I will continue working on it later.

Upstream PR: https://github.com/go-gitea/gitea/pull/24433 This change has taken me precisely 100 minutes so far today. (Figuring out how all of this works, remembering that you can't actually modify anything involving pull mirrors right now and particularly trying to foresee every single edge case was a hard task.) I will continue working on it later.

n0toose commented 2023年04月30日 00:03:40 +02:00

In the migration wizard, in the place where there would normally be the "This repository will be a mirror" checkbox, there could be a informational alert that informs the user that the option would normally be there, but has been disabled on this instance

This recommendation is great, but the PR that I just opened does not address this. However, that PR is probably/hopefully a great point of reference, if someone else wants to work on it.

It may be a good idea to mention that pull mirrors cannot be created at a later stage too.

> In the migration wizard, in the place where there would normally be the "This repository will be a mirror" checkbox, there could be a informational alert that informs the user that the option would normally be there, but has been disabled on this instance This recommendation is great, but the PR that I just opened **does *not* address this**. However, that PR is probably/hopefully a great point of reference, if someone else wants to work on it. It may be a good idea to mention that pull mirrors cannot be created at a later stage too.

n0toose commented 2023年05月29日 11:49:35 +02:00

Hi. This took a lot of time (there were many things that I had to iron out over and over again), but I think I addressed all of your points in the ticket. It is currently in the process of being merged and will land in Gitea 1.20 / Forgejo 1.20 if something super unexpected doesn't happen.

You can find a few screenshots here: https://github.com/go-gitea/gitea/pull/24433#issuecomment-1566118883

If you need me to fix anything else / if the result is not desirable to you, do let me know and I'll try to work on another patch.

Hi. This took a lot of time (there were many things that I had to iron out over and over again), but I think I addressed all of your points in the ticket. It is currently in the process of being merged and will land in Gitea 1.20 / Forgejo 1.20 if something super unexpected doesn't happen. You can find a few screenshots here: https://github.com/go-gitea/gitea/pull/24433#issuecomment-1566118883 If you need me to fix anything else / if the result is not desirable to you, do let me know and I'll try to work on another patch.

n0toose commented 2023年05月29日 11:52:28 +02:00

Yesterday I decided to set up one of my projects on Codeberg. The repo list in UI shows a category "mirrors", suggesting that such a thing exists.

Oh wait, maybe that shouldn't be shown either...

> Yesterday I decided to set up one of my projects on Codeberg. The repo list in UI shows a category "mirrors", suggesting that such a thing exists. Oh wait, maybe that shouldn't be shown either...

n0toose commented 2023年06月03日 01:23:09 +02:00

Oh wait, maybe that shouldn't be shown either...

Small update on this, I tried to fix this 5 days ago and it seems that the component responsible for controlling this is Vue.js-based and very delicate. I eventually dropped this.

I'll close this issue when the "biggest" fix for this problem is merged into Codeberg, then follow up with another ticket that will be reported upstream and under Codeberg/Community with more information.

> Oh wait, maybe that shouldn't be shown either... Small update on this, I tried to fix this 5 days ago and it seems that the component responsible for controlling this is Vue.js-based and very delicate. I eventually dropped this. I'll close this issue when the "biggest" fix for this problem is merged into Codeberg, then follow up with another ticket that will be reported upstream and under Codeberg/Community with more information.

n0toose commented 2023年06月03日 22:31:35 +02:00

Note to self: Affected component is in file web_src/js/components/DashboardRepoList.vue

Note to self: Affected component is in file `web_src/js/components/DashboardRepoList.vue`

n0toose commented 2023年08月10日 21:44:31 +02:00

This was fixed in Forgejo / Gitea v1.20. A further pull request that addresses some additional community feedback from a person that complained about its current form (as including the title of the documentation without clarifying that it is just a title is potentially misleading) as we were still running on v1.19 was also made (https://github.com/go-gitea/gitea/pull/26213) and merged - it will make it to v1.21.

I believe that the core issue at hand has been fixed.

Thank you for your feedback.

image

This was fixed in Forgejo / Gitea v1.20. A further pull request that addresses some additional community feedback from a person that complained about its current form (as including the title of the documentation without clarifying that it is just a title is potentially misleading) as we were still running on v1.19 was also made (https://github.com/go-gitea/gitea/pull/26213) and merged - it will make it to v1.21. I believe that the core issue at hand has been fixed. Thank you for your feedback.