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.
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!):
each time remove the old fork - maybe easiest because it does not need much understanding, but it maybe feels a little destructive and does avoid to deepen understanding of git
if your fork branch is not up to date, you can see it, and we can tell you how to update - definitely the best practice, but might be confusing and deterring for people who are not interested in getting deep into git
Find a way to avoid forking at all because the above means take too much of time.
Based upon the current guide, what are your general suggestions for further developing the guide? Feel free to also add related ideas if you have complementary thoughts about how to create a process that avoids/tackles outdated branches (for those who have related experiences). This is a little two-sided since we are asking people who use the guide, but at the same time we ask anyone with gitlab experience for ideas about how to mitigate the current UI issues the simplest way.
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 )