So by the way, you see I'm splitting up the screen here. I'm going to try and experiment here, which is we're going to try to keep a summary in real time of this meeting. And I'll try to keep that centered on the screen. And then on this side of the screen, we're going to have the detailed notes. And so the detailed notes are sort of the traditional transcript of what everybody said and when they said it. It's not going to try to be court stenography level, hopefully, but basically, if you want to make sure that you were recorded as having said something, make sure that it shows up on the detail side. But then the summary is going to be something that really should only be, it definitely should not take up the full screen by the time we're done. And so make sure if you see something that's really important that somebody shouldn't have to dig into the detailed notes to find, make sure that it shows up in the summary. And I want to just see how this works if we can summarize this in real time, in addition to taking the more detailed notes. All righty, I guess it's 2 o'clock now. So let's start. Hi, everyone. We're here to talk about code review, as I'm sure many of you know what that is, hopefully. So first of all, to just talk about the agenda, I'm hoping to kind of separate it into problems that people have with code review or if they have a problem and what brainstorming on what the root cause is, followed by a part on what we could do differently. And then at the end kind of concluding bit. So especially focusing on social conventions and things like that, less focusing on technology like fabricator or whatever, starting from the point of, what do we ideally want? And then later we can go ahead and get there. And brainstorming ideas, not final solutions. So I guess I should talk like where I'm coming from to begin with to introduce the problem. Personally, I've found sometimes things are frustrating. It seems like with code review, it can be very random. One day a patch gets reviewed in an hour. The next one takes two months. One time some gets trivially looked over. The other time it gets looked over with a microscope. And then people disagree on what the correct way of doing something is. And it feels very inconsistent and random. And like playing roulette, how easy it is to get code intermediary. And personally I just like things to be consistent. So yeah, the point of the session is do other people feel the same way? And why do we think it is that code review situation is unideal? And then later on, what can we do about it? So I guess to begin with, since brainstorming, I should open it up to the floor about what do other people find frustrating about code review? Nobody? Do people think that it's accurate? Description of the problem. Hello. I can start. What I find most frustrating is that when I do have free time for code review, it can be hard to find patches that I'm suitable to review. And when I actually need reviews, usually it's just ping people on IRC and get the reviews that way. If I add people through Garrett and I think they're good reviewers, there's a good chance they won't even see it until I ping them a few days later. Yeah. Do you want to? It's really tall. As a third party contributor, I would say that the most frustrating part for me is not knowing who's responsible for a particular piece of code. Typically, the things that I want to contribute are in places where there is not a specific person to point to who's responsible. There's no one person who or even a group of people. Nobody's responsible. And then, as you know, differing opinions about how to implement features. And so there's nobody to arbitrate and to say that this is the right way to do it. So you get people disagreeing about really trivial implementation things and not making any progress. And it's very frustrating as somebody who's a third party developer trying to contribute to core. Thank you. One other thing I'd like to, sometimes it feels like there just isn't enough. It's not code views and it seems like it's shared enough. And it's not something that everyone does equally. Somehow it seems like we need to do a better job of sharing it amongst all of us. I don't know. OK. Do you want to have any other thoughts?  Oh, there's two microphones. Oh, please. Oh, OK. You were first. OK. There's a bunch of media wiki code that's not really owned anymore because there's no core team. And so suddenly, if you want to patch that and get a review, in fact, no one is responsible. Not because everyone is responsible because literally no one is. Yeah. And that's a big problem. That's bad to put it mildly. Because we still need to make changes to these sections. Do you want to go? So a couple of things. I wanted to talk very briefly about my own experiences. One thing that I wanted to share is I'm not a very good code reviewer. I'm working on improving, but it's something that I think I will never be particularly excellent at. But at the same time, I try very hard to be available for ad hoc debugging of issues as they occur in production or elsewhere. And there are many times where I'd like to sort of green light something that seems stalled and would be more than willing and happy to sort of put myself on the hook for dealing with any fallout or anything like that that comes from it. But it seems that there's no currently socially acceptable way to take risks on patches, even when they're from highly valued contributors with a good track record. And that seems unfortunate and needlessly conservative to me. The other thing that I wanted to share, and I've brought this up into discussion on the task. So I forgot to introduce myself, by the way. My name is Ori. I'm with the performance team. I joined the Wikimedia Foundation to work as a MediaWiki and as an extension developer. But if you look at my commit record on two different repositories on MediaWikiCore and on Operations Puppet, you see two very different pictures. In MediaWikiCore, I have 300 patches touching about 21,000 lines in Operations Puppet. I have 1,500 changes touching 115,000 lines. And why is that? I'm much more interested in MediaWikiCore. It's much more related to what I'm supposed to be working on. So why this disparity? And I think it's because I experience MediaWikiCore code review as an incredible drag. People are not willing to take a chance on an idea if it's at all unusual or deviates in any way from established patterns. And it just does not allow you to build the sense of momentum and energy that you can with some other projects where you're actually allowed to merge your own changes under certain circumstances. So I've talked a lot. But the point that I was trying to make is that I think if you look at Operations Puppet against all expectations, it's actually a far more lively project. And I hope that that would motivate us to be more open to risk and to not discount the risk that comes with neglect and putting sort of barriers to contributions. So to summary, you're basically saying code review kind of saps creativity in a sense and risk taking and makes things un-fun. Hey, I'm Andre.  And then I saw Ryan's talk, and I was very thankful to see this. So in general, I see social, organizational, and technical aspects. And we already said we want to exclude the technical ones here. We have aspects that are referring to the reviewers and aspects that refer to the contributors. And looking at what I see mostly as things to discuss, of course, those ones that where not everybody will agree anyway, like, hey, let's improve the documentation. Hey, we need more reviewers. Should we have a more structured approach when it comes to reviewing code, like three steps and not starting with the smaller parts, like code style guidelines and so on? There was a blog post by Sarah Sharpe about that. How to increase our reviewer base if we need more skillful and confident reviewers. And also how to decrease exactly what was already mentioned, these areas where nobody really feels responsible for, and maybe having a role for media wiki core, a person that goes through all these patches that are rotting and tries to identify a person who should review that and feel responsible within a time frame that makes sense. So I think these are the most important ones coming to my mind. I think, yeah. OK, so I have plus two in skins, and I don't know how to review things. Is there anything telling people how to actually do it? I think that's a big problem is that code review is essentially instructions that basically don't screw up. There's some guidelines for obvious things you should check to make sure the patch works and stuff. But there's no deep guidelines about what's considered acceptable and what's unacceptable. Whereas the line, is there stuff that's considered unideal but OK, and stuff that's considered very minor? And if it really bothers you, make a follow-up patch, but it's not a reason to not merge a patch. There's not very good guidelines for what we want to code reviewers do. And the unknown-ness of it kind of makes it less fun to do code review because you don't want to be the one who plus twoed something that shouldn't have been plus twoed because you were mistaken about how thorough your review was supposed to be. And when other people don't have time to review things themselves, they definitely don't have time to teach other people how to review things. So yeah. Yeah, just I'm Dan from the release engineering team. So I'm responsible for maintaining, well, officially responsible for maintaining media wiki vagrant, although Brian Davis actually probably maintains it more than I do. So one thing that I've thought about doing, because I'm really bad with time management, is just carving out a space in my agenda, in my weekly schedule for code review, even if I find that there's nothing to review, I leave it there as a recurring event. I've thought about going to the extent of making that like an office hours thing. So leaving some time in my schedule where people can actually create appointments with me to actually do one-on-one review synchronously. I think the importance of that is maybe specific to the project because media wiki vagrant reviews are quite intensive if you actually want to test things thoroughly. Provisioning things from scratch takes about 15 minutes. So you do that iteratively, and that can add up pretty quickly for each review. So yeah, as one maybe social idea for that is something like office hours where you really carve out some time and dedicate a chunk of your time, whether you use it or not, for those reviews. Ready? All right, I'm gonna be the spoil sport who says code review is necessary. So on the security side of things, obviously I do secure review new extensions, new servers and stuff like that, but then it's up to you guys to make sure they stay safe, otherwise you have to fix them as security bugs. And so code review is necessary. I would love, I meant to actually run stats on how many security issues get found in code review. I don't have those numbers. If it is zero, then obviously we should reevaluate. I think right now it's non-zero. I definitely know of a few that have been caught in code review, so I know it's non-zero. So I know we do find bugs there. So it is unfortunately a necessary part of our process. I think it should be made better, standardize it. People who are plus one in, plus two in should, that should be, I think we are culturally a little too hard on people when they do make, no, we're a lot too hard on people when they make mistakes. So I think definitely plus one on that. Just to talk about people making mistakes. And one thing that it kind of seems like code review, like it's kind of the job that's very thankless. Like no one gets appreciation for doing code review very much compared to making patches. Perhaps one of the problems is there's not as much like prestige around like reviewing a patch versus fixing a bug. Or like, because the code reviews take on basically all the risk involved with the patch for none of their reward. Whoa! Yeah, thanks for the segue. My name is Adam and I just wanted to mention that code review is definitely as painful as it is. It's one of my favorite parts about this job. But the aspect of code review that I like the best is the communication and even training part. And so what I've also had happen is random hallway conversations where someone comes up to me and says, hey, that thing you did in edit page, what was that?  And that's actually, I can't say more valuable, but it's at least as valuable in a completely different way that allows me to then make more mistakes. So yeah, I feel like fitting some time into do actual training might be more effective if we even have a couple people, maybe a dozen people who are interested in a certain area of the code could show up and then whoever's been contributing the most in that could explain how that code works and the problems that they see, the ideas that they would like to follow up on, things like that. That's all. And we really don't have that for areas that are not associated with a specific team and for remote people and volunteers. As far as I'm aware, we have nothing like that. So first I wanna say I'm maybe strange and I actually really enjoy code review. I feel like I learn a lot from it. I get a lot of feel good factor out of it. Had one volunteer tell me, well I asked him like last year like why he contributes from over front and he said, could you review my code quickly? Like within like a day or so. So I think we really should be doing more than I think in the three, four years I've been here. Like I've seen very few new contributors and I see that as a symptom of a bigger problem that I'm really keen for us to rectify. I sometimes also feel like we don't retain them very well. Like we get input from like GCI and things but I feel like if we don't review things within like 72 hours, I think the chance of someone staying around reduces significantly because well like Wikipedia, right? It's built on instant changes and that's what makes it popular and models that don't have that tend to not work well. Yes, I think there's two symptoms which I think like before. I mean one like as we pointed out there's lots of repositories that don't have like maintainers like core is a very big chunk of code and it's very hard to like focus on certain areas. I mean secondly do we actually have like a definition of what's mergeable? I mean I've similarly like to already had really frustrating experiences just making code changes which all I do is refactor code and they just sit there for ages and then someone will find your review and they're minus one because I put a space in the wrong place in a for loop which is really stuff that you know it's not really helpful in code review like if there's something we can have in like some continuous integration to catch that sort of thing, that's good. Yeah, I don't know. I just kind of brain dump in my thoughts. I think the other thing about the fear of merging code is this idea that as soon as you merge code it rolls the train and it goes out into production. So I think there's something to be said around that like how can we, how can you be less concerned in our code review without worrying about break-in? So like have development branches instead? Yeah, exactly. All right, I'm gonna beat the drum I beat before about governance. Last July I wrote a blog post on mwestake.org about how Media Wiki needs a governance model and we really don't have one and I'll just quote this bit from OSS Watch, the OSS Watch Wiki, which says a clear governance model allows potential contributors to understand how they engage with the project, what is expected of them and what protections are provided to ensure their contributions will always be available to them. If you don't review people's code their code isn't used and you're failing. Again, I think that this is something that we really need to have a conversation about a governance model for Media Wiki for. I'm not sure I would classify this under governance. Well, I usually define governance model as more like how decisions are made at a high level rather than specifically like how we change the policy around code review less than what the policy actually is around code review. Well, we don't have that either. We have like a very convoluted like get consensus on Wikitech L and it's an ideal, but I don't know, that's kind of a site. The other thing is we do have the architecture docs as well which granted are in kind of drafty form but let's improve this. Although I guess ultimately I guess it's kind of a side topic already. I wanted to challenge Chris on the security angle. So Chris, you mentioned that code review finds a non-zero number of security defects and for that reason it is necessary. Well, right now our standard is to require one additional person with merge rights to merge and review the code. If we had upped that requirement to two there would undoubtedly be security defects that are then identified that we're not caught with a more relaxed process. If we upped it to three then we're liable to see the same sort of increase but I think we have to be very careful not to be biased in favor of what is easy to notice and what I mean by that is it's incredibly easy to say look, on line 35 of that patch somebody introduced a security defect and it was caught in code review. What's not so easy to pinpoint is there are vast sprawls of PHP code which no one currently involved with the project understands or is interested in maintaining and that of course comes with security risk as well and when our process becomes, when it drives off contributors then we incur security risk that way. See your counterpoint. No, I think that is a fair point. I do want to just clarify, I'm not saying that because we're finding a non-zero number of bugs that therefore we must do it. I think right now it is the only practical way we have identifying security issues post-release into production. We've looked at SAC analysis tools. They can't really look through our code very well. As a best practice, if you look at some of the security best practices, be some other things like that. Code review is actually like a very mature level of security. If you're actually doing code reviews that's actually a fairly mature level of security within your organization. So I think having a security review is a reasonable set in my perspective. I will totally evaluate it. I just think right now I think it is a reasonable trade-off between the security and just letting anything get merged. But again, I think we should do better about it and we should take more risks. But I think it is necessary. I just want to say, yes, there is a trade-off if we get rid of it. And I think it's a very reasonable one right now. Personal opinion. Also like from a security perspective, like I see if anything improving it would be to further probably standardize what you have to check for would probably help a lot with making reviews actually catch security issues. There's like some, where code review guidelines are actually around security, which most currently, but still it's not, like we can do that. Yeah, hi, this is Katie, fundraising tech. From my perspective, we cannot get rid of code review for PCI rules. So if the decision was made for MediaWiki to not do these things anymore, we would have to probably stop using MediaWiki or get someone to review the whole thing anyway, so. My personal opinion is that, like I think ultimately we have to, well, I don't know the summary, but I personally, I'm a fan of keeping code review, but I think modifying how we do it in possibly radical ways, and including a lot more structure and things is the way we'll help. But ultimately, it sounds like mostly people want to keep, I don't know. I think there's a difference between moving fast, breaking things, and letting other people clean up afterwards, and after a review, consciously taking a risk. That's a good point. Cool. Should we move on to talking about what we should do differently? Alrighty. So, so far there's summary. Does anyone have any specific solutions they really feel strongly about, begin with, that they wanna talk about? Looks like Lego does. So on the fabricator task, Brian proposed this great solution of making sure every patch to MediaWiki Core had a specific person assigned to it based on what area of the code it was in. And I think that's pretty key, that one person has to be, one or multiple people have to be in charge of a patch and going to shepherd it through the review process. And right now, there are places of core that have no reviewers, and we need to find reviewers for others, or reviewers and maintainers for those areas. One thing I'd point out also is even in areas where there are maintainers, there's lots of times where patches kind of seem to fall through the cracks. What I'd personally like to see is a structured system where each patch has a specific person responsible for it. And then, no matter what happened, it's like always someone is, there's someone who you know who to talk to if something is stalled. And someone who is ultimately responsible for getting the patch through, no matter where it is in MediaWiki. And how are you proposing to enforce this? That's a good question. Ultimately, I think first step is dividing up MediaWiki core into multiple sections and then allowing people who are interested to sign up for individual sections. And then this signing up and specifically saying that you're gonna be responsible comes with some responsibilities. And if you don't meet them, you get removed as the maintainer for that section. And we hope there's enough people who sign up to make it work and that they don't all get removed. I don't know if that's the best answer, but that's maybe, but maybe people would do it. If it comes with some procedure, yeah, like people want to be in positions of responsibility. I think people do lots of stuff for free on the internet because it has social value. Any other thoughts? So I never see the microphone there on that other side. One user interface problem that I think has been pointed out before and that we still have not solved is that there is currently no effective way of making non-blocking review comments on a patch in a way that both gets the author's attention but doesn't block it from getting merged. So I often find myself thinking, okay, I would do this a little bit differently or I think you might be better off doing this thing that way rather than that way. But it's not necessarily like, this isn't going to production on my dead body. I've found a defect. The problem is if you just leave those comments without a score, people don't see it and the interface is having been reviewed. And in the past, in fact as recently as today, gave a patch of minus one just to ensure that the person sees my comments rather than because I thought it was unfit for prod. Several points. So on the reviewer side, having a more structured review approach like as I mentioned earlier, actively check which people are using plus one, minus one in our current system and encourage people to get plus two to actually be able to merge. Cause I don't think that anybody's really checking if we have enough people who can actually merge or if that number is going up or down. Define a role to assign reviews that nobody selects. We already had that, especially when it comes to media wiki core. I think we simply need that. Also we need a review culture at least when it comes to WMF teams. That's something where I'd see maybe the team practices group but as much as there's daily standups, maybe there should also be like go through the unreviewed patches, especially those provided by volunteers. And last but not least improve the documentation both for reviewers, how to give good useful feedback to patch contributors and to contributors because there's pretty often a totally different assumption of what things are acceptable when it comes to not updating documentation or when tests break. And there's a huge gap of assumptions between potentially new contributors and what reviewers see as no goes. I just wanna come back to what Maxim said about your idea about people volunteering to look over code is kind of, it's great. And that works for Wikipedia. It doesn't work for media wiki because it's not happening. There's no system currently in place where like it's, there's people who- What would the system do? Like a system of you agree to do this and then they do that. Like right now there's some things, okay, there's a maintainers page that some people do but don't really follow through. There's no like social expectation that you actually- So what is the reward? If your people are going to do something for free, there's usually a reward. What's the reward? You get to call yourself a maintainer of this section. You get to call yourself a reviewer. Not many people like that. Question, have we ever tried anything like having sort of like office hours, something that's more of a live review session in IRC in which people who wrote the code are available at the same time people are reviewing things. So if there's a problem, they can correct it very quickly and actually have live discussions with each other. Has that ever been something that we've tried? Well there was code review day once but that's not quite the same thing. No. So basically no, we should do that. Cool. Let's see if it works, maybe it does, maybe it doesn't. Personally I've had a lot of success when I can actually in real time like synchronously have a conversation with somebody who's looking at the stuff that I wrote and then if I do have to patch it, we can do it very quickly and then it's done. So what Katie said does happen sometimes like at HUC but no it's not really standardized, it's not scheduled, it's not planned. But yeah, I have many times reviewed people just live on IRC. Just anecdotal evidence. We use Cloud9 once in a while and we do, we just go over that code review synchronously, get it in a good shape and then put it through Garrett and that works really nicely sometimes. So one thing we do sometimes and I can't really say in fundraising but one thing some people do is they merge patches if they're passable and if there's still issues they still comment on them and they just kind of rely on the author's goodwill to fix that up. So the visibility of those is a huge problem like Ori was saying I think. But I'm curious to hear from people who have experienced with the GitHub style feature branch development. Does that work for them? Because I would love to hear more about that because I really like the idea of just moving forward with a patch and then at the very end if you want you can squash it down and merge just that if you want it to look really elegant. Otherwise it's the real question is the final result what you want rather than is each intermediate step perfect? One thing I'd point out though is sometimes a lot of the problem is not coming to agreement on what the patch should be, although that's a problem. Oftentimes it's like the patch sits there, no one comments on it, no one says anything about it, no one touches it and like three months go by. So Brian, I'm in the reading team I guess. I don't know, does anybody know where I work? I think I work at the foundation. To Adam's question about GitHub style development, the composer merge plugin component that I originally developed and we're using in core. We have GitHub as the primary repo for it and my rationale for that was that I was trying to reach normal PHP developers outside the Wiki community to contribute and I can say that I have gotten a non-trivial number of enhancements, actually I have far more contributions from people outside the WMF and larger movement to that but there are a few key differences from Garrett that I find personally really crappy about GitHub. One, you can't do patch chains in GitHub so I can't propose two separate code reviews, one which depends on the other. You can propose them, you can have a feature branch that comes off another feature branch and put both of them up as pull requests but the second pull request will include all the changes in the first pull request and the second pull request so it's hard to compartmentalize a larger change that way, the way that you can in Garrett if you're stacking like four or five patches that build to a final point and then the other thing that I find truly horrible about GitHub's code review process is that often in Garrett if I'm reviewing something especially in MediaWiki Vagrant and there's a couple little nitpicky like, oh I'd like to see a tab here or a space there or this comment isn't quite right, I will amend the patch and merge it and move on or on a larger work that's not ready for merge I may even just, I may add a small revision to an existing patch that fixes something that I'm concerned about that there's been some discussion on it and I think it's ready for it but the developer hasn't had a chance to do and GitHub's pull request model does not allow that you can't take over somebody else's work or collaboratively work on a single change set that will eventually get merged together. So to speak a little bit to what Matt was asking about GitHub style pull requests, I think this is one place, without getting buried too much into the technologies which we don't wanna do, I think this is one place that fabricator kind of gets it right, it kind of straddles the difference between Garrett and GitHub in this regard, like it totally gives you the idea that a change is somebody's but at the same time it gives you better tools for creating dependencies between them, a lot Garrett, it's not quite as strict as the way as Garrett does it because Garrett does it strictly based off of the Shaw one in the branch history but you can indicate dependencies in a way on fabricator that you can't with GitHub. So I think that's one thing worth mentioning. The other thing is that I can't remember at this point so nevermind, I'll just leave it at that. Super small, super specific concrete proposal. So we may not be with Garrett forever, that's fine but I'd still like to see even if it's only for a short while, plus ones eliminated. And the reason is, so there's a bugzilla quip in which I think MZ asks what does a plus one mean anyway and Tim famously replied, reviewer has a working mouse. I think the plus ones do have a legitimate use case and that's for very controversial patches where you really want to establish consensus, it's a way of saying I'm for this but I wanna give other people a chance. In those cases, it would be I think less obvious from an interface perspective to just indicate in a comment like plus one but it would eliminate a huge use of plus ones that is not legitimate in my opinion which is, oh, can you review this patch for me? Sure, I did, plus one. Yeah, it's almost like a like button. Yeah. I've personally found that when I see a patch with a plus one, it doesn't necessarily mean it's any more likely to be good. If anything, it's slightly less likely to be an okay patch because usually what happens is it's, someone isn't getting the patch reviewed because it's very complicated so they ask their friend to plus one it. Seems to be like a trend I noticed sometime. I totally ignore them with an interface. And I think this is another area where a differential fabricator actually improves this is in the signaling. So we have to remember that we shy off from talking about technological solution sometimes but we have to remember that these technologies actually embody the way that we're communicating. So Garrett actually only gives us very like binary ways of communicating to each other that this has problems or it's ready to be merged. And like you said, a plus one is pretty much meaningless. Differential allows you, it signals these things differently. So when you comment on something, you don't give it and it's just purely a comment. You're not saying this should merge or it should not merge. It signals that is just information. So it's a very neutral way of telling the user, the contributor that there's information that they need to go look over and it's very neutral. So that forces the reviewer to actually give substantive feedback rather than just sort of this binary signal. The other thing about it is it puts the impetus for puts the responsibility of merging on the contributor and security implications aside and other implications aside. That actually makes it easier on the reviewer as well because they don't have to worry about knowing whether this patch is actually ready or to be reviewed and merged or if it's sort of a work in progress because those things aren't always marked either. So I have that problem a lot with media wiki vagrant. I'll go start reviewing something and somebody will comment really quickly like, wait, wait, I'm not done with this. So I think it improves those two sides of it, at least. Yeah, I just wanted to mention the main reason I wanted to shy away from technology thing is I don't want to be limited by current technology options. Like if we determine that the best way to do something is something we don't support, then the answer is to support it, not to limit to what we currently can do, I think. Sorry, I'm too short. I just wanted to point out, I don't know if it has to be by a plus one necessarily, but I do, this is like one reason why plus one might be actually useful. There are some cases and quite a lot actually where we have someone who is maybe more of an expert in one maybe type of thing where we would like to make sure that they give us their opinion, but they are not necessarily understand the code base enough to plus two. So for example, I'm sometimes asked to check things for right to left support and it might be extensions that I don't work on so I don't feel comfortable to plus two and I don't necessarily know if the library is being used correctly, if everything is okay, so I might leave comments about the code, but I don't feel comfortable plus twoing, but I do want to expressly say, yep, it works in right to left, got my stamp of approval or whatever. It doesn't necessarily have to have plus one might be in a comment, but sometimes comments get lost, especially if you continue discussing something. So it's something very useful to see that that person that understands whatever language or directionality or UI or UX gave it its plus one. And I certainly see that use case with C brand plus ones. Well, my code doesn't give very many design reviews apparently, but that's probably not a good thing. But yeah, I do see that use case sometimes, although often a comment would suffice, but in complex cases I could see why. So to answer Ori's question a little bit ago about numbers in terms of review, all of that is ultimately, I hate to use this because it's a cop out answer, but all of that's configurable. So if we were to come to consensus on a better set of metrics other than negative two to plus two, that's not something that we couldn't change. I generally agree when it comes to plus ones.  I've always likened it to Facebook likes. It matters about as much as a Facebook like in that it doesn't. I do see the use case for wanting to be able to chime in and say, yes, I've reviewed this for the parts in which I feel competent, but I'm not competent to fully merge it all the way through the cases like localization review or design review. Somebody comes along and says, this part of it is okay, but I don't wanna be responsible for merging it. And I think part of that is due to the workflow that we've built ourselves into in Garrett where plus two approval also implies merging. And that's not a good thing. I think we've kind of boxed ourselves into a corner there where nobody wants to come and review something because at the end of the day then it's going to go all the way through and end up on production. And then when it breaks, then they come back and say, well, why did you plus two this? Well, I thought it looked okay. As opposed to it being the responsibility of the person who was writing the code to begin with. Fabricator like Dan was saying gets this right as opposed to like instead of just putting us into little boxes where we have numbers that mean different things to different people depending on the context. Like Fabricator, when you respond to code review, like it's always asking for some sort of action as a result. It's either this is good, you can go ahead and merge the style or it's this is not good and here's the things you need to do to make it good. Like there's a whole series of things that you can possibly do and it's not just in nebulous like plus one minus one score that you then have to interpret as a author of the code. And so I think that's one thing we can do better both in the glorious Fabricator future as well as hopefully Garrett more immediately. Yeah, hopefully like making it less risky will hopefully mean more people do it too. Code review that is, at least I hope so. So picking up where Chad left off, in fact I use plus one and plus two in yet another fashion. Plus one when I give it means I've read it, I reviewed it thoroughly, I have not tested it. Plus two means I'd merge this right now and take the rap if there are problems, if you weren't taking responsibility yourself and in some cases I will in fact, someone else will say, hey, can you use it? I'm like, yeah, I'll even plus two and I'll merge it, do you care? And they're like, no. And so then I take ownership of it at that point. That's clearly different meanings that I'm hearing from other people but in that framework plus one makes perfect sense. I wanna preserve that, that I don't want to have had to test something before I give my review that says I like it, that I looked at it carefully. I was just coming up here to say the same thing. We'll persist across multiple catch sets, plus one and minus one will disappear if it's any, you just go along and say plus one and don't give it any comments or context whatsoever and then somebody comes along and revised the patch. You will never have that review again. Yeah, I have a few things to say. First, don't rely on votes. They're like, yes, there's plus one plus two but you also have to leave comments.  But you have to leave comments. Like you have to explain why you're leaving a plus one. Yeah, the second thing is Mark and Max talked about that no one will be motivated to review stuff like volunteer and like Brian's proposal. And I'm thinking that like we need to give reviewers more recognition like right now no one notices the reviewer. So like we can put a list of maintainers on special version. Like we have the list of authors. We can also put the list of reviewers and maintainers and like, you know, the kernel does like signed off by in the get commit message but Garrett puts the reviewer in the get note. So no one sees it unless you use get blick which no one does. So like if we can make the reviewers more prominent and I think differential right now is putting the reviewers in the get commit message and that's another way to give them prominence. And then my last thing I wanted to say was that along with Brian's proposal I think it would be a good first starting step is like we already have a Garrett reviewer bot that automatically adds reviewers based on the paths changed. So if we can make sure that at least one person is assigned for every single like file or directory and core that would be a huge starting step to making sure that people have responsibility. And I think like we can go through the current list of the people who are added as reviewers by default and see which directories are missing people and which directories already have people. One thing I'd like to say about ensuring people get a recognition I think we should like I remember in bugzilla days we had like a report that got emailed to wikitec l regularly that included like the top five bug closures. And I think that inspired people to fix more bugs to try and get on the list. At least it inspired me at one point or another verification. Yeah so like a similar thing with I'm not sure if everyone's familiar with Nemo's code stats. It's a list of how many people have reviewed even plus two patches in the last month. Like something like that emailed regularly to wikitec l and maybe also something dividing the code into sections and saying how long the longest patch open in each section is. Assuming we somehow get rid of the trend where we just instead of rejecting patches we just let them simmer forever and ever. But I came up here mostly to say the same things that Chad said so I'll just plus one that. But essentially I think that the biggest impediment to myself doing code reviews has been the automatic merging. Like there's been a whole bunch of times at least at least 10 times that I have plus two something and then later on I've been like slapped on IRC by somebody saying why did you merge that or why didn't you deploy that? Because I didn't know that I was supposed to deploy it because certain repos have this implied you must deploy if you merge and it's not exactly explicitly shown in the UI anywhere or I'm not even sure where I would look to find that out. And so because of that it's demotivated me from reviewing things because plus two implies that I'm gonna get slapped at IRC for approving something that I shouldn't have and I don't know why. So that's the biggest, yeah demotivator just for me personally. Yeah well this discussion like about plus twos varies a lot depending on the repo we're talking about. Like I've mostly been talking about Meteoriki core generally but like in the Wikimedia Configure is a totally different kind of conversation in a way about reviews for that repo. Well there's also another reason why people do plus one things. They don't have plus two. So what are they supposed to do? And from what people are saying it's not just pointless for them to plus one things they can actually be counterproductive from the sound of it. It's more like it's very meaningless and if someone plus one's it who I've never seen before or heard of and their only action on Garrett is plus oneing that patch. It's often not a good sign honestly. I don't know but like usually I think the trend is sometimes people try and force other people to plus one their patches and hopes it helps things and then it's just like a side effect that sometimes when you see a plus one it sometimes is like it's the opposite. Another way in which it can have a signal value opposite than the one that's intended is okay so plus one tells me that someone liked the patch enough to endorse it but was shy urging it which means that it might be risky if someone was hesitant to actually have their fingerprints on the trigger. So one way I've used plus ones in the past is at the comment I reviewed this please merge because I didn't have the permission. Another one is but making a plus one useful always involves adding a comment saying what you actually reviewed. Yeah. Okay, anyone else have anything to say or should we? Yeah, that's kind of what we're doing. Yeah. Already, well I guess nobody has any other specific things they want to say. Now would be a good time to kind of look over maybe the list and see if anything, I don't know jumps out as invoking strong emotions I suppose. I guess starting from the beginning. So like talking from the summary thing so how do you find how does a review or find reviewable patches? That would be, I guess the obvious solution of the ones we talked about is breaking down core better into areas and a lot of that's very tied to technology also with like querying and Garrett which originally we weren't gonna. Can I interrupt a little bit and just talk about like the so part of the reason for doing so the thing that I, the reason why I've been going with the question format only is because like it's the clearest way I think to not stop conversation is to just basically put the questions in the summary and not the answers and say like that the answers are in the transcript, right? And then later on and so maybe one of the things that we can do as a wrap up on this is like are there questions on here for which the answer is obvious or are these all like tough questions that deserve more discussion? So I don't know how to do that sorting but that's that I think that's part of it. If there are questions on here that leap out as like the answer is obvious maybe we can we can actually put that into the obvious category and say what the answer is. Did you want to? Well to me the answer is obvious to almost all of these and it's fabricator differential seriously. One specific thing though is breaking up core into you know like ownership areas assigning people to own pieces of code. Fabricator has a tool that we can use right now to do that and it's called owners. So you should go on there and look at it. Would we actually use it as the thing? Well we could and we could right now. We can do right now we can. Right, yeah that's called action right now. Everybody go into fabricator find pieces of code that you're interested in or you're able to review, create an owner's package. If you need help doing it talk to me either here or an IRC and I'll help you do it. But like even before fabric we could always do that. We could have done that in SVN days if we wanted to. But there's tools to help us do it and to formalize it and why not use it. Tools don't necessarily mean we actually do it. Right, but we could actually do it right now. So basically you caused me to introduce another question to the list which basically means no we don't the answer's not obvious. There needs to be another further discussion on it. But the reason why I'm saying like that like asking is there anything where the answer is obvious? It's like is that if it's like something where somebody says yes of course. So for example let me just try to find one really quickly that I think was a really obvious choice here. So I mean these are all tough questions right? I think one of the ones that no one disagreed with was that we need code review guidelines for both contributors and reviewers. Office hours, okay so let's see here. So which line number is that? Okay so 42. Right so okay right. Anybody object to that? No, all right great. Any of these others that we should do that for? Well maybe there is an action. So are there action items like is there? Is there? Okay. Scheduling office hours. Yeah anybody want to volunteer for this? Cause it's like it doesn't make sense to put up an action item that nobody's going to take on. I wanted to talk about the like when McKinney was saying about the owner's thing. As I've said elsewhere the problem is not technology, it's a social problem. We have a list of maintainers like on mediawiki.org that people don't update. Summoner used to update it. So like we need someone to go through prune the people who are not actively maintaining those areas add the new areas of core that have showed up since that list was last updated and nag people to take responsibility for certain areas and then convert that list of like the areas based on whatever that list is to actual like code paths. So people will be in like in charge of like you're going to assign people specifically to a patch based on what code it touches. And I am willing to like do the effort on that. And of course I'm going to get. Can you scroll the right path now too? Oh yeah okay. So I'm going to quickly throw a wrench in Canals suggestion. Well I think you should. Not act on just in his spokes. But so part of the part that would make this actually use so right now we have all this right. We have you can edit that wiki page and Garrett will automatically add you and you know we have the maintainers page and we can update that but then what right. I think we need an actual dare I say guideline policy thing on you like what we were discussing before about you know there is responsibilities with adding your name to this list and how to get added to that list who you know all that kind of stuff. So maybe we can talk more about delay that to a different discussion I would assume and yeah. Yeah well I think it's kind of both are important in a way like it's important to have a list that someone can go to of areas where at least this person knows about this area of the code and is reasonably active in media working development still but that's kind of a separate thing from having a list of people where the buck stops here for getting code review done and social responsibility is what is needed there. So stop me if this is totally out of scope but it seems to me that we should calibrate kind of the effort that is being spent on this list. These are good questions. They're gonna be hard to answer. They're gonna take a long time and effort. I mean look at Linux right. It was reviewed over email by a jerk you know like. So and it works and it's scaled to like ridiculous proportions and we don't have these proportions. We have very few contributors from my you know objective point of view I think. Maybe we need to think about what other stuff like make the code more fun to work with and. I'm not really familiar with how Linux does code review but I'm given to understand that they have it kind of split up into components right. And like. I'm not talking about now like in the early days right. And I'm saying it's possible to be successful despite like really horrible experiences in code review and it's not necessarily obvious that making code review awesome and fun and perfect will improve like the stated goal of the session like the number of participants. Although I'd point out there's a difference between like indifference and kind of hate as a negative experience. Like in some ways indifference is much more sapping than someone who's mean. Cause indifference means no one even bothered to respond. And that's in some ways I feel like that's more demotivating than people being assholes. But I don't know maybe not. Are you all saying I believe that? He said there's a very lots of prestige with being a kernel contributor and not as much with meteorokin. Is that good? Yeah, so you're. Yeah, so people are more likely to suffer through it. And that's something we can use when we think about how we make our code base more fun to work with. Like maybe people just really don't feel like they would contribute to society if they add, if they make media wiki core better, maybe they wanna work on the front end or maybe they wanna work on something else. So we should figure that out and focus on those areas first. So the owner's list thing again, it was said it's social and not technical but it's kind of a combination of both. Because as it is right now we have the list on the wiki but it doesn't have a direct effect. If we were using the fabricated differential thing we would have the owner's list and it would directly, if you were the owner, you would automatically be added to review on any relevant patches. So there would be an actual immediate reason for people to keep that up to date. So that would be one of those cases where a. People use reviewer bot but that doesn't necessarily mean they review everything they get. Well, true. But if we're going for a comment of people won't follow the policy then nothing we're gonna do is going to fix anything. My point is more the policy currently is not just because you added yourself as a maintainer you even have to do anything to maintain it. Like there is no policy currently. Well, fair. So a long time ago we used to do code review here via email and it didn't scale for us. The reason being is we don't have proper breakdown into packages in the way that the Linux kernel does. The reason that that is scaled for Linus and everybody else there is because by the time by the time Linus reviews a particular patch to Linux like it, it's already gone through several layers of gatekeepers at this point. So he's basically at that point rubber stamping what other people have already reviewed. We didn't have that when we were doing it via email. So doing it via email didn't scale. And I think the problems we're having inherently come with lack of ownership over different parts of the code base. I don't think using a particular tool solves it by itself. And I think we really do have to have the sense of ownership in the way that we're talking about over different components of the code. And there has to be a clear process as well for removing ownership as well from somebody who if I claim ownership over a part of code and I keep getting added as a reviewer to stuff and I never review this stuff, like then we need to have an escalation process at that point so somebody else can step up and take over it just so we can't just say, well there's a reviewer but he never does anything so oh well, because otherwise we're kind of in the same situation we have now with doing it ad hoc via Wiki. The problem with that is you can show, you can be interested in code without taking responsibility for it. Like there's a lot of things that I add myself as a reviewer on but I'm never gonna review it. I'm just mildly interested in keeping an eye on where it goes. Like I automatically get added to every single configuration change. Like I'm not gonna merge and review every single one of them though. So I think it's a matter about, it's about getting people to really take the ownership of something once they've declared an interest in it and then having a way to say, I really don't care about this anymore and somebody else needs to step up and take over. Cindy? So what I'm trying to do to make this more concrete for me is apply it to my own particular situation right now where I have a patch that's languishing and would like to very much to see it in some form or another merged. So with the discussion to date, the ownership issue is a huge one here because it's not clear to me at all who the person is or should be who's responsible for the area in which I'm trying to apply a patch. And this patch started out as a new class. And so where it's clear when you're editing an existing class that there might have been some path of editors responsible for the bulk anyways of code in an existing class when you're trying to add a new class it becomes a little bit less clear who would be the appropriate person to have ownership of that type of feature. So the ownership issue is definitely a big one but it's more complicated than just who's responsible for this particular bit of code especially if you're trying to contribute something new. And then the other issue is an architectural difference between whether something should be implemented as a separate class or as new code added to an existing class and I have had two versions of my patch. I abandoned the first one as a separate class and then created another one where it was code added to an existing class. And there's no decision, I don't know who to go to for a decision on which because there are absolutely valid reasons for both approaches. So it's really more what's needed is some sort of architectural guidance. Are we going in a particular direction with the code base where features should be added as object access classes in which case existing code should perhaps be modified but also new things should be contributed in a particular style. So it becomes unclear when new patches are being asked to be added in a particular architectural style that's not yet common in the code base and who arbitrates those decisions? Who owns that? And so again, it may be more complicated because of a third party contributor and so I don't see you all every day in the halls and so I can't just chat at the coffee machine but I very much want to contribute and be a part of this wonderful code base that we're developing but it's unclear to me how. So is that 10 minute warning you mean? Yeah, okay. Yeah, I think it's very important to have some guidelines about like not just what is the best way to do things but also what is an acceptable way to do things and when we're transitioning to new, like when we're transitioning to new, like say dependency injection, I missed the session but it'd be like we'd have the guideline and then we'd have like modify the guideline too. Now it has new code has to use this or maybe new code preferred to use this but if someone submits something it's still okay as like just very specific guidelines about what's considered okay and what is not considered okay instead of just what this one person would like to see versus this other person and it ends up random depending on who happened to review your code. As for owners, I would also like, like if we do divide into owners I think we'd have to have like a catch all ownership for things that aren't currently in a component with hopefully with everything componentized that would be a very small amount to code because otherwise it'd be unworkable if it's like 90% of media work is ownerless. Greg? So my project manager self is freaking out still about the lack of action items or more action items on this. That's a good point. Yeah, I still feel like there's one about the ownership discussion, right? And we only have one now that's about updating the maintainers wiki page. That's as far as it goes though. So is that something that we want to make more movement on? Is that an RFC? Is that a what, right? So, I guess let me respond on that. I mean, I think there are things that we could have done prior to the summit to figure out how to make sure that we have better action items here. But we can't, we don't have access to time travel technology. So we can't do that. So that said, I think the thing that we can do is like some of the action items can be figuring out how to follow up on this list of questions. Like prioritizing the list of questions and figuring out which ones are the important ones to move on, which ones aren't. I mean, if this meeting wasn't useful, then that's fine. We don't have to make this meeting useful. That's not the most important thing. The most important thing for us to do is to improve our code review process, right? So, I'm not as worried about the lack of action items here as I am without, if we're not getting clarity on what the challenges that we have are. I think it's a little more clear in my mind what the challenges are. Yeah, as long as there's someone on point for doing that review, I guess, Brian. I guess that's me. If I was to add an action item, I think it would be for someone, possibly me to write up a more formalized proposal for owners and what precisely that means and like talk about it on Wikipedia L and start an RFC about it. Part of the challenge is that code review has to do with the rules and regulations of how we interact around software development and it's very difficult for any individual or any group of individuals, unless they are invested with some kind of special and formal power to actually change that because it's sort of meta. And in light of that, one recommendation that I would make is that we agree that code review is a sufficiently severe issue that we should appoint some small committee to study and analyze it in detail and to make binding recommendations about how to change it to the whole community. That's interesting. Actually first, before we go there, just by a show of hands, who here thinks there's a problem with code review as it currently is? Okay, just one double check, like. Okay. I don't think so. Yeah. I don't know. I think it's just fine. Anyone? Maybe it's just mildly annoying, but not that horrible. Yeah, very bias, selection bias. I think my point earlier was more that it, maybe it's bad, maybe it's really bad, but that there might be much more return on investment working on other parts of the problem that, where the problem is having lots of people start contributing on our code base and engage with us in a real open source way. Could you go in more details what you mean by the other problems? Yeah, so the way that, if as a front end developer, if I wanted to work with a front end and I try to understand it, it's a fragmented, non-standard, non-modularized, non-componentized mess.   It's a big code base that's mature and has. I'll give you a concrete example. I tried to help with visual editor and I think the code base is actually really good and the architectural documentation is really good. I read through a lot of that stuff. I understood a lot of it and then I went to Garrett and I tried to find a patch and I talked to James and I know James, which is a huge advantage and he's like, no, there's nothing to work on. So, and I doubt that's the case. That doesn't sound right. I mean, it's a big project and I'm sure there's something to do. So I think there's some step missing from a total newcomer's perspective to actually participating. There's like a gap there that needs to be filled. When he said there was nothing to work on, did he mean there was nothing to review? No, I just generally wanted to help like write something new or whatever. And that could be a reflection of James' opinion of me and he didn't want me to. Yeah, cause I don't believe that there wouldn't have been things in visual editor to do because we have roadmaps for stretching into the 20s. Yeah, this is, okay. But we keep on top of code reviews so it is actually plausible there wouldn't have been anything to review because enough of the team reviewed cross reviews that that can happen. Okay, so we're running low on time here, I think, like four minutes. So does anyone have any specific things they wanna get off the chest before it ends? I also think in whatever planning we do to come up with good solutions, we should talk with teams who do a good job of code review because there are some teams that are actually really on top of code review and actually have volunteer contributors that actively contribute to their code bases. Maxsem wants to know examples. Like mobile team that used to exist. I think what that comes down to though is ownership. Like a lot of stuff in MWCore isn't owned by people and probably a reason why we didn't always have a huge code review backlog in visual editor was because it was clear that that was the thing that we owned and that if you were on a team you were gonna review something that was what you were gonna do. Yeah, so I guess what you're saying is teams that where there's a very specific boundary where they're specifically responsible for the entirety of an extension do well. I'm not saying that they necessarily do well but I think that is an element that makes them do better than MWCore, which as a thing is not owned by anybody. One thing I'd like to say, like I really wanna make sure when we do owner thing it's not necessarily like there's a WMF team that owns every kind of, like I want it to be whoever owns it. Maybe people work for WMF team, maybe they're not. Maybe it's something they do on the side that they care about. I don't know. And I guess it goes beyond ownership it's a maintainership because the visual editor team doesn't just own visual editor as a thing they grudgingly take responsibility for. Everybody on a team works on a software every day and so they are naturally predisposed to reviewing stuff there because it is easy for them to review and comprehend the code because they work on it every day. So it's more maintainership than ownership maybe. Yeah, okay. I have a follow up comment to that. I think one of the things that we can look into is other organizations taking on ownership of pieces which could involve us pulling in code from other organizations rather than inventing the wheel ourselves. I don't really consider them an external organization. Yeah. Already, I think, okay. Already, so last final chance to comment on anything? Anyone? As I think that's, yeah. Hopefully this was useful at least got people thinking about it and yeah, I guess that's then. I guess that's then. And hopefully I probably will follow this up with some post to Wikitech L about things that were talked about here and the more popular solutions and hopefully we will implement them eventually.


Luke's a big part of this team, big part of this offense. He brings a lot to the table, a guy that's going to hit in the middle of this lineup. His for power uses the whole field, solid guy over there at first base. And he's a really vocal guy in the clubhouse that gets us motivated. So we're going to be missing out on that for at least a month. But I'm excited to have Jay Bruce on this team. This is why he came to this team, was to help any way he can and help us win a championship. So we're going to be missing Luke. But I know Jay Bruce will come in and he's going to do some special things for us. Man, I get here at the stadium. He's beating everybody to the stadium. He's one of the first ones here. He's always in the weight room, always working, always prepared. And that's what you want, especially a guy like that, a big part of our team, a big part of our offense in the middle of the lineup, playing first base, always in the action. You want a guy like that that shows up ready to go. And it's the things like I was saying earlier, being outspoken and motivating guys, telling us when we're down the dumpster, we're feeling sorry for ourselves. We're like, hey, let's go guys, we're New York Yankees. So we're going to miss that. But I just wanted to get healthy as we can. And we got a lot of important ball games on the road. I'm ready to go. I think we've been ready for quite a while now. It's usually these last couple of weeks of spring training are tough, more mentally, I think, than anything. And we're trying to fine-tune the last couple of things before we get to the season. Because when it's April 1st, it's go time. There's no more time for let me fill this out. Let me get some work. It's go time on day one, because I know the Blue Jays are becoming porous. And we've got to bring it to them. So I'm looking forward to getting to New York and getting back to the stadium. Consistent hard contact. I'm seeing him really attack the pitches in the strike and he's taking his walks when he needs to. Here in spring, when guys don't want to face him after he hits two balls, 120. So when you got a guy like that that's, when they throw to the plate, he's going to do damage. And when they don't want to pitch to him, they'll take his walks. That's when you got something special. That's when Big G, when he's healthy, when he's right, when he's in the lineup, that's what he does. That's what he brings to this team is that dynamic of, he can drive guys in, but he can also get on base for the guys behind him. I mean, in Hixey, man, we've got a great relationship. That's a guy that when he's on the field, he's doing some pretty amazing things, especially playing center field, the ground he can cover, being able to switch hit, hit for power, gets on base. He's our number three hitter. It's great to see him in camp, in shape, healthy. Because when we got him in our lineup, it makes this lineup so much more dynamic. So that's a guy that can continue to kind of roll, gets walked, gets on base. Somehow it's getting Big G, if he's sitting fourth, gets him a chance to hit in the first inning with a guy on base and could end up being to nothing in the first, just like that. So seeing what Hixey's been doing so far in spring training has been pretty amazing. And we just got to keep that rolling because when we got him in our lineup and out there in center field patrolling, it makes us even more dangerous.


Hello, and welcome to Data Diversity Talks, a podcast where we discuss with industry leaders and experts how they have built their careers around data. I'm your host, Shannon Kemp, and today we're talking to Mark Horseman, the manager of data governance at Alberta Motor Association. Hello, and welcome. My name is Shannon Kemp, and I'm the Chief Digital Officer here at Data Diversity, and this is my career in data. A Data Diversity Talks podcast dedicated to learning from those who have careers in data management to understand how they got there and to be talking with people who help make those careers a little bit easier. To keep up to date in the latest in data management education, go to dataversity.net forward slash subscribe. And today we are joined by Mark Horseman, the manager of data governance at Alberta Motor Association, and normally this is where a podcast host would read a short bio of the guest. But in this podcast, your bio is what we're here to talk about. Mark, hello and welcome. Hi, it's wonderful to be here. I'm so glad you could join us.  You've been a long time friend and engaged in so much that we do. We really appreciate it.  Yeah, manager of data governance. So AMA brought me on board. The Alberta Motor Association brought me on board to spearhead a data governance program. And that's something that I've been doing a lot of in the past few years. So I've been working in higher ed before then. So at the Northern Alberta Institute of Technology, I've also did a number of years at the University of Saskatchewan. And I had a brief foray into the private sector at Vesema Networks, where I managed some data for them as well as as well as an applications team. So, yeah, the ebbs and flows of how you work in data is interesting. But currently, my chief responsibility is operating a data governance program, defining what that program is, how it works for the organization. And generally, I drink a lot of coffee and talk to folks, which is largely what this job kind of is for me. A lot of coffee. You can see it in my eyes. Coffee. I can so appreciate that. I've had a bit myself. The feel of it sustains us. Yep. Well, I love that you're starting a data governance program. We'll come back to that. But so tell me, Mark, when you were a little boy, is this what you wanted to be when you grew up? Like, did you dream of being a manager of data governance? No, I don't think when I was a young person, I'm secretly old.  But when I was a young person, we didn't have the internet yet. That wasn't a thing. So the amount of data management things that were going on were very limited. And I was sitting there connecting to bulletin board systems with a 2400 BOD modem. So maybe I'm dating myself a little bit there. I actually had a 360 BOD modem at one point as well. Anyway, actually, I wanted a career in the sciences. And so going to university right out of high school, I just took all the sciences and then did the best in computer science. So stayed in that one. And that kind of launched a lot of career things for me. But before I got into university and during university, it actually worked in sales a bit, selling computers to people. And a lot of what we do today is very sales related. We're in the business of selling ideas and selling the way that things can work and selling breaking down silos. There's a lot of sales that we do. And one thing, if you remember anything from listening to me drone on about data management and data governance is read a sales book, any sales book. Just grab a book about sales because we're in the business of selling ideas. Oh, it's great advice. So you majored in computer science. I love it. So where did you go after that? And how did you get from there to to where you are now and into data? Yeah. So while I was in university, I got into an internship program at the university that I was attending. So that was at the University of Saskatchewan. And my first project in the nineties, which is cool, was working on identity management. So that was well before identity management and customer data integration and entity resolution before all those things were cool. U of S was way ahead of the game and and I got to work on it like right away. So that kind of really started my my path into understanding how data plays between all these different enterprise systems and and all the rules and processes and things that kind of happen along the way and working on various student systems and understanding instructors way back in the day. I wrote an article called Doctor Who, like who if your class doesn't have an instructor assigned to it, what does that mean? So there's a lot of interesting things that happen in that world. And then you just I just started that slow, gradual climb into data quality and then from data quality into more master data management and the master data management into data governance and starting to define the processes around managing things. And yeah, and then the rest is is history, as they say. So with with a lot of technical work in the background and then moving away from technical stuff and then graduating into more leadership style positions working in the private sector was fascinating for that. And then being able to hone and repeat by moving into the Northern Alberta Institute of Technology, which is a wonderful organization and and now working with Alberta Motor Association, again, another wonderful organization that's very much supporting data management. These days and and just everybody's been patient and wonderful and and really wants a data governance program in place. And so, yeah, the sales the sales tactics work. Yeah, again, great advice, because, as you know, we have so many people who struggle with, you know, how to get people on board and how to get buy in to their programs more than anything else, more than building the processes around the data. It's it's getting the people to collaborate, right? And in sales, the one thing I learned early is nobody's as excited about what you're excited about as you are. So being able to sell that excitement and being able to share why things are exciting and share why things are important and tie it together to your customer or your executive in this case is what's going to get you some success. So I don't mean it like glibly, like definitely read a sales book. Any sales book will definitely help. I am with you. Is there one in particular that you recommend? No. My library is downstairs and my ability to remember titles right now is limited. So, Michael, what is your definition of data? And how do you work with it? Yeah, so this is one of those things. Everybody says, well, what is data? What's the difference between data and information? Like you get all sorts of different conversations out of this. And again, because you're always looking for buy in and and to share some understanding, data is just stuff. It's stuff. It's just things that are out there. It has no context, generally. It's just stuff. It becomes information when we apply context to it so we can use data to create information and information has meaning and we can use it to make decisions. That's wonderful. But yeah, the data that's out there is just stuff. And how do we work with it? Well, some stuff needs to be managed differently than other stuff. So certain things may have a legislative component to it. So if we are collecting social insurance numbers or social security numbers in the States, we may be required to encrypt in place, for example, or like credit card numbers. So that's a credit card number is a piece of data. It's not attached to anybody, so it's not really information, but it's a number. It's a useful number, so it must be managed appropriately. So yeah, data is stuff. Different stuff requires different methods to manage. It isn't really information that you can use strategically until you provide context. That's great. And we haven't really talked about this in advance, but since you're so ingrained in data governance, what is data governance to you? Because so many people think it's just about adhering to laws. Yeah, and some folks are like, just manage the business glossary, like you get a lot of that as well, which is an important thing to do. Also an important aspect of breaking down silos and having conversations about what stuff actually means, even if you get down to the nitty gritty English language definition of something and spend a whole day describing what a student is, for example. Still an important discussion, but data governance at its core. Bob Siner has a great definition. I think I just glommed on to an older definition that he used that was a little bit punchier, but it's executing the sovereign authority over the management of your data and data related assets, something like that. I might be paraphrasing a bit. I just like the word sovereign authority. It's just a little punchier. But yeah, it's really it covers that gamut of, you know, we care about this stuff, so we're going to manage it like it's an asset. I think it might have been John Ladly.  And you're like, oh, we've tagged this urinal as an asset. So somewhere there exists a database or a spreadsheet or something that describes this urinal, shows what maintenance has happened to it, shows everything that's happened to it. So why don't something like that for credit card numbers? And is that urinal necessarily is important to our organization as our data for making strategic decisions about how we operate? Well, maybe for a minute. But yeah, data governance is really about everything involved in managing that data. What are the rules and the rules of engagement for doing these sorts of things? How are we doing it? How are we communicating it? Who's the the owner of those things? How does it percolate through the organization? How do people engage? How do people read and learn all of that stuff? Kind of is either related to or operated on by data governance. Ready to mingle with your fellow data governance practitioners? Join us in Washington, D.C. this December for the data governance and information quality conference. Five days packed full of new knowledge, new friends and new strategies are yours. When you register at djiq 2022 east dot diversity dot net take advantage of our super early bird pricing when you register before October 7th. I I love that. I love the description. Makes a lot of sense. So, Mark, you see the importance of data management and the numbers and the number of jobs working with data increasing or decreasing over the next 10 years and why? What I'm seeing nowadays and just talking to friends out around Alberta right now, because that's where I'm at, but talking with friends out in the wild as well. You're seeing a lot more people with the skills, people who put data governance skills or data management skills on the resumes, you see more of it on LinkedIn, but you see more organizations actually dedicating positions to it as well. It's not always off the side of somebody's desk, although sometimes it still is actually it often still is. But there's a lot more dedication to it. And and what I've seen in the in the past little bit here, both both Nate and AMA dedicated to data governance. So we were able to have data governance teams with team members that are on a data governance team. And that's what we do. So and that's true both at Nate and AMA. So that's exciting. But I'm seeing more and more of that not just in those two organizations, but other organizations as well. So as executive data literacy increases and, you know, CEOs and CIOs and CTOs and all those types read more and more and more research about data management. We're seeing a lot more easier buy in and better support for these sorts of programs and organizational structures. So I see it going nowhere but up. With a robust catalog of courses offered on demand and industry leading live online sessions throughout the year, the Dataversity Training Center is your launchpad for career success. Browse the complete catalog at training.dataversity.net and use code DVTOX for 20 percent off your purchase. And what the C-suite is reading is beneficial, of course, to learning and understanding that it's beneficial, of course, to the company and the right. Exactly. Yeah. And and reducing overall risk to the organization. So you see all these because we're so we're so tangential to security. So if we're worried about data breaches, well, what data is at risk of breach? If we're managing data correctly, then our risk of data breach should go down. If we do have a data breach anyway, then what data was breached? How was the data that was breached managed? Was it encrypted? Like, what is our worry factor here? So all of those things are so hand in hand and work so closely together that that we're getting a bit of a boost from all the security stories these days. Makes a lot of sense. So, Mark, what advice would you give to people looking to get into a career in data management? Be excited about data, be curious, read. There's there's a lot of great reading out there. Where's my library? Again, it's downstairs. But Bob Siner's book on noninvasive data governance is a fantastic read. It's quick and it's just so well put together. John Ladly has written a lot of excellent books on on data management and data governance, blogs, wonderful presentations. I know the folks at First San Fran Partners, they do wonderful content every time that I have the pleasure to read something that Kelly has done, has been amazing. Or presentations at various conferences. There's just so much learning out there. And and this community is so sharing and open and and and generally free. We just want to help each other out. So there's always an opportunity to poke people and and and communicate to go to these conferences, network with folks. Things like DGI Q and EW are great for that, which are both wonderful diversity events. Yeah, like just read, look at blogs. Read some books, talk to folks, get your CDMP. All that good stuff.  Yeah, the people aspect of it. Yeah, most of us that end up in data governance were naturally an introverted type personality. The the data nerd in the in the basement brick wall office with moss grown on the wall. I'm literally describing my intern office, by the way. It's a great big asbestos pipe that has since been removed before asbestos was bad. Anyway, so yeah, we generally have that introverted personality type, but we need to be extroverted and excited and engaged about data for everybody to be excited with us and to maintain that buy in and maintain that momentum and maintain an operating data governance program. So being able to communicate and continually sell ideas. You're never done selling ideas to folks. It'll always happen. So yeah, sales book. Be be excited, even if you're introverted. Pretend to be extroverted for as much as you can and and learn how to sell those ideas. I'm certainly seeing you very much engaged in the community at the conferences and overcome that or or or challenge your introvert as you give a lot of talks. It's amazing. And you have even sung for us. That's true. We have proof that's true. Well, Mark, thank you so much for taking the time to chat with us today and for all our listeners out there. If you like to keep up to date on the latest podcasts and the latest in data management education, go to dataversity.net forward slash subscribe. Until next time, Mark, thank you so much. Thank you and have a wonderful rest of your day. Thank you for listening to Dataversity Talks brought to you by Dataversity. Subscribe to our newsletter for podcast updates and information about our free educational articles, blogs and webinars at dataversity.net forward slash subscribe.


The Board of Minnesota State Colleges and Universities has opted for an interim leader after rejecting its three finalists for Chancellor. Despite an extensive search, System Chair Michael Vechich said Thursday he didn't believe the board found the right candidate among the finalists to be the system's next Chancellor. Instead, the board unanimously chose former St. Cloud State Provost Devinder Malhotra to serve as interim Chancellor until a permanent one is found. Minnesota Public Radio News reports 43 applications were received for that Chancellor post. Chancellor Steven Rosenstone plans to retire at the end of July. The system has about 400,000 students at Minnesota's two-year colleges and regional universities. If you've enjoyed this segment of Lakeland News, please consider making a tax-deductible contribution to Lakeland Public Television.


Welcome to the next episode of Make It Mini, which is a series that reimagines trending recipes in Lucker's Day's mini-cucuts. For the first episode of the year, we have these buffalo chicken stuffed brioche buns for a fun twist on a game day app. These little buns bake right in the minis and are stuffed with buffalo chicken, celery, and lots of mozzarella and blue cheese. Top with green onions and whatever other toppings you want. Like and follow for more.


If you want to learn how to do soccer tricks, this is the video for you. In this video, I'll give you a demonstration of all these soccer tricks followed by a clear explanation on how to master these tricks as quickly as possible. I will send the better blueprint to anyone who comments hashtag soccer on this video. Focus on good foundation, like this, even with your foot on the ground, your heel on the ground, just try to keep it there as long as you can. You can start with a bounce and a stall going with both feet.  Trap and just play around like that.  Roll up, lean out of it, a little jump, and then I'm popping it with the heel boom of my other foot. Knees together at the right time on both sides. It's a little bit timing and watch how I'm watching the ball as it comes here, getting out of the way, soft absorption, several different ways. Just place it there, but most players will struggle with this, let me do a bit. Players will struggle with this because they don't actually face vertical enough, even when they're doing like basic headers. If you're struggling with this skill, you're probably going forward too much or backwards too much. You have to find that proper angle of the neck so you're straight up to the sky. And then it's all about the little adjustments as the ball moves. If you want to improve faster and achieve more this season, use the Soccer Success Planner. It's 100% free. Players all around the world have already used it to improve. You can download it right now. There's a link in the description below. Okay, so as it moves, I'll move with it. After a certain point, you're pretty good at keeping it still. I'm always adjusting. I feel the ball. I feel it running away, so I try to move with it and stay underneath it. So I'm cupping it between my shoulder blades. Now, like super beginner would be, I would say, like a really flex the arms. And especially if you're a young player or you don't have any muscle definition in your back, you're really going to have to overemphasize the squeeze of the shoulder blades because I'm making a pocket in here. And in here, I'm making a pocket and I really have to overemphasize that. For me, I'm pretty casual with it. I don't have to flex too much. But if I really want to keep it up there, I should do a little more of a flex there. But I'm keeping it in that pocket there. Okay, so I'm just hitting the ball with the heel on top of that. Most players will struggle with this because it's the flex of the foot and the timing and they're not actually hitting here. I'm basically hitting on like the hard part of my boot. When you're about to do that skill, really focus on this touch, the touch before the skill. Put it exactly where you want, just with a little more focus, a little more of a delicate touch. Okay, but I'm just hitting there, reaching around, hitting with that sole. Always try to both feet, especially from the beginning. I know I spoke about this skill. Putting my foot around the ball. I'm kicking it around the ball and then I'm trying to put my foot around. It's never going to happen. You have to do it in one motion. So I'm actually, the touch is more like this. It's not a normal juggle touch, touch at the same time. So you're not kicking it and then going. It's at the same time. Picking up and I'm already starting my circle in that motion. Same time. Okay, so it's a touch and the circle at the same time. And then I just get back to it before the ball hits the ground. If you don't know about me, I used to be a huge underachiever, but through obsessive self-improvement, I found my success. Earned a college scholarship, played for my national football team, a YouTube channel with over 100 million views. I've helped players worldwide and I'd love to help you improve faster and achieve more. From moving up divisions to making national teams, players who use the Online Soccer Academy get results. Access elite level coaching and training, become a complete player, make a difference on the field and get noticed when you play. Limited spots available, apply today, start improving tomorrow. Link in the description below.


It is common for a national health system to have a digital architecture composed of several information systems and applications that serve complementary functions. These systems may need to exchange information or talk to each other to reduce duplicate storage of data and help bring data from different sources together in a holistic way rather than keeping it in silos. This helps decision makers to obtain a broader, more detailed picture of what is happening in the health system as a whole and can also improve the operational efficiency of each individual system. The ability to send and receive information between different systems, software, and file formats is referred to as interoperability. For example, DHIS2 and OpenMRS, which stands for Open Medical Record System, are interoperable because they allow the sharing of data and data definitions with each other. In this example, a health system may use OpenMRS to store detailed medical records for each individual hospital admission among other hospital and patient data. Interoperability allows DHIS2 to receive relevant data from OpenMRS, such as aggregate data on total hospital visits, services delivered, and patient outcomes, or tracker data on individual patients, and use them for analysis in combination with other data stored in DHIS2. This is commonly referred to as a one-to-one integration, as you are linking one system directly to another. Interoperability depends on standards that can be broken down into two levels. First is content. This means ensuring that what is being shared between systems represents the same item conceptually. For example, that a hospital admission record in OpenMRS contains the same disaggregations for sex and age as the corresponding aggregate data element in DHIS2, or that the organization units in both systems are aligned. The second level is technical. This involves the mechanisms and formats used to actually transmit the data from one system to the other. In simple words, technical integration ensures that all systems involved can speak to and hear each other, and that they use the same language. One of the most common DHIS2 interoperability scenarios is using DHIS2 as a data warehouse. Let's look at an example. One country uses a software system that records and stores the results of laboratory tests used to detect tuberculosis cases. Another system manages the stock of medicines in the facilities and alerts supply chain managers when there is a stock shortage. A third system collects human resource data to help manage and allocate health center staffing. Data from these separate systems flow into DHIS2. In this scenario, the DHIS2 platform functions as an integrated data warehouse, hosting data from various sources and systems so that they can be utilized holistically to enable informed decision making. While this scenario involves more than two systems, it is still an example of one-to-one integration because each system is integrated with DHIS2 directly without those external systems being able to talk to each other. In other scenarios, instead of using DHIS2 to combine data from other systems, data in DHIS2 may be sent to other systems that require it. For example, DHIS2 may send national disease surveillance data to a regional surveillance information system to facilitate cross-border surveillance of infectious diseases. In some cases, this may mean exchanging data between two or more DHIS2 systems. There are also more complicated scenarios where DHIS2 is one of a network of several different systems sending and receiving data from each other. This is an example of end-to-end or many-to-many interoperability. This can be achieved through the use of an interoperability layer, which is a separate piece of software that coordinates the exchange of data between multiple systems. In each scenario described in this video, interoperability is not as straightforward as simply connecting the systems to each other. Interoperability is a process that requires strong governance to coordinate content across systems, including the initial work to align or map data between systems, as well as technical support for the initial integration, and an ongoing basis as systems are updated and modified, and as the larger information system architecture changes. In summary, interoperability refers to the ability to send and receive data between different systems, software, and file formats. Using DHIS2 as a data warehouse is one of the most common DHIS2 interoperability scenarios. This term refers to how DHIS2 can be used to receive data from multiple information systems and sources to facilitate data triangulation. DHIS2 data can also be sent to other platforms or systems that need it.