General Questions/Overview

Hi everyone, I don't know if this is the place to post this but I'll try this for now. I'm having a hard time following the instructions on here, as I'm unfamiliar with much of the IT lingo. In addition, I don't really understand which issue to open/follow first.

To clarify, the web 1.0-forum-style GitLab is pretty confusing to me because there's no way to get a clear overview about what to find where. It reminds me of my first internet experiences as a 9-year-old in 2001 where there was no proper search engine and no overview pages with nice design so you had to look for everything by spending hours on forum pages - or encyclopaedias. I don't understand why we have to go back to that version of the internet (since the current web 2.0 is much easier to use and also much easier to get an overview of a topic, for example). I do see its value in developing programs and apps, programming websites etc. where you need to see every single change made to it. But for learning new computer skills it is very confusing. There have been a lot of new forum threads opened recently and it just feels a bit tough to figure out what is important to keep up with the course and what is additional (not crucial) information. I'm trying to keep up but it seems the forking thing still hasn't worked out, for example.

Is there a solution to getting a better overview, where to find what etc.? And could someone clarify what issue to work on first? Maybe @leyla.feiner or @daniel.mcdonald have some good answers on that Thanks!

added Mutual help label

mentioned in issue #22

@manuel.kissoczy Many thanks for this feedback. I think part of the problem you're experiencing is related to @maryam.joseph 's comments, and they derive from the strategy that @daniel.mcdonald and I conceived for this course, namely to drop you (and, to be honest, me most of the time) into the digital deep end as quickly as possible. This actually comes out of previous feedback I've had for teaching digital stuff (where the complaint was that it wasn't hands-on technical enough), so it's a very difficult balance to find. If you're finding there are too many new terms, or too many new issues, then that suggests we still need to refine how we teach this course (and, for example, whether we would offer it to BA entry-leve students in the future), so your comments (and those of @maryam.joseph ) are extremely useful.

With regard specifically to the number of issues in play: partly this is because (as I understand it) GitHub / GitLab work best when there's a single collaborative project in play, and people can quickly see what they need to do. In this course, the collaboration, as it were, is simply running the class; and then you all have your own projects on the side, into which we're all invited to add ideas/comments. That means there's a lot of different issues open. So one thing I've tried to do--and we can all do this--is use the labels more precisely (I've created an "optional" label this morning), and I think we should also all try to close issues as soon as they're no longer hot topics (e.g. @patrick.gut could possibly close #29 (closed) , although he can always either reopen it or add a specific "due date" if he wants to speed up getting particular comments.) Please feel free to do this yourself, for your own issues. (If your own project issue is dormant, for example, you could close and then simply only reopen when you've got additional stuff to say, thus clearing up the issues at least temporarily).

The other thing that would help is a feature that GitHub has but unfortunately the UZH-licensed version of GitLab doesn't, namely the ability to assign a feature to multiple users. The advantage of this is that you could then prioritise according to your own personal assignments, and assume that if your name doesn't appear, it's not your problem. (To see other ways in which you can order the issues to help you, check out the drop-down menu beneath the green "new issue" button on the issues main page: here you can choose to list according to urgency, or date, or assignee, etc: it's another way of helping you keep an overview). Unfortunately we don't have multiple-assignees but that's a feature we could try to lobby UZH to improve.

This all does relate to #16 too: are we simply using GitLab as an alternative to the "Forum" feed on OLAT, and in the process only confusing you further? I would hope not: but then we also get into the problem of using the repositories more actively for our own research/storage: this is what really distinguishes GitLab from OLAT. This is clearly something we need to talk about more on Tuesday 31st, so I'll make sure we leave time for it.

Hope this helps a bit and keep the feedback coming.

I will go ahead and add more feedback. First, thank you @martin.dusinberre for your explanations. Something that could be a major help to me and future confused students: a file where all the words are explained and which process is used for what exactly – Like a "GitLab for dummies". I literally googled "what is a repository" an hour ago.

I think this would overwhelm first year history students because there is also so much new history-lingo to take in, learn and process.

@maryam.joseph Many thanks for continuing to offer feedback. Here's a few thoughts:

i) If it's any consolation, I have experienced your frustrations myself. I can't tell you how many times @daniel.mcdonald had to explain "command line" to me when we first started working together (i.e. Terminal, see your comment in #22 ). I think your frustrations come partly from us not being physically in the classroom any more: in fact, you've already used Terminal several times in this course (especially to set up GitLab), so you do know what it is--you've just forgotten, and it's stressful having to do it on your own. Similarly, you know exactly what a repository is, because you helped us contribute to it when you wrote your "Hopes and Dreams". So hang in there: you know some of this stuff, and it's just a case of remembering it, and also using it on a regular basis (see iii, below).

ii) On the other hand: one of the points of GitLab, and of having "Issues", is that you have a community of people who can help. If you're not clear about something, open an Issue and assign one of us to it. (@leyla.feiner , for example, is the tutor for this course precisely because she can quickly help you answer questions about what a Terminal is, or what a Repository is--and much more). If you think it's a question for someone else, open an Issue and assign them. And then, once you have the answer, close the Issue. In other words, part of the GitLab experience (and this is something we think is central to doing history in a digitized world) is that we need to learn to work more collaboratively.

iii) It may seem ironic that I'm writing "be collaborative", as that kind of top-down direction seems to undermine my very point. But part of working in a different way is that when there are problems, we all need to be more proactive; and, although @daniel.mcdonald and I can provide help and comments (as now), the solutions to the problems also need to come from you. If you want a glossary of "GitLab for dummies" terms, open a Wiki page yourself (see Wiki tips ) and start listing up the terms you need help with. Then invite us to contribute. More broadly: this type of work requires a different kind of engagement. We all work different hours, so it's worth being aware that help isn't always immediately available. For that reason, I don't think it's as viable to concentrate all one's weekly preparation for this particular class into a single session the night before class (@maryam.joseph I'm not saying this is what you generally do, but I do just notice in this particular case that you first raised these issues last night, when it was already too late for me--at least--to help). Keep an eye on GitLab stuff during the week; if there are methods you learn which you found tricky (e.g. using Terminal to do something), remind yourself of what you did every couple of days, just for 20 minutes or whatever time you can spare.

So: where you're overwhelmed, use GitLab's Wiki and Issue functions (especially assign) more; keep working on this regularly to get more familiar with the stuff that freaks you out; and see you in 90 minutes for class!

To add to this: I've been quite swamped the past weeks and haven't been able to keep up with everything on gitlab, but the situation has stabilized a bit now. If you've got questions, you can open an issue (or message me on Teams if you don't want anyone to see ;) ) and I'll be able to answer you quite quickly, hopefully.

@martin.dusinberre Thank you for your comments, that could help a lot! Closing the issues will make it a bit more easy to find the more pressing matter. And thanks @leyla.feiner ! See you in half an hour everyone!

closed