 So it's 11 o'clock, 13 people in the waiting room. I'll open it up at 14 now. And I'll open it up in five seconds. Okay, you let us know when we're ready to go, Pete. Yeah, good to go, David. Okay, great, excellent. All right, well, here we are. Thursday, the 4th of February, and we are very pleased to welcome Corita and James as we deliver a webinar for everybody regarding Victoria University of Wellington's use of GitLab. And this session will be really giving you an overview of how from the academic perspective, the platform has been used. Before we kind of get into that though, and before I do some introductions of James and Corita, I just want to kind of go through a little bit of housekeeping stuff. The webinar is being recorded. So if you don't want your voice recorded, then you need to stay silent. Hopefully you'll happily ask questions and won't be shy as we get into the panel discussion. The slides from this presentation will be emailed out to everybody who has joined the session. And if you do have any questions during the presentation, then if all you need to do is type them into the chat box. And we will read those out. Or if you want to voice it yourself, then we'll give you that opportunity later in the session toward the end of the session. So let's just quickly go through and do some introductions. And I've just realized I've lost my introduction slide of James and Corita. I don't know where that disappeared to. So in the absence of me having that to talk through, what I will say is that we've had the pleasure over the last several months of building up to this, of working with James Quilty, who is the program director of the School of Engineering and Computer Science at Victoria University of Wellington. And Corita Escott, who is a former student and now assistant lecturer, soon to be PhD herself as she undertakes that venture. Working on not only preparing this program, but gaining a much deeper understanding of the use of the GitLab platform from a teaching and learning perspective. So I think I've got a few more intro comments to make. And then I will hand over to them to do their own additional intros. And we will kick off. So as far as the overall agenda goes, we'll go through getting their perspective. I'll then quickly give you an overview of the outline of how GitLab is kind of providing for universities in terms of the licensing programs that we run. We'll then have the open panel discussion and move into any closing remarks. So quickly background for me, probably my claim to fame as far as education and technology goes was I had the good fortune to work at Methodist Ladies College, which is a fairly exclusive girls private school in Melbourne. And we were the first school in the world to compulsorily introduce laptops in 1991 for fifth graders. And we're working with Professor Seymour Pappert that the MIT Media Lab, who was one of the founders. Anyway, that's a long wind of way of saying I've always had a passion for what technology can do in education. And I think this at the tertiary level is an awesome, awesome example. So moving on, a couple of quick points about GitLab. I would usually if this was an interactive session ask people to guess what they think the numbers are. But in the absence of having that interaction I'll just kind of explain it. I will say by any standard in terms of the varying companies I've worked across in the tech industry that GitLab is by far the most transparent corporation I have ever experienced. We have a handbook, which is essentially the company operating manual which you could freely go and explore and find all sorts of fascinating details. It's 8,000 pages or thereabouts now, I think. We are at our heart open source. So we have GitLab Community Edition. Some of you may be very aware of that and probably using it. The 1365 is a reference to employees and the number of countries in which the employees are based. So work at that order of complexity. And in fact, both those numbers are slightly outdated now. And the 3000 plus is active contributors to code as far as GitLab versioning or rather GitLab releases goes. And we actually do a new subversion release on the 22nd of every month. I'll talk more about velocity a little later into the GitLab part of the presentation. I think if you're thinking about kind of why GitLab exists in the market and what we're here to do, it is really, I think, best summed up by Mark Andrusan's broad commentary in the market. But I think this in particular is a pretty good example of explaining just what we're aiming to do which is really help organizations move at the pace that technology is enabled and do that with velocity. And as you'll probably know from your own organization or others you might have a view into the sorts of environments that we tend to see and that I think that the team at VUW are preparing their students for look like this into a tool supply chain that is unfortunately not as integrated as it might be. GitLab's view of the world is very different. We as you can see across the top have a single platform that caters to all of these functional requirements from managing all the way through to release config monitoring and defending. And over time, what organizations are realizing is that whilst they may sacrifice some point superiority of a tool, the benefit of being in a single platform dramatically outweighs the loss of the 10% that they're missing out on in unique functionality. Just another quick kind of touch on the transparency piece. The company again publishes this level of detail on our website and whilst you can't click on these here, all of these functional descriptions are actually clickable on the website so you can drill in. You can literally see in any particular dev cycle where we are at as far as what we're delivering against on any given kind of sprint cycle or whatever the activity is. So that level of transparency is truly kind of there for you to see and do your own planning around. Historically, the company has continued to deliver really substantial growth in the platform in terms of what the platform is capable of supporting within your organization. And I suppose from an academic standpoint, what that means is your curriculum is probably gonna continue to expand James, which is a good thing. Because the students that you're sending out into the workplace are gonna need to be ready to, you know, embrace that. I think from the GitLab point of view, that is probably pretty much all I wanted to say. And I will now happily hand over to James and Carita to do their introductions and start their part of the session. So James and Carita, I am gonna stop sharing and invite you to start sharing. Thanks, David. So as David said, then thank you very much for the kind introduction. I am the engineering program director at Tehering Awaka Victoria University of Wellington. And Carita here, I had the great pleasure to have her as a student in my class and now as a colleague. And so as the title slide indicates here, we're going to talk about our reflections on GitLab and undergraduate teaching from both sides. So I'll give my staff point of view and Carita will speak to her experience as a student using GitLab. So our context really informs quite a bit why we chose GitLab, why we settled on GitLab. So just to take it from the top, we're one of eight universities in New Zealand. We have a School of Engineering and Computer Science that offers a BSc and a BE degree. I'm gonna talk mostly about the BE, the Bachelor of Engineering because I'm the engineering program director. We have a variety of majors. I think the real key point here is that we have a diverse cohort and I will be touching on that later. And our environment is quite unique as well. So we are located in the capital city of New Zealand, located in Wellington. We have a center of government here and a really, really strong local tech industry. So our graduates go to places like Weta Workshops who are famous in the movie industry. They go to Xero, the online accountancy firm. And we even have a student. So actually one of my students who's graduated and is now working as a DevOps engineer at Rocket Lab up in the Mahia Peninsula, launching rockets or help launch rockets. So we've got a lot of stakeholders that we've got a very diverse cohort and we need to meet the needs of all of these stakeholders. So the objective that we have as a school, one of the objectives is to teach engineering project management to undergraduate engineering students. And why do we have this objective? Well, engineering graduates are expected by accreditation and by employers to have knowledge and skills in engineering project management. They're capacity to work within a managed project and understand what's going on, to have some skills in teamwork and operating in different modes within a team to have skills with modern tools and modern practices around projects. So my role in all of this before I became even the engineering program director was to develop and deliver the project management courses within the school. And at the time that I started this, there was actually no preferred technical project management infrastructure. So we started with nothing. And this is the story about how we settled on GitLab. So one of the things that we have here to fulfill this objective, one of the things that we settled on was to choose real-world full-year projects with external clients wherever possible as a possible way of meeting that objective of teaching engineering project management. But this choice didn't solve everything and led to its own challenges. And we had the big three challenges, or I as a staff member found the big three challenges, which are listed here, the individual versus group work tension, the theory versus practice tension and the unauthentic versus authentic assessment. And those challenges link with each other as well. So just to talk about the first challenge and this perhaps arguably is the most important and the biggest challenge facing me as a staff member is that, as you can see on the left there, most students see themselves like that. They are individual students, assessed individually on short individual assignments. They solve the problem, they are graded, they receive the grade, they move on to the next piece of work. And so this is really important. It's the educational environment that they've come from prior to joining the university. It's the educational environment they find themselves largely within the various courses within the university as well. But it has a lot of important effects when we're trying to go from individual work to what we see on the right, students working together as we would expect within the workplace and as employers expect the students to work. So the whole structure and background leads this perception that engineering students sometimes have of their professional engineering work as being something that will be a body of labor divided into small, non-interacting pieces that they work on individually and contribute at the end and somehow it all just comes together. So their part, their role as professional engineer is to solve small technical challenges. And of course, I'm sure that those of you who are coming from industry and our employees know that that is absolutely not the environment that we're working within today. It's not even the environment, the academic environment that we work in these days. We have a situation of highly-coupled, collaborative teamwork and it's only going to go more that way. So the idea of the hero coder, that's so 20th century. Part of this as well that does tend to make this a really big challenge is that the students are very instrumental about assessment. When everything that their entire degree is writing on are the grades and the marks that they receive for the assessments, they look very, very carefully to what is asked and they try to meet that. And so then they take a view either consciously or unconsciously that the assessment is the learning itself, assessment as the learning. And one of the things that we want to get away from is actually that. And one of the ways of doing that is having that practical project that's long, complicated, requires management to actually force students to move away from individual work and move to inter-reliance and collaborative work that we need a professional engineer to fulfill the graduate attributes and to fulfill employers need. So spend a fair bit of time talking about that first challenge. I do think it's a big one. I think that it informs the second challenge which we have, which is the theory versus practice challenge. We have to deliver both. But the project management theory, well, let's charitably call it not the most popular topic for a software engineer or an electronics engineer. You think about classic project management and you think about planning, documentation, the whole PMBoc thing, scope, time, quality, cost, risk, all of those knowledge areas. That's all good. And the theory is important, but the theory only is actually not really of interest or value to students or employers. And that theory can feel really disconnected from the day-to-day technical work that the students perform in their courses and perform in their employment because many of them have part-time jobs or have internships. And so it can feel irrelevant. So we need to have a way, you know, this challenge and this tension of introducing the theoretical ideas that we need to as a university while also having modern tools and practices. And modern tools and practices are hardly without their own problems because specific tools and methodologies date rather rapidly. And it's not the role of the university to teach specific tool use. Rather, we teach broad theoretical ideas as well as modern tools and modern practices. So the solution that we came upon here is to take a practice-based approach, a practice-based professional learning approach to the course where we marry both the theoretical aspects and expect a practice in terms of repeated performing of a particular activity to build and maintain a high level of skill, high level of professional skill. And look, the DevOps loop that we see, there was a really good example of practice and it's a really good example of an expression of modern project management, you start with planning. So you start here with planning and then you go on to do the building, the execution, the create and then you monitor your quality, you verify, you evaluate. It's a key attribute of an engineer and then run through the rest of the cycle and you keep doing it. So you practice and you keep building and building. Every project is built iteratively. So again, this does require that big long project. But we're talking here and we still haven't really addressed this issue of there's no existing project management infrastructure. So the third challenge that we have and that does link into the lack of an infrastructure is assessment. And I've already mentioned that students are very, very Q sensitive to assessment. And we've got, I'm sure everyone will recognize the unauthentic assessment that's very academic but feel false and pointless. Formal documentation for a software project is not what we're doing these days. Reports and essays on your experience or reflective report is also not really a particularly authentic way of assessing your experience on a project. Even examination of the final product or artifact doesn't tend to assess the student's performance and that's what they really want. They want their performance to be assessed and have feedback on that. Even the final artifact as a monolithic whole doesn't really allow that. And so all of those things really, really leads to that instrumentalism. If we ask for an essay, we get an essay. We don't necessarily build the skills that we're looking for in terms of modern project management, modern software development, modern development of software and hardware. So what we do want to assess and the authentic things that we want to assess are things like issues, milestones, actually documentation, documentation management, milestones and epics, the management of time, the management of scope, branching strategies, how do you keep things under good version control? How do we assess that you have followed good continuous integration? So we need to find a method of assessing that practice. And without settling on a particular piece of infrastructure, it's actually rather tricky. And that's where GitLab rises to the challenge. So we started out a vacuum and tried a variety of things. And then when I found out about GitLab, I thought, aha, this is great. It's self-hosted, which is important for our external clients, but it's an all-in-one application. And when we say talk about all-in-one, we're not just talking about the technical. So it's not just that it does all of these technical things all-in-one. Important as that is. It also allows the non-technical aspects to be captured as well. It really does become, in the project management terms, our single source of truth. I'm prone to tell the students, if it's not in GitLab, it doesn't exist. Just to reinforce that idea that GitLab can and should contain everything to do with your project. So it enables as well, by design, meaningful teamwork practice because it's built on that DevOps lifecycle. It's built on that loop that we see here with the modern tools and practices. So by design, it enables exactly the first thing that we want to get away from individuals and into group work. It also provides a sophisticated project management features that marry nicely with project management theory. And it enables authentic assessment because as an all-in-one application, we have access for assessment to the practices that the students are following. The other thing that's worth mentioning is a self-hosted on-premises application. It alleviates problems with the access for assessment because we have the control. It also ensures confidentiality when confidentiality is required. Now we really want students to follow the engineering design process. The thinker planet build it as our School of Engineering's slogan goes. And that's really, really nicely expressed by the DevOps lifecycle. So you can imagine how happy I was to find how well GitLab actually gives me the expression of project management in a 21st century context-appropriate way. So what you see here is GitLab is an all-in-one solution showing the GitLab workflows from a blog post a little while ago. And as you can see here, this is good basic project management. You come up with the ideas, right? You document it. You plan it. You plan it in scope. You plan it in time. Then you do the technical execution. You share it. You commit it. You get it under good version control. Then you evaluate how well it's done and control all of those aspects of the project. And then you get it out there. So it's a really good way of this idea of GitLab workflows a really good way of introducing the students to not only modern practices, but actually good project management in a way that feels authentic. The thing is, you know, did have a little bit of experience with this is if you don't say use this, if you say use whatever you feel, then you get one team choosing some, one making one set of choices based on what one, two or three team members have experience with. You get another team who make a completely different set of choices. And then not only do you have this problem of, as you can see here on the diagram of, if you don't have GitLab, which has this horizontal integration here across all of those aspects of the DevOps lifecycle, you have all of these weird interactions going on between the different tools that you choose, this tool chain tax and the cognitive footprint that it places on staff and students is just huge. Now imagine that's just one project. Now you've got 18 projects. So going to GitLab as an all in one solution really made life simpler, not only for the students, but also for the staff. So it also allows some insights into student practice. So we want students to follow good version control and we can talk as lecturers, as staff about good version control practices and continuous integration. And we do in lectures. And of course then assessment instrumentalism kicks in and the students go, what's in that test? What's in that assignment? So here's a really good example from early on where version control practices were kind of followed. We've got Frank fund branch, which was not merged. We've got Ben's branch, which is individual work, not associated with a piece of project work. We've got Frank's tiers, which presumably was not the most funded branches. And there's work sitting on these branches here that aren't merged that wasn't really integrated. It was just wasted work. And Ben's branch, well, who knows what's that related to in the broader scheme of things. So one of the things that we don't see, and this is actually quite a historic example, we don't see this now at the end of our projects. And the reason is that we are able to intervene earlier because we have the insight that GitLab affords and make corrections prior to the end of the project. Some other insights that we can have are from, for example, the tile view or the value stream analytics. So the value stream analytics are over here on the right. These give staff good insight to students who are regularly contributing it, which is what we want, good tile view there. And the lovely thing about the tile view is it encompasses not just the technical commits to Git, but also all of the management aspects as well. And then we've got a student who perhaps needed some practice at their continuous integration. So it's good to be able to see that. It's good to be able to see that for staff, but the beauty of GitLab as well is that these built-in analytics are available to the students and can give continuous feedback to the students as well about their performance. And I should mention also that the API allows a really deep insight into individual practice. Getting onto the GitLab API and pulling out event information allows staff really deep insight into what students are doing and how they're following the different practices. So just to finish off my experience as a staff member, just to talk about current use, GitLab started as really just being used in one or two courses that were looking at the project and teaching the engineering project management. Now we actually have courses from second year to fourth year, not a lot, predominantly only those that are involved with project-based courses and predominantly in software engineering. But we do have grown from a pair of courses to being a set of courses across a number of years using GitLab for their coursework. It's also used by some staff to store and manage their course materials. And the more complicated the course, the more that GitLab is required. And also used independently by staff and students to store and manage their assignments. And also the future use we can see from the trends that there is going to be wider adoption for research and also for administration. And we are already seeing the school's operational side, our professional staff are beginning to move their code that actually operates the school and the various school websites into GitLab to use GitLab. And this is a really good time to mention the school is running completely self-sufficiently our GitLab and that's really enabled us to meet objectives that we otherwise wouldn't have been able to achieve or we might fail to meet. By necessity, our school is really unusual and has some very high demands in terms of IT autonomy to do the things that we do as a school of engineering and computer science. And really it wouldn't be reasonable of us to expect any central IT service to accommodate all of the unique things that we do and all of our unique activities. So we are able to run our own service that indeed we do in collaboration with our central IT service who provide the virtual machine, but we run independently. And so we are able to have that autonomy that we need and run our own instance, which is a really valuable thing that GitLab has given to us as a self-hosted on-premises application. Okay, and that's probably enough talking from me as a staff member. I could go on, as Karita well knows, because she's been my student, but now it's time to pass over to Karita for her perspective on the student side for learning this stuff. Thank you, James. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thanks, Karita Thank you. So that was an sense of opportunity that I played in today's conference, and I have sana eight-year transfer for the student basket, and we will go on in my little micro program with Ms Kate and the student lecturer in the school of��ernarrang and computer Science at the Heading awaka. As James mentioned, I was a student of his a few years ago and actually took part in the project management course be talking about the student experience. So the project management course was my first hands-on experience with the DevOps lifecycle. We worked as a part of a team on a real-world year-long project from start to finish. And at the start of the project, and in that point in my degree, I had pretty basic programming skills and was somewhat aware of the general steps in a project. However, I had no experience working in a team or working on something for such a long period of time. So there was definitely a lot of learning to be done both technically and in terms of the project management aspects. So I was on a team of six students and all of us with ranging but pretty limited skill sets and experience. And our project, funnily enough, our project was to develop a project management software for an engineering company who wanted something simple but specific to them to help them manage their own projects. And we were quite lucky in that we had a very engaged client who had a very clear vision of what they wanted. And they were realistic about our abilities, but they were very encouraging and supportive of us throughout the project. So that was really cool. So at the start, a year-long engineering project with other people felt quite overwhelming. So James mentioned earlier that as students, we're used to working on short individual projects where we work on them, submit them, and then we don't think about them again until we see our marks. And so this idea of think it, plan it, build it at this point really is presented with some small problem. I'm going to think about a solution. I'm going to try to build it as best as I can and then I'm done. When realistically and in real-world projects, you go through many iterations. And as you can see, there are many steps to be considered. So throughout the course, we were tasked with taking some high-level concepts and ideas of projects management, projects and project management, such as planning, testing, integration, time and risk management, and so on, and putting them into practice. In any software project, there are a number of tools that facilitate the successful delivery of a project. However, at the time, as a group of students with very limited knowledge, making decisions about all of the different tools and platforms felt quite daunting. So the use of GitLab really enabled us to experience both the technical aspects of our project, but also the management aspect by providing a tool that allowed us to to do the planning and the management alongside our technical development, alongside our CICD pipelines, which took some of the pressure out of making those decisions. We still had to make a lot of decisions that had good and bad implications for us throughout the project. One thing we consistently did was we relied heavily on the experience of our one team member who had had an internship over the summer. The rest of us had no industry experience at all. And one thing we had to decide on early on in the project was the language that we were going to use to develop our software solution. And I remember deciding as a team that we would just use the language that our strongest team member was most familiar with. Despite the fact that the rest of us were similar, were more familiar with something else, we made that decision based on her. So luckily for us, she was a pretty good teacher for a third year student. But I think it's fair to say that while she was able to help us along, making decisions based on your strongest programmer and not on the project itself, it's not only bad practice, but it was also really risky. If she had left us at any time, we would have really struggled to even finish, I think. So yeah, students don't always make the best decisions. And so one of the other things we did despite being taught about it in class was we neglected to decide on a branching strategy. So alternatively to Frank's fund branch and Frank's tears, I think the other one was, our branching strategy was to use no branches at all. All six of us committed directly to master whenever we felt like it. And all six of us doing that with no real pattern or idea what we should be doing led to some pretty interesting merge conflicts. And in addition to that, we not only didn't use branches, but we also completed some pretty rough code reviews. And I think looking back, I'm not sure you could even call them code reviews. And although merge conflicts can happen and do happen in any project, our solution to send each other code via Facebook to resolve those conflicts. Definitely not a good idea. I think it's certainly something James wouldn't have been impressed by at the time. And you definitely couldn't do an industry. So on top of that, we also didn't really think about a production environment until towards the end of our project. So we knew we needed to deploy the software in order for our client to use it. But we figured there would be a problem for later on. So as you can tell, even though we're provided with all the information and tools that we need to take the concepts of DevOps and project management and put them into practice, yeah, we didn't always make the best decisions. So as I mentioned before, there were a lot of lessons to be learned as a student at university. In an engineering context, the project really built on and supported the development of new skills that better prepared us for joining industry. And GitLab really supported that development such that it was able to provide a tool that allowed us to collaborate and put our theoretical knowledge into practice together by working on a real world project from start to finish. So as a tool, GitLab really supported that learning for us of the DevOps lifecycle in a practical sense, even if we didn't really implement the steps properly. So in our project, we were able to use GitLab from start to end to plan our iterations of work and work together as a team. It was especially important when we weren't able to physically be together in person, which turned out to be a lot more often than we initially thought. And we were able to create a backlog of issues to keep us on track and engage with different aspects of the project in the same repository. So James mentioned earlier about being able to manage the project as well as the technical stuff in the same place. At the time it was, we might not have really realized or been even appreciative, but that really was quite important to us that we didn't need to be swapping between learning different tools. So as a first time working for an extended period of time as part of a team, we were able to create that one source of truth in the repository while we attempted to engage in best practices. So using GitLab to manage our technical work and the project itself allowed us to experience an engineering project in an environment where not too much effort was needed from us to learn how to use the tool. And although we made mistakes along the way, lessons were learned and in the end we were actually able to successfully deliver a software solution for our client that we could be proud of. Thank you very much for listening. I will now pass over to David for the rest of the seminar. Excellent. Hopefully you've got me back again and you can see the screen that I'm sharing. Awesome. James and Corita, that was excellent. I think I'm going to steal the hero coder comment, James. I love that. I'm sure it is actually still a thing. I've spent some time in a few large companies that sure remain nameless and it's either the hero ops person or the hero coder that still seems to exist in some organisations. Anyway, I think it was fascinating actually just hearing the story of the journey that you've been on and where you've landed in terms of how the platform has really enabled you to do a whole lot of things that otherwise would have probably been much more complicated. Okay. So I'm going to spend just a couple of quick minutes. I wanted to give a shout out to a company called Integration QA. They've been a phenomenal partner for us as we've been working to build some focus around, frankly, supporting universities just in embracing what they can enable. And I'll talk about how we're doing that in a second. But if you haven't heard of Integration QA, I would certainly recommend making yourself aware of them and the work that they're doing. Certainly a lot in universities, but also beyond particularly around the DevOps space. Okay. So GitLab for Education. Again, keeping in mind that you'll get this deck. There are links here. So the program itself has been running for at least three years. Essentially what GitLab for Education does is provide a free instance of the ultimate tier or version of the GitLab software for academic use purposes. The details of the program in terms of the fine print is available on the website. Just to give you a couple of quick points on it. I'm not going to read through this by the way, and I'm not even going to talk to it. All I'll do is just simply pop up the next couple of slides so that you know that they're there for you to dig into when you actually get the deck. And if you've got questions about any of the aspects of the Education Licence Program, there is definitely a section on the website where you can post or you can specifically direct any questions to me as well. So having gone through that, just wanted to highlight a few logos. I hope there are no competitive issues with that. James and Carita, these are just some examples of some of the local organizations or local institutions that are using the free version of GitLab in their university teaching today. What I wanted to do now is just close off before we move into the Q&A discussion by highlighting that while GitLab has an Education Licence Program, we recognize that the standard commercial license just wasn't cutting it broadly in universities because you know commercially it's obviously way more expensive than a lot of universities budgets can afford. There was recognition of that at the global level, globally over the course of the second half of last year, the company moved to a fundamentally different license pricing model. So without going into all the gory details, essentially you know the fundamental model that you would see on the website today is user price driven. So a number of users determines price. What we've done is moved to a very different license pricing model for universities who are going to commercially use GitLab in internal IT or for other purposes. And that model is actually based on student enrollments and just based on feedback I've had anecdotally with the organizations that I've socialized that model with, it is certainly very palatable and I would say is you know my role in this region has been to localize that global program particularly in the context of what I call the post-COVID reality as I was explaining that phenomenon back up to the global team about why we needed to arrive at a more commercially feasible model in this market. So that's been achieved. We're in a great position in that we've got some universities who are already looking to take advantage of the GitLab ultimate license pricing as it's been modified. I think the other thing that I want to highlight is that for all intents and purposes that license is actually an unlimited use license in terms of numbers of users that can use it obviously whereas the more traditional model was very much you know user pays, numbers of users drives the price. This university model is definitely not that. Okay let's move to Q&A. I'm not sure if Tim you've got that any questions from any of the participants yet but this is that time. I'm going to start off with a question which Tim I didn't document in the chat which is, Carita what happened with the project management you know sort of development effort and your client your delivery? Yeah I think like most clients they're interested to see the technical stuff. We were quite lucky that he came to visit us quite a lot so when it came to the management stuff of needing to you know have a production and deploy he was happy to just have a play around on our laptops so I think while he was really great he also because he hadn't really pushed for us to be organised with our management part. Yeah so it did take a little bit we did have to after the project had ended we actually had to and I say we but it was mostly our strongest team member had to go through and make sure that it was properly deployed for him so while in terms of the project there weren't any major disruptions we did have to follow up after the course had finished to to kind of tidy up where we hadn't hadn't really delivered. Yeah I think I guilt tripped the team by saying it's what professional engineers do. Yeah yeah. Well I was going to ask the hard questions which is did you deliver on time and on budget and was it bug-free right you know because that's that's always what the the Linus business the line of business executives expect they want perfect software they want it yesterday and you know preferably free or cheap which is not real. Yeah I think budget wise we were okay probably I don't think I could a hundred percent say bug-free but for the most part um yeah for the most part delivered I think yeah if James hadn't guilt tripped us into sorting ourselves out post the course we maybe couldn't say that. I think just to to give a little bit of background that Carita is a little less familiar with there um the the client was and this is another thing that executives and project management people say is that client satisfaction is actually sometimes much more important than those other aspects and the client was very very satisfied um satisfied to the extent that um he put up a prize for the whole team and and gave back a little bit he said that said an enormous amount of value to his business so this was definitely this this particular project was definitely one of our best success stories actually and yeah yeah. Excellent very good um I haven't been monitoring whether or not we've got questions uh I will poll the audience so one more time to see if there are any questions um oh I've got one actually Brian I'm going to read your question out assuming you're still on otherwise if you want to read the question yourself you can unmute yourself and uh ask the question yourself looks like Brian's not going to ask that question I'll raise it so this is Brian Bell Bellson Stanton who's actually here at Macquarie University have either of you two had experiences in GitLab with grant funded research projects. Yes for for me I have um so there are a couple of things that um that I I did and there's some hours and time to to talk about so at least not uh not in the the main part about um my use and actually our use on the staff side of of GitLab for managing the the delivery of the courses on the grant funded side of things yes I I have some grants and because I've built a skill set in GitLab I decided it was only sensible to start managing the research using GitLab itself but my research areas tend to be a little outside of software at the moment or at least the the things that I'm putting into GitLab so I'm not necessarily using GitLab version control for keeping um for keeping control of code rather I have datasets that need to be tracked under version control datasets need to be processed cleaned checked for for verification as well as all of the you know the myriad administrative aspects of dealing with um with grant funded research so that's that's my contact with um with grant funded research thank you um I've got a hunch that Brian may be coming from a slightly different angle and what I might do is connect Brian with you James if you're comfortable with that um James I do have a question in the absence of any of the other participants having one you touched on the relationship to internal IT and I think you were very generous and I'm going to say that having spent considerable time talking it talking with rather both academics who are in your situation and university internal IT I'd say in most instances it appears there's a degree of tension shall we say between you know what the academics may want in terms of the their needs and how they feel they should be supported versus what internal IT has the ability to or even just willingness to you know support sometimes that can be budgetary constrained sometimes it's actually a difference in views around what technology should be used I'm interested in your point of view on how you've kind of navigated that and you know if there were any people you know in from university IT not necessarily your university but generally you know representing university IT what would your kind of messages be to them in terms of how they would you know best support what you're trying to achieve on the you know faculty side yeah um so one of the things that happened actually quite a long long time ago before even the school of engineering and computer science back when it was the department of computer science is when central IT was instituted a decision was made that the computer science department needed to have that IT that tech autonomy things were just not going to work because the stakeholders of central IT are a very different and broader set and their concerns particularly around their sensitivity to risk and compliance aspects are very very different to those of an academic department delivering a teaching and research program so um so we established and have kept that particular separation which has led to some tension sometimes yes you're right I mean there are things that that we want that the other party can't be reasonably expected to give or sometimes there's just not quite the meeting of minds on a particular issue be it around a particular platform um or whether or not you know particular aspects of IT are going to be um are going to be pursued so what I would say I guess in my in my ideal world um I think that having discovered DevOps and having worked for the past few years um and learned a bit more in that space I think that the time has come when central IT starts to take a lot more of a DevOps approach and becomes a little bit more open to um to interaction with the the non-central units um with the academic units at the moment um just my personal feeling not only from this university but from other universities that um that I've seen there is quite an understandable but there's a barrier between the flow of um of knowledge and skills and even labor um you know we have a huge pool of of students whose skills are developing day after day as they attend our lectures or and and complete our assessments right um so so it we've got this great set of talent here that that the university could leverage potentially in a in a better way and actually you know in terms of where we are in in the early 20th 1st century now we have the technologies and we have the the frameworks that actually allow that to happen in a way that probably couldn't have happened in the past yeah it's actually an interesting point um I won't mention the name of the university but there's a university in the US who's become a very you know kind of strong GitLab advocate both within technology and uh at faculty and I think the benefit that they've gained or one of them they've gained is that they have students actively working on uh university IT projects and so you know those students might be working to complete a but they're doing real work for the university you know and I think university IT is benefiting because it's essentially free labor um if we want to take a somewhat cynical view but it's also you know I think it's an awesome way to see the the the collaboration that's enabled when you have that cooperation between you know the two entities yeah I I hesitate to point fingers as as you probably sense I I do honestly though feel that much of the problems that we have are structural um and and so it would be you know quite unjust to the point fingers really that they're historic structures that we need to break down and that's what DevOps transformations are for right yeah David it's Simon L here hey Simon um yeah hi Simon L from Integration QA uh that's been really fascinating uh from the presenters and um again that that comment about uh heroes uh coding heroes is is resonating we're doing work with a startup um at the moment or in fact there's they're two years past the startup at the moment up in Brisbane Australia and um sometimes those heroes are accidental heroes and want to want to work them away out of a out of their um role in the team we've got excuse me one client that uh they can't actually put their code into production without an individual in the in the team who's one of the founders of the business getting involved and one of the aspects of what we're trying to do is put the structures in place to ensure that that team contribution can actually occur and having the right DevOps delivery and pipeline works that way what what are the ways of I noticed you saw the the value stream um the value stream board and that sort of thing what are the ways are you looking at um team culture for software delivery within what you're teaching James I guess my most recent experience of of doing that has been that the good students are often the ones who are are filling that role of the the hero coder um or for that matter the um the hero hardware person um who does all the electronics and they shoulder a lot of the burden and they don't necessarily as you say want to operate there they are often the the biggest allies um in correcting those problems in the team and I've got a really good example of that from um from a couple of years ago where there was a team who were really interested in um in DevOps and much much of the class where they'd been reading the phoenix project um and we had um it was a diverse team as they very very frequently are there were strengths some team members had strengths in some dimensions but not in others and similarly there were complementary skills but it there were two two students who recognized that they were doing a lot of the work in one particular area and came to me and said what are we going to do to um to correct this this problem because we identify this as a problem you know if anything happens to us or you know we um we get job offers or whatever you know the the project's going to file we don't want that um and also place demands on them and I said well look let's you know let's go back to to our DevOps principles uh and back actually you know beyond that to um to principles of co-working and co-location peer programming making a real point of sitting people down together um and sharing that knowledge and making sure that that knowledge is transferred between people it's just good basic project management and like I could and did cite the PMBock areas for that um but also it's in the phoenix project as well and it's in the DevOps handbook for that matter um and so I think those those two things are the ways that I've been able to to create the problems when the problems have occurred um or the the problem always one is to have allies from the people who who are the the the ones who understand the situation and understand the risks of it and also to to get those reference points back to to good solid theoretical principles of good practice and good theory yep yeah no that's that's fascinating thanks James thanks Simon one last question and then I think we need to close it out uh this comes from Matt Plummer directed to Carita uh how useful was your student experience using GitLab when it came to transitioning to a teaching role in the factory awesome kind of faculty factory awesome question yeah that is an awesome question uh uh my my experience with GitLab as a student um you know while I didn't probably use it as well as I could have uh it definitely helped when it came to using it as a as a teaching tool uh so one of the first uh courses that I worked on uh when I became an assistant lecturer was with James on the project management course uh and being familiar with it made it so much easier to uh support the students in figuring out what they're trying to figure out uh but also in being able to look out for things uh like and during the assessment um assessing how many students were in the course uh we had we've had regularly over 100 yeah so um you know from being one of the students to then trying to assess a lot of them of again overwhelming uh so having the experience with the with GitLab I was able I knew what I was looking for um but also it's helped me uh with other teaching courses so I've taught I think three different courses now um and one of them is the DevOps course that we've been developing uh and just being being confident in that I know how to use the tool to manage myself uh has really helped with that uh but I also use it for my thesis work as well so Paul GitLab probably have a lot of my awful repositories all over the place um but yeah having the initial experience really took the pressure off uh becoming an assistant lecturer and helped me with a lot of that that stuff that's awesome excellent look uh on behalf of everybody who joined the session today uh Carita and James uh I want to express uh our gratitude for you being prepared to come on and share that learning experience um you know obviously uh personally I'm very much looking forward to continuing to work with you and expand however we can the use of GitLab as a way to you know kind of continue to develop interesting exciting offerings for the university to be providing students you know as they then head out into the workforce so thank you both very much and for everybody who joined thank you just as a final reminder we will be um uh sending out the uh the content uh the slides that is uh so that you've got that to refer to and um if you do have any questions then you can actually refer those directly to me um uh or if it's of a more general nature then start at the GitLab uh dot com website there is a staggering plethora of information and if you've got any decent search skills you'll probably find what you're looking for but if you don't then certainly feel free to ping us well uh that is pretty much a wrap thank you very much everybody thank you David for the opportunity to speak I'm actually very grateful for it thank you thank you very much it's done all right thanks everybody