 OK, the next speaker is Rock, most of you know him. He's one of the persons behind Nick's con. Rock's also the one who actually brought me to Nick's. I used to work with him together about a year ago, and he did some very weird stuff that I really didn't want to even look into. And just about a year later, I think, I'm completely infected. And yes, he wants to talk about make Nick's friendlier for beginners. OK, I'm on. So welcome. I have a loud breather. OK, better? Good. OK, so this is, I can't breathe less. So this talk is a bit, it's anything everything else but technical. It's something I've been basically doing the whole year. It's more. It's about trying to convince people how to use Nick's. Somehow successful, sometimes not. But it's more of what I see people struggling with. And this is like the report out after a year of telling people, Nick's, Nick's, Nick's, Nick's, right? So yeah, the tweet, the account, my Twitter. What I mean with friendlier? First, this is very kind of, if I would give you now the time to questions, would be really bike shedding. Like, is what's friendlier? It's very subjective. So I will make a definition of what I meant with friendlier is like, if we can fix something in one day that will produce the 80% of the good stuff, the usability improvements, that's what I'm aiming at. There are some really basic things we are just forgetting about it because we are too deep already, right? So how the beginner enters, you will see in the slides, it's quite different experience that we as the users. It's basically also the UX from the developer's perspective, how they see it. And what I mean also, usually, there are kind of two things which I like to emphasize in the UX, how to achieve better UX really cheaply without any over-engineering, which we tend to do, is first, the first one is you always go for what people expect. And it is really easy to do what people expect because you just see what they're using already. And then you, what overlaps, like a simple example is if you plan a park and you see those crossing on the edges, well, that's the usability thing, right? You didn't plan it correctly. And this is exactly what we need to do in our tools. And there are multiple ways. The second thing is, which I think is not only the UX part, but it's also a security one, is the default, right? What do you choose for your default values? It's also a usability thing. And this sometimes can be quite different. So I think we should focus on beginners, the newbies to the project, because that's actually how we will rule the world, right? And yes, actionable things. I want whatever we take from here to actually code on it. And two days is totally enough to implement every year of this. 90%. So basically, we'll go through the stages how I see people are going when they're entering NICs world. As far as they have this first contact, right? And then after that, they try to install it. Then they got to know all the tools. And they read the documentation. And then if every of these, they succeed, they start contributing, right? So this is like a normal flow. You want to convince your co-worker to start doing it. So the first contact, nixos.org. So these are more like complaints we can fix. But the first thing is very Nixos-centric. A lot of developers, I try to convince. I have to actually copy-paste them to URL. Just add slash nix. And you will know everything about Nixos. I think this should be a landing page where you get everything about Nix and Nixos and how they manage. This is very hard to do in one page. But it should be at least slowly getting there. We should have a landing page for both projects. So you know how to choose one. Because there is a lot of, well, there is an overlap of features, right? So we can do this. Everybody goes, come on, ask Docker people that five, six-minute video. Everybody loves it. That's how you sell to the developers. This is the thing. You don't need to place ads. You need five-minute video. So people go, it's funny. But yeah, I even click a lot of times, and probably you as well. Then usually when it comes, the next step is it's issue of trust. Who is using this? So why one of the, why Go is so successful? Well, Google starts with Go. So you're using it. So that's where. So people want to see that they're not alone, that there is a community, and that there are actually companies using it. And having the use cases that they use, or examples how they use it, that would be a nice thing. And I guess it's also nice for companies to have these kind of white papers. It doesn't have to be extra visible, but it should be there, because that's nice. And what I found really interesting is that we should be honest. Like, we're not the best tool out there yet. But being honest is like, it pays off in the long run. And if we are not good at it, we say we are not good at it. Continue carefully reading the documentation, for example. This section is not good. Just honesty really pays off. And then people appreciate it. So we can completely say, we are small as a community, but we have big ideas. People will understand this part. So the next thing, the front, the first contact, is really small. But if I would not be sitting next to a person convincing him to go now try and install it, they will never do the second step. So it's like people who are just coming over the internet, searching on the internet, searching for a solution, and seeing it, there is a potential there. Next thing is installing. So who has problems installing Nix and is Nix user? Probably you don't know, because you installed Nix in 2008. And it's just running since then, and it's happily. There are many. First thing is we are using curl. And it's not started, not started. It's a huge debate. I don't care. But the whole thing, even if, let's say, this is OK to do the installation, it's breaking. It's really fragile. And we as Nix, we are the ones who are saying, hey, just copy the closure. It's everything is there. And it should be that solid. I have a solution in the next slide. But Nix was installed, that's one of the things that a lot of times happen is it should be offline installation. Like half a year ago, it wasn't when I tried. And I think I guess the problem is not that we don't want it to be, but it's hard to test. And there should be a way to know that we can install it offline. That basic setup, I mean, right? So we need to Nix configure that basic setup should just run without touching the internet. And to go back on the first thing, right? So what I did at road code, what we did at road code was we went with building a standalone executable. So because we are a Python developers, we, of course, solve this in Python. Is this writing? I don't know. It's very easy to do it. And it's nice, quick. And I did it in two hours. And since then, we don't have any problems. Like if a build, if a download stops, or the connection is slow, how do we zoom and everything? No, you download the whole thing, you run it, and you have an offline installation. Well, that was one of the requirements to have. But how did we do it? So in Python, there is this thing. If you create a folder and you put inside the underscore underscore main dot pi, and you zip that thing and you execute it, that Python file will get executed. Now in zip file, you can also put the whole closure of Nix. And that install that Python code will actually extract the table, unpack it, and just install it. And that's the whole point. As being deep in Nix, you don't see the benefit, because it's like, yeah, why would I care? But this is actually saving a lot of customers, a lot of overhead, a lot of bugs. Like system is down, this is not working. This is that 80%, which you can do in one hour or two. That's usability from beginners, which we are not seeing as a. Is this just a Python that's already installed? Yes, yes. So why Python? Also, you could use any other tool if we can compile and then just have a binary static linked. But Python is more or less on all the platforms to write a simple script which work across Python 2.3 and Python 3.5. It's possible. And for that little functionality which you need to entire and just install, it's doable. It's not that hard. So it's a quick solution. We could deploy it tomorrow as a thing. Then if you want to improve it to have this standalone executable in another language, because it's for whatever reason better, let's do it. But this we can have tomorrow, right? Tooling. We already talked about Elko talked about that we should improve the command line tool. I did my research. I took the, in the slides, there are only two tools, but I also looked at not the APT gap, because that's really ancient. And I don't get a command line interface there. Makes a bit sense, but not that much in the new age of hipsters. So I took the example here. It's how they install packages, right? It's exactly how we do it. Makes no sense. And we want this, right? I actually picked basically only what we can do in the tomorrow that I only picked few commands, which are overlapping over all package managers, right? I didn't go through all of them, all support everything. I just want the basic. People want to install packages. And people want nicks install something, right? The other side of it is uninstall, right? So the same thing, like when somebody runs nicks uninstall, you should just run nicks and dash e, right? So it's in your head, in your language, you already see how easy this is to implement. Do you know how much you're helping the beginners? Like a lot, a ton, right? Because the first thing is people don't read documentation when they are trying out the common line tools. That's how it is. They even don't open ManPage. But the first thing they say, oh, I want to install a package, nicks install, and they wrote it. And I was like, enter. It was like, oh, stop. That's not how it works. It's like, this is that path of the UX which the users expect. And you should provide it, right? So what do I store for most? This was actually coming from. So to repeat the thing, this was, so the current situation, how we have it, it's taken from the RPM, how they did it in 2001, I guess. OK, so from the 90s, right? I'm just saying, it's not that the thing that this is broke. Like, we have broken tools and everything. No, we have good tools. Tools are working. It's just that 80% what people expect. And this is the really important, the UX for developers. Next set of commands is search, right? This is the echo. How do you call this package, right? And then they search for it. Like, everybody has search commands, right? It's OK, right? I mean, I don't care. For me, ZShell autocompletes, but for a beginner, you want this, right? The opposite of this. Install packages, right? It's listing the packages. This is also what do I have installed so I can uninstall it, right? That's a common thing. And yes, did I do it right or did I? The presentation was done around 4 in the morning, so probably I did mistakes. Oh, that should be dash, dash, install, right? But OK. And next step, supports for your experience. Yeah, this was from, I started using Nix in 2010. So it's still working. So there are still users doing this way, just for the camera. OK, the next thing. Oh, hi, guys. OK, see? Interesting things happen. Upgrade command. It's some people call it update. So there was what? Upgrade, update. I don't know, I started calling it upgrade because it was the most common one. Because a lot of projects have aliases, and the upgrade was you want to upgrade. So we do this. Of course, we also, in all the commands, I wrote two commands because that's another topic, which we already covered. We will start using attribute paths or names, right? Which is awesome. We should do it because it just makes less things to know, it's better, right? The less, it's more. And then, yes, this how it should look. And the next thing, which you would not believe it, but are awesome and really important for how people feel the project, how do they trust it. It's not about, yes, it actually doesn't matter about the beginning when I said that you need to use cases. What they want is colors, s-guards, and emojis, right? I'm not joking. I'm serious, right? It's, no, it's, this makes it crispy. It looks like it's new. It's like recent. This is the hot thing. It's like, oh, it looks like, almost like Docker. You see, that's familiarity, right? From the outside. But so what I want to emphasize here, it's even different point. We already said we are moving that way. Doing the UX is not like, oh, let's just code it, and it's going to be like this, and it's good. This is the wrong approach. It's a path to failure. Because once you give something out, people expect it, and it's hard to break that promise. I would suggest we use current tools we have and start experimenting and building tools that we'll call those subtools, and let's experiment. I mean, these commands are, they make sense. We can, I already implemented it. We need to experiment how users perceive that. Does it make sense? And it's okay to implement this in kind of, I don't know, Python, Perl, whatever. Until, and then once we freeze the functionality, the commands, yes, then let's implement it how we want it, right? It's that research of what users, what is the expected way, or what's the best way, needs to take stages. And that's, I mean, it's basically how the designers work or UX guys, we need to also, in our tools, bring that workflow. So yeah, emojis, remember. So we're gonna have emojis? Yes, emojis there, please. What do we have? Pony. Oh yeah, we have ponies, something. Yeah, okay. More the better. Documentation. So, documentation, it's, everybody is not happy, but nobody wants to do anything, right? That's the whole kind of thing. I want to go differently way and ask ourselves, why do we want documentation, right? Why do you write documentation? Is it for yourself? Like, why do we write the whole manual? What's the reason? Is my opinion bringing somebody who is beginner to the advanced level, right? And, you know, you cannot just, you know, I, when I started Spanish, right? You just not, I will never learn Spanish if you just throw me a dictionary, right? And it's like manual, here it is, learn it, done, right? It doesn't work that way. How you do it is you need to be taught. You need somebody to teach you, right? So the teaching part is the problem. And when you do documentation, it should be about teaching. And the, once you know why you write documentation, you also clearly more defined how you write it, right? It's, you have to, when you're teaching somebody and teaching is really hard, especially writing documentation because you don't sit next to the person. You don't see the expression when it goes like, what happened, right? You don't see that. You have to take it through steps, make it sure it's kind of bulletproof and learning this, it's very hard. There are even profession about it, technical writers, right? But it's, but even basic stuff in the Nix, like in open source community should be dealt with it. Like you should, your manual should be done in a way where they teach and then they don't tell. So the outcome of this documentation should be teaching and not telling, okay? So there is one which I always point people to because it's just enormous resource and it's the, that lead folder, you open all these files. It's amazing thing what you can do with the language. It's just hidden, right? I'm not saying we should use doc strings but we should document that. I don't know how, whatever we do, it's documented and it's documented good. So we have the documentation, we just don't expose it. So this is like, you never point to somebody saying, hey, just read the source, right? It's like, or read the doc strings. It's no way, right? It should be there. But yes, so this is one of the things we can fix probably in this friend, question there. No, just remark the problem is even one step before it took me over two weeks to figure out that there's a third manual for NICS packages. Oh, yeah, so that's actually the discoverability in the like getting to like first contact with NICS. So we know that, oh, there is every project has a documentation, so that would be. Yes, there is a documentation for NICS packages. Yes, good. Okay, but you see, this is, okay. So I already told this, but we should teach and we shouldn't tell. Like this should be the approach we take. And I'm not saying that manual we have currently, it's throw it away. No, the manual is good. It has everything inside, but I'm using it, right? And I'm a few years developer of NICS kind of trying to be, right? It's, we need tutorials, right? Which are going to tell you how to use NICS. What are the types? What are the basic types? Like tell you, go through like, you know, usually if you wanna teach somebody to drive, imagine you'll get the, you know, new BNV, you give him the BNV manual and it's like, you know, that's it, read it and drive it. Doesn't work like that, right? You have to take the hand and take them all the way step. If you see they fail, you know, you cry with them, right? That's the whole point. Like, so this is, so, and then the last thing, this might be a bit personal, but kill the wiki, right? The wiki is not documentation. Actually, the wiki is abomination. It's basically the worst part of documentation, right? Because have you ever taken a class where you have multiple teachers? That's the wiki, right? Everybody writes in their own style, but okay, you can read different, you know? But everybody teaches differently, right? And sometimes actually happens is, you know, as the developers is, you started, oh, let's just set up a wiki and then let's wait because documentation will come, right? Do the basics and then it will come. It's like, and then beginners come to us and it's like, oh, yeah, well, you know, we don't have time, just update the wiki. No, now imagine being in the Spanish class and coming there and it's like, oh, there is a bug in the notebook and they say to you just, oh, just go fix it yourself. Seriously, we would turn around and go, right? So wikis are not documentation. More, you know, that when you have in the primary school usually happened to me, it was like there was one jerk being there, you know, just being loud, right? And this is, and it takes the whole, steers the whole class. And if you consider yourself being in that class, like everybody fails there, right? It's because of that one person. And this is really easy to achieve with wiki style. Oh, yeah, I'm better removing all the wiki we have than having wiki because no documentation is better than false documentation. Some more, all you know, I find that I rather figure it out on my own than actually giving, having false promises. And then, you know, this was in 2006. Whoa, okay, you know, I know this will never work, but that's the beginner. Yeah, one thing I also keep firm belief is that if you keep documentation in the wiki, there is no way you'll have it in the place where it should be, which is next to the code. So you should treat documentation as code, like with three JavaScript as a programming language. We also need to keep documentation close to code. No, no, come on, it's JavaScript, JavaScript in the beginning was really hard language. Only when it has tools, we could start reading it. I'm not joking, it's good language now because of the tools, right? And the same thing, we need to apply to documentation. And having it alongside the code helps a lot because usually the ones who are the teachers are the developers and they should be, right? Especially in the open source communities, in companies you have special creatures. Yes, okay, so who is to kill the wiki? We do it, okay. Yes, the last step, right? So let's say the person goes through all of this, all the pain, there's documentation, there's extra homework, decides to contribute. What we found, I think we saw from the slides, from Elko's, was that which year did we convert to GitHub 2012? There was like after 2010, and there was like really a spike up, right? This was a good decision, not because GitHub is awesome, but because it brings that social effect and you can argue it's not, but we have proof, right? It really spikes. It's also the discoverability. So the thing I mentioned in the beginning, also from the code point perspective, it's more discoverable as a project and people is like easy to contribute even if it's just a typo, right? And yeah, the whole PR, having a review process before something comes, people see this as a barrier. I'm seeing it as a teaching process, right? So this is where you learn, you commit something and people tell you like, hey, there are better solutions. And after that pull request, you come out smarter and that's the whole point. Even I sometimes comment on pull request and me as a teacher, I learn stuff, right? And that's also the process. If you don't understand something in a pull request, ask. Maybe the implementer will actually tell you and you will know more, right? Pull requests are a process of to learn, right? That's at least my experience is a good thing. I mean, eventually they have to get merged so you have to end up discussion, but yes, it's a review process. So yes, then the next thing I wanna mention is I think Doman, yes. So he posted the tweet that we are receiving 440 almost pull request per month, right? And then we know it's a lot of pull request, right? And we close quite big chunk of it. The question was like, how many committers do you have? Like the push, right? 65. How many active, really? So it's not about like pointing out who is an active. That's not the point. I wanna point different things out. It's, there is a barrier which kind of people don't even notice that the pull request needs them because they are not tagged automatically, right? I think pull request to some extent is it is a Darwin thing? The something that's rebuilt should actually include all the, you can get the top level. We can automate a bit of it. Like just to know who is actually the top level packages that are being changed, who is the maintainer, add them automatically. I think this is possible via Travis and some shell scripting or Python or Perl or JavaScript or Haskell. So automatically assign maintainers to review pull request. This is the D thing, right? Cause if a maintainer who is actually listed there would know that somebody updated, he would go there and review the thing in not every time, but in 90% of the cases. And this will offload the one who has pull request a lot, right? Yes, the question, there is a mic. I also wanted to say as a contributor, it's not always clear if it's gonna be reviewed or when or who's gonna do it. I think it's really cool. So having these automated things, I'm not saying we should go all the way, right? This is whatever we can do, let's do it, right? That's whatever we can do in the sprinting days, let's just do it and like how the Docker or the chorus guy says like ship it, you know? Let's do it. It's really will bring the effect, right? And yeah, so this is a bit, I'm gonna, before I press disclaimer, it's a bit controversial how I wrote it. I'm not good sometimes at expressing without my hands and let me wait between you judge. Committers should be invited to step away if not having enough time. This is not to say to kinda, oh, you don't have time, go away, right? This is not thing. It should be, if there is a way in, in this core group, there should be also a way out because maybe next year, I will not have enough time. And I would like, so what's the perceived value is, we have 65 committers, right? So now somebody looks and would like to be a committer as well and have enough time. He sees it as like, oh, there is enough guys, right? I'm not needed. And that's how it is perceived and why nobody is actually coming as a new committer and having the time. And it's the other way around. I wanna have a lot of this cycle that developers can come and go out and just, it's okay if you don't have time. I mean, it happens, right? Babies get born, marriage, you break a leg, you go surfing. So, yeah, so, so I kind of pointed out now all the where I see, at least from my, let's say this was like a year, a bit more progress, a year and a half when I was going to conferences and talking with different companies and trying to convince them to use NICs and this were all the points, right? There are many more, but this is something I pointed out that is solvable. Now this topic is a bit by shedding as I mentioned, so everybody has their own opinion. But if you, when you ask questions now and or do proposals, cause we need them, can you try to stick into that, do it in the two days time and bring 80% of the value? If you have some proposals and questions or if I did some mistakes, we can talk about Wiki later, but yeah, this is my last slide. So, thank you. Yes, we have about I think 10 minutes for questions and one question is already pending and afterwards we also have an announcement, so please don't run directly away after the talk. Hi, about the pull request thing, I think automating tagging them is a really good idea, but I consider this also a problem of GitHub itself because I want to have the possibility to tag and assign maintainers for issues or pull requests, but I don't want to have push access to master because I myself consider pushing to master a bad style and I don't want to have that right, but I want to be able to do sorting out issues, closing them if they're already done or something and assign tags and so on and I don't have that possibility on GitHub and I asked GitHub like two times, I guess, maybe three times almost a year ago now and it's always, yeah, we are thinking about that and I guess if we as a community can go to GitHub and say, hey, we would really like this feature, I guess maybe we can get it. No, I'm not sure I get it. Just, we are too small, they care, but not enough for us. It's okay, this is how the world is, right? So it's true that we cannot get into the perfect world where everything is automatically tagged, but having a tag, just adding a responsible there, that's possible to a Travis hook, which then figures out we have NOx already which does the build, why not build something there around it that will, this is possible. I'm not going into extreme. It's like everybody wants ice cream with everything on top. So I just get, how to say, cane, just basic stuff. Just in terms of narrative documentation, I think little man's Nix Pills does a great job with that and maybe it might be quick win if we could hook that up or make it more visible on the NixOS or website that might be good. Yeah, those who you don't know, is it public now, right? They released it already? Okay, anyway, I think there is a lot of these tutorials how to do the teaching part. I'm bad at teaching, I know. I need to improve and it's like everybody here, I guess, should improve. Yeah, I understand. I don't have a recipe how to improve, like just try it and fail, the same thing. Learn to learn how to teach. Yeah, so I wanna respond to your remark about maybe you should make it more visible. For example, these blog posts that lethal man has wrote because it's excellent, actually. But in my opinion, the NixOS community has always been about doing, people just taking initiative. So make sure you actually take that initiative. So not only, of course it's good to have ideas, but this could have been, for example, in this case, you can just make a pull request to the NixOS website and I'm sure it'll be added, let's say, within a day. So it's typically something that can be done quite quickly and there are probably many things. So if you wanna do something, just do it. Yeah. So actionable, small things we have in front here. I think that's the whole point. We could go really, like, do the whole analysis, but we know those little things that we can actually fix right now. I mean, so this idea of having Nix installed and Nix uninstall, Nix shell and so on commands, I really like it. I mean, I already mentioned it in his talk. By the way, it should also be extensible, like the git where you can just add a new sub command. But about the Nix upgrade command, I think actually that one shouldn't exist. Which one? The Nix upgrade command. So maybe the underlying command should still exist, but I mean, like when I try to update an imperative package, I usually prefer to just use Nix and I again, because that has more predictable or like more intuitive behavior. See, the thing is you're thinking from your perspective. No, no, no. Thinking from the beginners. Yes, but from the beginner's perspective, like, okay, from Nix upgrade, it's more intuitive than Nix and few, sure, but it's still like very confusing semantics. And if you make like a nicer syntax for it, that won't make the semantics nicer. So definitely, I'm saying we should put a bit of lipstick on a pig, right? But this is really, these five commands are across all package managers. People expect these commands, right? And they are basically, if you're using Nix, the package manager, they have to be install, uninstall, list, search. I mean, maybe you could just make upgrade then and synonym fence type, right? I mean, you want to see how it works? How do I do it? Bigger? This part doesn't matter, you just function the trans command, but there is a main command with a bit of documentation. It has, this is the sub command, which is called install. It does run Nix and dash I. And you have uninstall, you have search, you have list and search. What I'm trying to say, I'm not saying this, let's put it into Nix, right? Wrong. This is easy way how to experiment. Let's package it and let's give it to few users. Let's try to, that's the whole point, like maybe upgrade is a bad idea, right? But this is the way how we'll know it. It's experiments, people like to be test the mouse's rabbit. Ghilliepicks, yeah, that animal. Not that interesting, but maybe instead of infusing the idea of there is an upgrade into users, just say there is no upgrade version. If they execute Nix upgrade, let's say this command doesn't exist, maybe you meant install instead of upgrade. Like suggestions, that's part of it. I know the semantics isn't even existing, please use the other one. But do you know that upgrade exists, right? Yeah, but just say it. Yeah, okay, but you know, people are bad. Like to be bad. Yeah, one more. I think that the Nix packages documentation should be updated more frequently because I use it as a reference for myself, for stuff that I've written because I can't remember how to use it. And so it's really easy when you make a pull request that you put in a new function in Nix packages that you should just automatically go and edit the Nix packages documentation at the same time. I guess in part of our pull request review process, we should also see, do we need to update, like that question, do we need to update the documentation? Like the manual, because at least the manual always has to be perfect, at least, right? Then tutorials are nice to have, beginners will like it, but yeah, that's, okay. Thank you. Okay, thank you very much. So I think...