 Welcome. This is the Inclusive Naming Project as part of Sheikot Africa Contributon April 2022. Today is May the 10th. Let's get that in the notes. May 10. And great to have you all here. Thanks for being here. And topics that I had on my list was let's review progress to date. We're looking at the list of poll requests that have been assembled, etc. And code reviews, likely needed on the poll requests. Special thanks to Angelique Jard who's been doing a number of code reviews. And then peace and Catherine if you have questions we should probably put your questions first on the list because we're in the last week of I'll put it on the list as a timeline reminder. We're in the last week of the project so let's talk about what we've got. Questions and answers timeline review of progress. And if there are any other questions or topics on the search Catherine or peace anything else you want to add on to the list. Will there be another meeting next week. Yes, and that's last week of the project but not last but not the last week of meetings yes there will be. Good good point so let's talk about that what's next and what's what happens in the last two weeks in the last two weeks of May. Okay, in the inclusive naming sheets. I saw something like the last progress is creates build and something like that check in the inclusive naming sheets, that's the spreadsheet. Oh in this one right here. No, in this one here. So, sorry piece which what piece was it that we were looking for the inclusive naming document that was sent from the beginning. Oh, so this one. Okay, uh huh. Yes, at the last part I saw build the last tax. So the last task here compile the plugin. Is that what you mean by last task. No, okay so me know the one before submit full request. Before, right. Not this, I mean the last tasks. Just screw up you see. Okay. Okay this one revised the terminology build. Right and I think I think this we just need to correct it because we've found the two of you have proven that in general you don't have to build the plug in in order to in order to propose a terminology change. I think we can just delete that text, because you've at least what I've seen on your pull request so if I look at any one of these pull requests. I think that this one required that you build blue ocean in order to check that the change was reasonable. Okay, so I don't think you have to build the plug in. Good, good point. Was was that what you were asking piece or did I misunderstand. Yes, yes, that's what I'm talking about. Okay, and in fact this is nonsense I've got this task here is this task is not related to inclusive naming. Right because what we found is we by choosing to only change things that were in Java dot comments in HTML files and in jelly files. We've been able to avoid any requirement that you have to compile the plugins or even test them right it's they are simple string manipulations in safe locations. So, so I think I this should be deleted from the document, because it doesn't help you and it won't help future projects if we do this again. Good catch thank you. So let me put myself an action item here. Got it. Okay. Peace anything else. Any other mistakes that you found like that. Nope. Okay. Okay, on my on the inclusive naming sheet. I, there was one indicated post that's on the inclusive naming spreadsheets. Okay, so I'm on the inclusive naming spreadsheet and email. email. And let me find the earlier one so Oh you said paused. Okay. Okay, when you open the plugin. Get on the naming. The terminology to be named on this plugin is a white list. Okay, good. All right, so there's use of the word whitelist. Okay, so I saw lots of white list. Right. Oh, okay. Exactly. And but now the question is which of those can you actually change and which, which can't you change right. Because when I am when in that dog file. If you scroll down you see one dog file when you change the whitelist to allow the the English term does not it's not sounding correct again. Exactly. And that's been that's been a, that's why the term the replacement for whitelist with something else inevitably needs it requires that we use some better phrasing so it's it's not a simple string replacement. It has to we have to use some phrasing form that that describes it there you're exactly right so this recipes dot a doc file is is the example. Okay, if we look for whitelist. Filting recipient recipients on a whitelist on and probably in this case it should be on a list of allowed from on a list of allowed recipients or from a list of allowed recipients are based on a list of allowed recipients. Now let's let's test it with the rest of the group okay Daniel's confronted this one in particular Daniel any comments from you. So we have a straightforward replacement term in allow list. However, I found that subjectively just doing the straight forward replacement of whitelist with allow list, sometimes was not particularly helpful or it just gave the impression that you're missing some information there. So, we have a straightforward one, but I would recommend thinking about, well, is there a better way to phrase this to indicate what is being allowed. Excellent. So peace are you come and and this one is a really good one for for several pieces like for several things like that. For instance, whitelist here means a list of allowed email recipients, this variable name, given that this is sample code actually could be replaced. Likewise, because this is sample code, this death thing could be could be replaced so this is one of those, one of those conditions where, because it's sample inside a document, we can actually do the replacement. Most times I would say oh it's code don't don't touch it because you'll break it. But in this case, you actually can use better wording to describe what what it means so filtering recipients based on the list of allowed user allowed email recipients, that kind of thing. Does does that help you with your question piece. Yes, it does. Very good. If I delete the whitelist and write a lot the phrase not sounding correct and I'll be like, what's going on. Exactly. Yeah, that you're, you're exactly correct and that's that's just exactly as Daniel noted that. I guess we could do the simple textural replacement, but then it feels like you're missing information right it doesn't feel right to say, allow list, it's just not telling the user what they really need to know. Very good. Thank you. Does that does that also apply to areas with the branch name master. It's referring directly to the master mean that the branch name. It very much does Catherine yeah good good observation as well so, so the when when documentation describes a branch name and uses the word master to describe it. We have to look at the context quite carefully and decide is this talking about a branch that is exactly the branch name of a specific repository and that repositories master as its convention, or is it a reference to the primary default branch of this repository and in this could be used the term main branch or primary branch. Again, this is one to check in with Daniel since he's here with us. Daniel what's your experience been on referring to the names of default branches in get. So, exactly that. So, historically, get get up and so on use master as the default branch name. And so every said everyone just said master branch, and all the repo still have that as the branch name now the problem as far as I'm get hub specifically if you create a new repository will use the main branch and they kind of a notch people towards that name, even in existing repositories but there's still a lot of repositories around that use master, and get the tool itself as far as I'm aware still uses the master name. So, since there's no longer this fairly strong convention to have a master branch name and it differs on. It's different on the various environments my recommendation would be to call it the default branch as just a more generic identifier of. I mean the default branch now there are two limitations here. One is as Mark as you said, if it's a specific repository and it has a master branch, we're going to call it the master branch if we need this level of specificity. Mark, you will know this as the maintainer of the get plugin. We still have not been able to migrate from the implicit default branch name master because that would break all existing configurations that rely on this being the historical default. In that specific context that you will be able to describe much more accurately than I am. It would remain master as well. Thanks Daniel thanks very much so Catherine did, did Daniel's description, give, give the answer you needed. Yes, it did. Excellent. Thank you. Thank you. So, so good point that whitelist blacklist and master all have cases where we've got to, we have to think more, more deeply about what we're describing and read the text that we're using to fill them in more more accurately. Very good. Excellent. And yeah, as Daniel said I could tell you some horror stories about certain certain plugins inside Jenkins that struggle mightily when people change the default branch name. It's a very reasonable thing to do and command line get has actually now made it an option so that you can say my default for all new get repositories with very recent command line get versions will be named main instead of master or default or something else primary. You could choose the name but that means certain plugins have really challenging situations and how do we deal with that change. Good. Excellent. Any other questions. Peace from you or from open for or from Catherine. If you go back to the sheet. You can see the areas that I had highlighted the yellow. Those are the areas that I had queries in the latest one, the latest edit. Oh, here we go. Okay, so this one, this one and this one. There are there are a couple of plugins that have like like the first highlight that have a similar repo GitHub repo to another plugin. Yes, very good and good observation so here what we see is pipeline stage tags metadata. I think that's enough uses the same exact get repository as two or three other plugins. And, and if you look at, if I remember correctly it's the blue ocean plugin has a similar thing where it has multiple plugins delivered from a single repository. And actually that's because it made sense for the development of that plugin to to develop to place multiple plugins into a single repository because they were strongly connected to one another. In the case of pipeline stage tags metadata I believe it's because it is a fundamental component of the Jenkins declarative pipeline, and the repository it's in is actually the Jenkins declarative pipeline repository. So, so you're correct to say, Hey, this is the same repo. Now the the other one that you note here the handlebars repo, that's the same repo but for a slightly different reason. This one is the okay so the handlebars plugin or the handlebars bundle handlebars what you call it JavaScript bundle is stored in this JS JS lives repository, along with an old copy of bootstrap. A sedator jQuery moment and numeral. So, so there are some of these several JavaScript libraries that are in a single repository so you have to is visit those ones. Okay, Marcus so should they make one pull request per sub directory or sub plugin or just one big for each repo, you know, either either would be fine. Either would be fine, either would be fine if I'm hoping that this thing doesn't have many references to master but I've never checked Catherine what was your experience. Was this one where you said oh there are a lot of places where it has inappropriate terminology. No, no one that had a lot of issues we covered it last time. Okay. Yeah. Great. Excellent so yeah so what you're, and you, I think you'll find the same thing in in a number of other open source projects in a number of commercial projects where sometimes the boundaries between repositories and things we're delivering are intentionally shuffled in order to make it easier for the development team to maintain that thing by putting them all in one repository in some cases it makes it easier to make changes. Okay, that's okay. And then that means the moment JS plugin also shares the same repo as the one that we had just opened. Yeah, and I did notice it doesn't have the GitHub link on the Jenkins website. I think if we look at moment JS will see that it's, it's release. What would you call it it's when was yeah the last, the last time it was released was six years ago. And this these links are in general only updated when we do a new release and we we don't in this case need to release a new version of moment JS. I hope not anyway. And, oh, and this is even declared as deprecated. I don't know the history of this particular module bundle so forgive me if I say something wrong Daniel or if I'm failing to cover history here correctly. Okay, those are most of the issues that I encountered. Thank you. Excellent. Thank you. Any, any other questions. Okay, then maybe let's go forward on our time our agenda next item was the timeline. So the, the next events that are coming is May 19. I think it's May 19. Now I'm going now I got to look at the, at the timeline. I believe it's next Monday is our. May 19 is the is the end of the development phase. And that's beginning May 19. We start the final final project report phase. And that lasts for two weeks. In the project report phase what we what we need to do is, each of you writes, each, each contributor writes their own report and the Jenkins project writes a report so the mentors write a report. And we need to will post a blog post. Highlighting the accomplishments. And then by the end date, which is, let's see 19 plus, I think 14 days so think end of May you submit your, you submit that final report to the she called Africa organization. Likewise for us. Okay. So what do you have on the, on that part of things. I do have a question. Because from the sheet, it shows there's quite a number of plugins. Is it a requirement to complete all the ones that you assigned to us. Oh, no, no, no, no, not even close Catherine. No, no, no, no, no, no, absolutely not what what we're going to do with this sheet. What what what we will continue to do as a project with the sheet is we're going to use this to guide our efforts. So you've already done some looking to see if there were changes needed so we now know we can skip over these will can we'll use this sheet can in an ongoing basis to do more work on these kinds of efforts. So no, no, you do not. I feel like you've done a great job. I would love for you to do even more before the end of the week, but my sense is there is no way did we ever expect that you would complete well, let's look at the number. 1,800 repositories. No, no, no, never, never assumed anything like that. It was just, we'll work as many as we can. We start with the most popular first and keep working down the list. Okay, I'll definitely try to cover as much as possible. Super. Now, I did get a question in a preceding meeting, are we allowed to continue doing this even after the project ends and the answer is yes, absolutely. I understand that the project is intentionally for a specific time, and it's funded so that you can afford the time to do it. We know that you've got lives outside of the Jenkins project and you've got work or school or family. And we understand that but if you're able to continue we certainly welcome you to continue as well. Okay. Thank you. Hello. Hi, Nafisa. Okay, so my question is based on the report, do we have to update our folders with the report with the final report? Sorry, I missed that. Do the audio, so do we have to update what? Do we have to have a folder on the Jenkins contribution? Do we have to update our final report on our personal folders? Ah, good question. All right, so in general, no. That's a, so let me, let me highlight what Nafisa is indicating. So in the projects folder that we had on Google Drive, we have an inclusive naming, or we have an inclusive naming folder. We also had a people folder, where for each of the participants, we put a folder for you so Catherine's folder is here. Pieces folder is right here. What Nafisa was asking is do you need to update your copy of the document that we put there for convenience? The answer is no. That was just to help you as a participant as you were organizing your thoughts. You're welcome to provide your summaries separately. You're welcome to keep that private if you wish. You don't need to feel like you have to share your insights or comments publicly because if there was something that went really badly with the project or that you think I really need to say something very harsh about Mark Wait. You should be allowed to do that. And, and you go ahead and do that and submit it to Sheikot Africa privately. You don't have to put that your final report into these folders. Nafisa, was that the question you were asking? Yes, that was my question. Thanks. Thanks very much. Go ahead. On the on-boarding, I remember they not made a statement that with the reports should be made published on any platform. You can publish it on Ashnode, Medium, like you can publish reports, but make it public so that they can view it. Okay, so if you would like to make it public, we've got a great, I had forgotten Zenobs guidance and she certainly is the one who would be the more important one to listen to on that. If you would like to post it publicly and wouldn't mind posting it on the Jenkins blogs, each of you, I can, we could certainly do a session after the end of project to show you how to do a Jenkins blog post. You could also even maybe it's even easier. If you want something that's even easier to submit than a Jenkins blog post, you could post your report to community.jankens.io. Because here it's it's as simple as writing a writing a text file. So if you're interested in post having a place to publish post publicly, this would be a great location to do it. So, so piece what did you what does that sound reasonable did I address your question there. Yes, that was what Zenobs said, like we should post it we should make a blog post about it, and then forward the link to the code Africa. Very good so let's I had forgotten that so let's let's use, I would propose we use community Jenkins.io as the public location for your for your report. Because that lets you want it lets you embed pictures if you want. You can insert graphs, you can do, you've certainly got text, and it's easy text editing so it's, it's far simpler to do a posting to community Jenkins.io that it is to do a new blog post on on the Jenkins.io doc site. Okay, please can I ask a question but it's not, it's not related to this this particular topic but it's something concerning the gift of, is there a way that we can, for example, the last time I commented on the, I made a comment on the gift of it on one of the gift of plugin I made a mistake I wanted to correct it before creating a pull request, but I am finding difficulty correcting it. I want to ask is there a way we can correct mistake after making a comment, then we can go back and correct that comment before creating a pull request. So, so the answer is usually yes. And it depends on on what you what you mean by correct it so so is it okay if I bring something up to try to answer your question. Yes, please. So let's take. Let's pick one of the one of the pull requests as we're going to borrow one as an example and we're going to make things up about it so what if we pick this one. So, here's a pull request and I think what your is your question asking. Hey, could I can I change this commit message this rather than master use controller is that what you're asking or are you asking how to change some other part of the pull request. I mean this master already this one. The commit already made like I can't shoot master and use controller. Maybe I want to change that controller to mean or something else, without having to. Yes. So I'm asking if there is a way it can be done. And there is the typical way to do that is to just add another commit which makes the change. So I committed the first commit I did may have had a spelling error, and the simplest thing is submit another commit that fixes that spelling error. So that's that's the easy way and that shows a history then the person who receives, who reviews the pull request may choose if they wish to do what's called a squash merge. So what it does is it takes your multiple commits, and combines them into a single commit. So that you're all of your, well, in my case I make many mistakes while I'm doing these things. And I squash merge because it hides all my stakes, all my mistakes into a single commit. So that's one way to do it. Now, now that's, that's what I'd call the easy way to do it, because you don't have to really change your workflow you don't have to use exotic command line options and you don't even have to use command line get. You can do all that from the GitHub UI. There is another way to do it if you're willing to bring out command line get where you clone it locally, and you do a get commit minus minus amend. And what it lets you do is rewrite the thing. And you can change the message you can change the contents, but then in order to push it to get hub you have to use the very dangerous option minus minus force. I say very dangerous because it's destructive. So, so avoid the option minus minus force if you possibly can but it's available. So there are those two ways to correct a mistake the easy one, which I think should be the almost in 99% of the cases you should use the easy one, submit a new commit. The easy one is overwrite the commit and force it. And that one is dangerous because you can destroy things. So peace did that answer your question. Yes, those thank you very much. Oh, good question and just so so you understand the real life. There is serious damage by using force pushes to repositories. So, so be very careful, especially if you put the force option in a script. We've had episodes where we, we had really serious damage done to things because someone iterated over a bunch of repositories doing force force pushes. So be be very careful with the force option. Okay, thank you. Any other questions along those lines. Okay, so I'm going to go back to the earlier on the final report. Now FISA, I realized that that this may be a perfect place for us to ask for your help on sharing with other the other projects in the chicote Africa contribute on for Jenkins to ask them to do their, their final reports to jb.Jenkins.io as well would you be willing to do that maybe we have you actually act as the first as the first example and create one that we can say hey here's how it's done. Okay. I believe that I think I need to have explanation on that. Do you mean I have to create the blog post of my own, and then posted on the community Jenkins blog page. What I was thinking is if if you were to create a some your create the first beginnings of your, your final project report, and it could be pretty simple saying hey, this is the beginning of a project report and put it on Jenkins that I also that others see it. So, post their public project reports to community Jenkins that I would you be okay with that. Yes, I can do that. Thank you. Thanks very much. I have a question. You'd mentioned about submitting the report, the article, you'd mentioned another option of I think submitting it as documentation. Yeah, but yes so there's, there is another another way we could could submit it as as a blog post to www.Jenkins.io. But that is more difficult because it requires that you write it. It's a GitHub poll request must fit the ASCII doc, the adoc format, etc. So is, is that what you were asking Catherine or did I misunderstand your question. Yes, that's what I was asking is there a guide that someone can read because we are short of time that if someone wanted to try out an alternative to see how it works. Oh yes, absolutely. Yeah, so there are, there's a contributing guide on Jenkins.io let's go there, and you can read the contributing guide and it talks about how do you create a blog post. So if we go to the contributing guide and adding a blog post, and I'll just embed this link into the document here. See the contributing guide for instructions. So it very much has instructions on how to do that if you'd like to see what would it take to post a blog post to Jenkins.io. Okay, thank you. I'll check it out. Great. Thank you. Yes. Okay, and so now I have to admit for the Jenkins project report to submit to Sheikot Africa. I'll have to check with with with Xenob to see if she expects that one to be public or not. Not because we've got at least one participant where she hasn't, she hasn't actively participated for at least three weeks. And so I'm hesitant to say that publicly in a, you know, big, but I'm going to tell it to him privately saying hey, one of the participants didn't participate. Okay, Mark to check. Good. Anything else on the final project report phase. Okay, so what happens in the last two weeks final project reports. And I assume she code Africa will probably do a host a meetup of some sort or an online session to highlight the accomplishments, etc. But I'll have to double check with Xenob on that. The next point for me was reviewing progress to date. And, and the sheet. Now Catherine and peace. I assume you're putting your pull requests into the sheet. Are there any that aren't in the sheet that we should be reviewing. So are there any that are missing from the sheet, because we could also look at your GitHub history and try to grab them from there instead. None for me, all of them on the sheets. Okay, great. And peace likewise for you are all of your pull requests on the sheet or would you be willing to put them on the sheet so we make sure we review them. Yes, they're all on the sheet. Perfect. Excellent. Thank you. All right. Well this this is great. Any other topics before we conclude for today. Thanks. Oh, we've got. I'm going to go ahead and turn off the recording.