OK, so this, I did say that I wanted to change the name, but didn't make it to the final program. But yeah, basically, it's the same idea.

So I'm Gil Furcada. I'm coming from Catalonia, actually working in Berlin, Germany, GitHub, Twitter. And I work at the Deaf Gaita, that's a weekly newspaper. And we, of course, use Plon.

But just a quick quiz, who has ever made a pull request on GitHub? OK, no, so far. Well, OK, perfect. So do you know Jenkinsplon.org? No?

OK. So well, the few of you maybe have run this pull request job that we have for you. Yeah, of course. So there's this package that we have on the Plon GitHub

organization called Mr. Roboto. Maybe ever heard about it? OK, perfect. So everyone says it's like the ongoing topic. Plon is hard to contribute to.

So once you have, OK, I have that, I know that there's the CSS error here, or there's the small Python function that doesn't

make what I expect, then you make a pull request. So if you find the package, and the code, and the branch, and everything, so all the stars are aligned, you can finally make a pull request. But then maybe you have some problems on,

or some uncertainties, because maybe you are not so well-iterated with the Plon code base, and how the project organizes, and everything. So for example, in Plon, we have kind of a lot of pride on keeping this running. And some years ago, you could see

Timo complaining, and raging all around about that. So of course, nobody wants an angry Timo. So you want to make sure that the tests don't fail,

or maybe you don't even know to which version are you targeting. Maybe your fix is something Plon 4.3 specific, not Plon 5 or 5.1 that we already have on the working. Maybe, OK, you just fixed that small function,

or that CSS, or JavaScript. But is there anything else that needs to be added on the pull request? Anything missing? Also, especially for newcomers, we legally cannot accept code if they haven't signed the contributors'

agreements, and all of that. So fortunately for all these things, before we have Mr. Roto, which is basically a pyramid app that sits between, or that listens to GitHub activity,

and then reports back to GitHub, and tells also Jenkins to orchestrate everything. It's not everything. It's not everything perfect. There's a few things that could be improved a little bit, but at least whenever you are creating a pull request,

for example, it checks if all the people that made commits on that pull request have signed the contributors' agreement. It checks if you have made any change on the, if you updated the change log entry on changes RST. And it tells you which plan versions you should try to,

you should run the tests before knowing if anything did broke. There's a few more things, but that's basically the overview of what Mr. Roto is actually doing. But maybe we could start doing more things.

Like, for example, something that we already do, but not on the pull requests, for example, is like code analysis. Well, yeah, in a way it's there. So code analysis reports documentation, for example.

To a certain size, if you are adding a really, really big change on a package, probably that should be documented. Maybe like if you add a complete new module, or if you add a few more things,

like a complete new package, or a complete book of code. That's a special, that's one that I really, I'm tempted to add, that if you add a new pull

request with a decent amount of code, but there's no tests being added, probably we shouldn't merge that, because in a way it's, so in Plun we have all this pride about having tests,

and we rely on tests to make sure that everything doesn't break, and we get notified. But then you keep seeing pull requests, and pull requests, and basically, I mean, I didn't make the numbers, but maybe not even 20% to 30% of them do have tests.

Maybe 40, so to say. But of course we need to add tests when adding new functionality. Of course, if you just change functionality or fix things, again, it would be nice to have them. But that's probably something that people used to Travis

probably would like to have, that we auto run tests. Of course, our tests are quite, quite slow to run, especially the pull request one takes more than one hour

and 10, 20 minutes, depending on the day. So that's not really quick feedback, but it would be nice that maybe we can find some ideas on how to run that.

That's something that GitLab does automatically if all the tests, if all your integrations run fine, you can do a checkbox and mark, OK,

these pull requests merge it automatically, so you don't even have to do the extra effort. As we are open source, probably we want to get somebody to review the changes before that. But as recently, GitHub added this thing about these reviews

that you can approve a review. We could automatically merge if there's at least one or two reviews, for example, or make sure or force that there has to be a review before actually letting a pull request be merged.

Something that Eric will probably love, like that Jenkins does the releases by themselves. There was a talk early this morning about continuous delivery. And one of the key points on continuous delivery

is, of course, not having to do manual releases. That's part of not automatic. It's like continuous delivery. And of course, there could be way, way, way more things to be done here.

The code is here. On Mr. Roboto, in Jenkins, we have all the configurations and all the ways to configure our jobs and all the integrations. I can go. I seem to have quite some time still,

so I could go a bit more about that. But especially any ideas on everything related to Jenkins and the integration in pull requests that you find yourself that could be improved.

See, I'd step back even a little further. Because trust me, you don't want me going into GitHub. That's a GitHub. But I do a lot of user testing on it. And when I find either a problem, a bug,

or a suggestion, I don't know where to go with that. And I go on to the community, and I realize you win. I know the bug trackers and stuff like that. But we talk about removing barriers. I don't know where to go with that.

And my feeling is, if I go to the wrong place, and I've assigned a bug to someone that's not theirs, they're like, I don't know if I'm going to piss them off. I don't know most of these people. And this probably isn't where you are headed, and that's OK. I just want to throw it out there. Even if you become a registered super user,

or whatever the hell, not a programmer, that I can go somewhere, or we can go somewhere. And put in a bug, in a bug tracker. And then someone else figures out where it goes. Sure. Well, that's one of the problems that's sort of,

more or less, or well, to put it in. So quick answer is that on GitHub, we have the Plone organization, github.plone. And inside there, there's like thousands of repositories. But there's the product, cmf-plone,

which is the main repository where bugs are reported. So if you don't know specifically that it's about Plone app content types, or about whatever, just report there. Easy shop, easy store, easy place.

If you are not really that much sure about if it's really a bug, or if it's just you, or all these things, you can definitely, and I would say that even on early stages, so to say, until you feel comfortable with GitHub, so to say.

Because maybe there, people just close the bug with a small reason, and then you feel a bit back off. Then communityplone.org is always, people do report there, and then people just point you to cmf-plone or the specific package or so.

There's actually quite a lot of repositories in the GitHub, in the Plone GitHub organization that do not have the issue tracker enabled. Mostly to prefer to have that there. I mean, because of course, the idea in GitHub

is that every repository is king, and that's the whole world, so to say. It's not for us that we have this, all our code is spread in so many packages, but we treat all of them as a single Plone thing.

That doesn't work, that doesn't fit really, really well for us. But definitely, either report them to communityplone.org or if you feel more comfortable to GitHub Plone, cmf-plone, product cmf-plone, sorry. What if on the product page, whether it's in IPY or a packing oldies or another product page,

there could be a link to wherever the heck, whoever created that product, where did they want me to make suggestions, bugs. I don't even like calling it a bug, because I'm telling you you screwed up, right? Well, you don't even have to classify, you just need to, you just open the issue and say,

well, I found this, people, opinions, please, sure. Yeah, I'm not sure Victor may say something about that. In plone.org, do we have any direction page for,

like, okay, there's a, I found the bug or I have something. Okay, okay, okay, sure, let's see. The first order of business for you in particular

would be to go to plone.org slash support, and if anything on there does not go to the right, in the right direction, then that should be fixed

and you should not, you should dump that. Well, all right, so for bugs, okay, do you mind following this, is this okay? Sure, sure. So let's go to the bugs. So let's say I found a bug on Mosaic, just to pick one, okay? Or I think it's a bug or whatever it is. So from here, obviously it's not security,

all right, I don't think it is, so bugs that are not security related. So it tells you to either go to the specific repository if you know it, or if not, the catch-all CMF plone. Oh, sorry, I can't make that bigger.

I didn't know this page exists, so thank you for showing. Sure, well, that was bigger, but sure. But yeah, I'm not sure if maybe that should be something that on the control panel on the CMF, on plone's control panel.

Uh-huh, sure. I mean, that would be kind of nice.

Maybe even more.

We previously were using a variety of atoms, or we were using track, and we were using also some atoms, we were using oil with it.

After that, but I think that nowadays, everybody is using oil. I think also given the fact that we have also a few weeks ago added also that waffle, uh-huh, the project.

You can get projects on GitHub that you can also use, yeah, lists, get things on the list, or managing issues. It's okay. I don't know if someone created the project.

That's what I'm trying to get to, if, okay. There's one project already, so there in GitHub, now you have this projects tab where you have a Kanban like this, and it's totally configurable. You can have as many columns as you wish,

and you can drag and drop things so that you know the status. Well, I mean a Kanban thing. So yeah, definitely that's something also to organize. I have a line in talk that I want to talk about this, actually. But again, even if, for example,

you know that it's about Mosaic, and I could tell you that Mosaic is a still not core, so probably it should not be on CMF Plon, and especially because Plon and Mosaic already has its own tracker as well. But that doesn't matter. Just always, if you don't want to think about it

or just don't know, just go to CMF Plon, report there, and mostly people are polite nowadays. So... No, but I mean, it's... So... No, I mean, the extrovert that you can cause is just closing it, so no problem.

So yeah, that's... You saw the lightning talk yesterday by a German guy. What do you think about that? Well, if I'm not mistaken,

that's probably when I... So maybe let me just quickly... Maybe this one... Oh yeah, exactly. So when you see this logo here

on the status of a pull request, if you see this logo, that's from Mr. Roboto. That's the project I was talking about. So it checks the changelog entry, so they did here on the changes, they did add something here. But then the contributors agreement failed

because in this case, it's nothing just committed with a random ID. Well, not so random, but an ID that's not known for GitHub. You can add those names and emails

on your configuration, on your user profile. I think your question... Yeah, I was... So I talked to one of the guys who runs a company to help people do their governance, and he said he'll help us get it sorted, but it's going to be like,

the Americans get to sign it online. The Europeans have to do a physical copy still because it's their laws that are restricting it. So that's why we've kept it as one thing, so there aren't two different sets of rules. So it's kind of restricted by the Europeans, like the Germans are very strict around it, and we're going by that strictest rule right now.

We'll bring it back up again and again because we bring it up every year, I swear. So it'll come back around again. He said he'll have his attorney help us once we have a plan, but we don't know that we'll be able to have a plan to get rid of that click-a-button-in-your-contributor thing. So because it's more structured by the laws of other countries, of the EU and other things.

So we may be stuck with it for a while. Well, still, by now, that was a bit unfortunate because Mr. Roboto, it's enabled on all the repositories, but for the documentation one, you don't need to have a contributor's agreement.

And actually, I think that either this one at that time or another one, I already turned it off. So nowadays, you don't have that. But still, I think that the other problem was that it was pointing,

or not sure if it was in that case, but there was some other times where following some links or just Googling it went up to a place where it was telling you something that was totally updated. And I guess that it's already been fixed. But so far, right now, at least,

what Paul, maybe that should not be recorded, but Paul always says that with a PDF, it's enough. So you just print, you print, sign, scan, and send. That's not that much. That's not like perfect, but that's fine.

And especially if it's just the first, it's just like one time, not like every year or something like that. But yeah, but for example, so my idea with, or the idea why Mr. Voto was created was basically for this thing here,

for running the tests and everything. But we certainly can expand just like, as I was saying before, that documentation. So here, we can even provide welcoming messages

or where to point to, or maybe if it's, we can even monitor the pull request and if within three weeks or a month and there was no activity, then point to the person if it's still addressed or closing it, things like that.

And at the end, the more you automate, the less that you have to think about it and then everything is, so it's this self-service in a way that, or maybe like if everything is done but nobody merged the pull request, maybe like trying to put some random names

like the few last persons that touched or merged pull requests, like can put them on CC on a comment and say, hey, can you, as you were the last ones involved in this package, would you mind getting a review of that so that we can move things around

because of course you always have the notifications up here but after you've seen it, if there's no more activity, it was merged, maybe not, maybe yes, who cares or who knows. And of course for newcomers, probably they don't feel like, hey, can somebody kind of look at it, can you look at it, which is,

which for already core developers, maybe that they will feel totally confident on doing that, like hey, Folio, please review that, but maybe others will be a bit more hesitant or maybe don't even know how to think as well.

So if there's any ideas or if you happen to like all your pain points while contributing, please either put them here on CMF blog or so so that we can, our community, we can discuss that on community. First of all, I want to say thank you for all,

it really has gotten so much easier, so that's great. One thing, I know that, where is it, labels, I know that Jens created a whole set of labels,

a whole set of, you know, what do you call them? Well, so he sort of like put some categories on the labels. Yeah, sure. And some of them are actually sort of workflows really.

Like, okay, the tool status. And still so. Yeah. So if any of that could be automated in some way,

that would be great. Well, so as running tests, it's so much time consuming and maybe you just create the pull request because you do it like through the web, you just edit the file, but then, of course, like for example, there's the change log verifier that will probably will yell you that it's missing and so then you edit. I was thinking that probably maybe,

so to automatically run these jobs, if you add a certain label, so like for example these testing, so as soon as you say it's on testing phase,

then you can start. But definitely, like if more or less the idea of this is that it's like a confirmed, in progress, testing ready and deferred, probably we could like automatically add the,

well, in progress probably. And then once you manually move it to testing, I mean we can of course just create some comments here like please add this label as soon as you feel that, this or that. So we could add the testing label or if manually added the testing label,

then Jenkins will start and then if everything is fine, Jenkins can change that to ready and that can trigger that, so or that can be the final state in this like in this pipeline. And then if three weeks later, all the pull requests that are still ready

but nobody merged them, then start pinging the people every now and then. And then maybe you can just move it to deferred if you don't want to get bothered by that because maybe it has to wait for something. One thing, I'm not sure if there is anything that's matching,

but one thing I noticed is that a lot of times people create pull requests that are just so that tests are started automatically and they say please do not do anything with it, do not merge and stuff. That probably should have a tag.

Yeah, actually there's, sure that would be a good idea. And there's another thing that all these checks here, I can't remember really,

but I think it's somewhere here on the settings that you can make them mandatory. So like if that check is not green, cannot be merged. So in a way, that's probably something that we want to do at some point.

I think, I can't remember. But the thing is, yeah, there's all these work in progress pull requests that you don't want to merge and actually Jens on one of his cleanup pull request tasks,

he just ignores everything and he says, oh yeah, the label was that and that, so I did merge. And he was like, well yeah, but I did say there, so if you didn't. So there's, for example, in GitLab,

you can, if the name of the issue starts with work in progress, so WIP, then it doesn't allow you to merge. It already says, so it's kind of like here because now there's conflicts. So yeah, there's some process

that could be improved here as well. It's a minor thing, but. No, but again, it's some things that you take away from people. Or especially when you have pull requests that depend on other pull requests and they have to be merged either together or sequentially,

so to say. Then of course you want to really do that. And that's again the problem with GitHub and having just the repositories,

it's all the limits that I look for. On the other hand, it's also our problem for splitting into multiple repositories. There's lots of larger organizations that, for example, I read about Google and I think even Microsoft, for some projects that they had,

usually, just like us, they had 20 hundreds, hundreds and hundreds of packages. They decided to just create one massive Git repository. Of course it would be a bit too much, maybe, if you look at the dropdown of branches or so because it can be a bit daunting.

But then everything about testing and integration and releases and everything and conflicts and so on, that will be just so gone. That's... I'm sure GitHub is too...

Maybe. We don't know, but it seems like a very common thing. Sure, but they also target, I mean, the year... Well, now that they added these reviews

and these projects, it starts to feel like they are really moving not just to code repository and code review, but also to project management. Maybe they do that, maybe they just do that for enterprise, the enterprise version, who knows.

But anyway, that's still a problem for us, for ourselves. We need to find a solution that works better because so far we have just patches and the way Jenkins is configured so that we can do all of that,

it's sort of insane. If you compare it to just, for example, what people is used to, that it's just Travis. You just put that file, connect it to Travis and everything works. Sure, we are not a single package, we cannot really do that,

but we should be able somehow to get closer at least. One for the idea to add documentation,

Mr. Roboto. This change log verifier, you mean? No, no, no. Or for the docs. Yeah, the problem with this is that as here you can only have, well, actually we have all of them here, you can have like, okay, working and failure.

It's kind of like, well, if we agree in what's the logic to decide if something should have docs or not, but then it's also like, well, maybe I refactored something, but it's already explained somewhere because I'm just merging two packages,

so to say in the package it's already well explained. So that's a bit of, maybe just a comment. It's probably enough, like, okay, you are adding quite a lot of changes here. You may want to think about going to the documentation repository

and do contributions there, explaining the feature, or at least creating an issue explaining that you are about to do that so that we document things. But yeah, definitely that's, I mean, when previously there was this talk about

Plon versus Drupal, Kelvin was saying that yeah, Plon is really good in terms of documentation for upgradings because there's all the documentation, but at least for the Plon 5 one,

most of the things were there, lots of things actually were there, but there were like some big gaps on that, and I don't really see us as a community making much, much change in there.

Again, on the app side, I feel myself contributing quite a lot on the documentation because I know that it's maintained and I know that there's people there caring about it. So that's also something that's probably already started if we have, if the docs team has also,

is also moving more to engaging a bit more with continuous delivery so that you can see the fixes that you make. That's probably a bit more appealing to contribute there and like, okay, there's all these, I mean, every now and then I'm just fixing broken links or things,

or links that point to sbnsob.org or things like that and just point them to the new places, but that's already like the cleanup and the minimal, yeah. Just checking in. Okay, sorry. We have birthday cake.

Oh, done. So thanks for listening. I know that not going to David League was, was challenging. I mean, probably everyone was there, but oh well.

Yeah.

Yeah, yeah, but I want to at least, I mean, I have no code done for that, although it would be tricky to do. I mean, it will be trivial, sorry. But in a way, I want to add that, maybe not as a check,

like you have to add them.