Wow! That’s great news!! In that case it might be worth to wait before
putting more efforts in this 
If I find a free minute in the next days, I add a box to inform users to
keep an open eye if they have already a fork and that the issue could be
solved soon (to avoid that they waste time), just as interim solution,
and then let’s hope that 15.10. solves our issue.
Very timely indeed. 
Thanks for your heads-up (@py0xc3 @mattdm ).
I’m a half-convert to the new WebIDE when working with GitLab Docs repo. I have made two MRs using WebIDE today. I’m getting used to it.
We expect to see more users joining the casual contributor workflow.
I have added a CAUTION box as interim solution. Hopefully, we can delete it soon 
Commits 8d4ac50c, 01ee8b70, e63d16cb
The published page should be updated in <1 hour.
Hank already identified that the feature was shifted to the 15.11 release, which is to be released tomorrow:
Fetch new upstream contents when fork is behind (#330243) · Issues · GitLab.org / GitLab · GitLab (updated)
15.11 · GitLab.org · GitLab
Sync button not visible in Web IDE beta mode. Until it is activated (maybe 16.0) and we get hands on with the UI and behavior, could we withhold any update on the casual contribution page?
The UI shows how far a fork is behind. But explanation on fork could scare target user groups @py0xc3 had in mind when the original guide was published in 2022.
@py0xc3 what compromise do we need for intended target group? Also you fear the revised procedure step 3 “create a branch” would lead to resignation of contributors. I admit I work on test pilot mode (beta tester) way too long without any feedback from your intended group and users you interacted in Discussion. Please advise.
Indeed, originally, they just changed the topic that it has been released. I absolutely agree on your point that adding more stuff about how to update themselves could be scaring for the targeted users. It becomes more and more they have to understand and to get into…
My fear was, on one hand, that more steps leads more people to refrain from contributing because we wrote the guide originally for people who did not want to deeply get into git but just get their contribution done (this does not imply that this is still the major user group).
On the other hand, if we try to find new compromises that maybe go in other directions than the previous incentives from users, we should involve the community to get incentives (or let least offer the possibility to avoid exclusion- and misunderstanding-based defiance). So what I had in mind was that people gave incentives, and if then something else is implemented, this can lead to some resignation for giving incentives in future if we do not let people know about the “why we do that”. Additionally, inclusion through explaining the “why” might cause more incentives about how to proceed best from the user perspectives.
So this does not mean that your changes are wrong (they definitely fit the current GitLab better than my original version!), and we obviously need to add steps now, but that we should try to involve the people who work with it. We might not reach all, but some, and they maybe have some incentives about how to proceed with the current GitLab circumstances. I guess people who reject from any contribution on Fedora discussions are also unlikely to actively contribute in Docs. We can only try to propagate discussions on our channels.
There are no doubts that at the moment, there is no chance but to find “bad compromises” with the current GitLab UI. So if there is some interest from people who use the guide regularly (maybe @sampsonf ?) we could maybe start by asking them questions like:
→ with the updated guide that shall balance parts of the issues in GitLab, do you prefer to just get contributions done as quick and easy as possible, or do you also use the guide to get understandings of git? (e.g., implement best practices with adding steps to get your own branch). Or both?
→ what solution would you prefer for the current circumstances of GitLab? I think we have currently these opportunities (feel free to add more ideas!):
If that is ok for your @hankuoffroad , we could create a new topic so that people in the forums see that we ask for help in this respect. If you want, I can open it later today or tomorrow, but you can also open it yourself if you want. We can then put all points together.
The other points you made in the GitLab ticket are also reasonable and maybe things have a little changed, and especially in the current circumstances, it is possible that we need to focus on those who have some interest in getting into git.
I know this is also a bit a tautology, but finally we have no chance but defining the target group by those who respond and say “hey I use it, this is what I would like”, with the assumption that those not answering are also unlikely to do much contributions.
Btw, an addition could be to add a INFO box to the top of the guide to let people know that we currently seek incentives? So with a link to the new topic if we create one?
(Supplement for those who keep watching the AI topic: this post is not AI generated, I promise 
)
No, not at all. It is worth discussing before making a move or suggesting a change.
Could you create a new thread to engage with Web IDE users based on your questions?
Of course
The follow-up topic is:
Long-awaited update fork button in GitLab is here with 15.11 release on 22 April.
I checked it on 24 April today while I was working on my fork. See screenshot below.
