No PR button in LixFloat after direct pushes

[NiklasBuchfink]

Maintainers can push directly, they don't need to open a PR

[linear[bot]]

FINK-11 No PR button in LitFloat after direct pushes

[NiklasBuchfink]

@felix.haeberle You raised this issue.

It is complicated to resolve this:

1. If you are the repo's owner and your repo is not a fork, there will be no PR button in the LixFloat.
2. Fink expects all repos that are forks to open PRs back to the parent repo. This is based on the PR workflow where fork first and contribute back.
3. Tracking the flow from the parent repo to pr and seems unreliable. If you reopen your fork directly and want to open a PR, users have to use GitHub for that.

Possible proposals

1. Atm, if you fork should diverge from the parent, you can just ignore the fork button and continue.
2. The alternative would be to flag a repo for inlang apps that it should diverge. Atm this is only needed for Fink as it is the only app with PR workflow from the browser, so save this to the local storage.
3. Introducing a different process where users have to proactively open forks with the risk of outdated and unmerged forks.

IMO 2. is the way to go for now. Let the 2% flag their repo in the settings and force the 98% to use PRs non-techs need to learn this process. In the long run, we need those flags in the SDK and redesign the pull request flow in a way that users don't need to think about it because it happens in the background.

[NiklasBuchfink]

After a few more thoughts.

Ideal UX

If I'm part of the team, I open the project, make my changes and it should be commited, when I'm done. (To support autosaving, these changes are collected and commited, when the user is done. The lix server might help with that in the future. Also for live collaboration)

I just open the file, make my changes and click request changes, if I'm not part of the team. The team is notified and can decide to add this changes. (fork + pr workflow in the background)

If I want this file to diverge, I want to click copy. Maybe I we can offer features like, "get updates from the original" or "merge documents", but since the copy action was done, we don't assume PRs anymore and users explicitly state that the copy should be updated or merged with main. (same forking + pr workflow as well, but with explicit user actions)

[janfjohannes]

@niklas.buchfink is this not partially

solved by our conditional modal that allows deactivating notifications about diverging forks? if i activate this it is a frok that should diverge, if not i want to usually contribute back eventually.

[janfjohannes]

i always see there are these options after making changes in fink:

• push the changes back to the same branch
• submit for review: if it is a fork, select if on my fork or for the upstream

[NiklasBuchfink]

@jan.johannes You are right; we can use the tick from the modal as a condition for this flow 👍

The "Ideal UX" I illustrated above is an idea of hiding much of the git-specific workflows and terms from non-technical users and creating something they can understand. Does this make sense for an app contribution workflow for non-techs (in the long term)?

[NiklasBuchfink]

I implement the suggested behaviour that no pull request status is displayed in the LixFloat if the user has ticked to deactivate notifications about diverging forks.