Based upon previous discussions, you may know that we created a guide for casual contributors, to lower the entry barrier to contributions in our Docs, and especially to enable people without connections to git to contribute without much efforts.
However, originally identified by @sampsonf , the user interface of GitLab has changed a lot, and thus, it can be questioned if the original goals of the guide can still be achieved, if the original target audience is still realistic, and even if so, how to achieve the goals to enable the original target audience to contribute easily.
This is why we ask the people who use such a guide: how to proceed?
Generally, if you are interested in any way to contribute to the Docs, even if only on a casual basis, you are right here and your incentives in any direction are welcome! This topic is for you.
Please feel free to let us know about your thoughts and incentives for any of the following questions but also complementary ideas (with regards to the discussions of here and here, but also the original discussions of 2021/22 that led to the concept of the guide):
- With the current GitLab user interface, are you interested at all to keep using it for casual contributions?
- If yes, are you interested to only get your contribution done as quick and as simple as possible without being bothered by “why is it the way it is”, or do you want to get some understanding about git or to even start implementing its best practices, even if it adds some steps? An example for the latter would be to create and use your own branches, as you can see it currently in the guide.
- Based upon the current guide, do you have any general suggestions or needs?
- Currently, we have identified the following possibilities - which would you prefer?
→ 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
→ Please try to find a way to avoid forking and such at all because the above means take too much time or for other reasons so that I cannot contribute that way.
- With regards to the 4th question, do you maybe have other ideas or thoughts about how to tailor the casual contribution process and its guide in GitLab to satisfy your demand?
- Anything else you have in mind! Do we maybe ask the wrong questions? We are open to everything The only limit that we have to set at the moment is git: too many of Fedora’s Special Interest Groups and Working Groups depend on the use of git when maintaining their respective Docs, directly or indirectly.
The underlying questions for us are: who is the current (realistic) target audience? What is their demand? How to achieve satisfying this demand?
There have been changes both in GitLab and maybe also in the audience that uses this guide, whereas the latter might be influenced by the first (obviously, one related question is if it is even possible to create a GitLab-based process that is interesting for people without git-preferences). So, here we go, let us know
Many thanks to @hankuoffroad who took the initiative to start adjusting the guide to changed demands and to reveal that we have to also re-consider the targeted audience.
Looking forward to your thoughts,