 Three, two, one. Hello, thank you for the counting. So good evening, good afternoon, good morning, everybody. This is an informal GSOC office hour where no real agenda is foreseen. We just meet and answer questions. We recorded a little bit late. And there was an interesting question from Mukul where he wanted to have some ideas and maybe advice on how to better handle discussions on GitHub. So it appears that Mukul proposed something or somebody proposed something in a PR. Additional informations were requested and somehow the point was not really understood. And there was an impedance mismatch and it didn't work. So the communication did not work. So I open it. So who would like to start answering? I just have one question. I just posted a link to the PR that I think you're referring to, Mukul. And could you please confirm that that's the one? All right, so OK. So I'm just brooding through the PR. And I see that so there's a lot of a change with Chris, the maintainer of the plugin. And from what I see, she's trying to, she's not here. Sorry, he is trying to push you to express what you're trying to say in the PR a bit more precisely. And the different exchange, at the end the PR was closed because it was not answering the issue you mentioned at the beginning of the quest. And we had a lot of documentation and a lot of explanation going through the PR. And so I think in the end, Chris added the RFE label just to mention that maybe that's more a new feature that you were trying to address rather than a fix or something like that. But to question how to handle better the miscommunication and so on, I think on both sides, you did your best to explain your different points and the different aspect of that PR. It seemed that I didn't pay attention to the time window. So it's all happened in the same day. But I see that there's like 38 messages exchanged in that PR. I think at some point when you reach that number of messages and the point is still not understandable or comprehensive for both parties or everyone involved in the PR. It probably means the only solution forward is to close the PR because it seems to have a fundamental miscommunication or disagreement that will not reach any constantious or reach any viable solution for both parties. And in the end, it's not like a dictatorship. But the maintainer has the power on the plugin. He can accept because in the end, the maintainer is responsible to keep the plugin healthy and to keep the plugin working for a very long time, more than just your contribution. So it did happen to me in the past also to refuse a pull request just because I didn't see the point of the pull request. I didn't see what was the value of the addition. And because I was not sure how to maintain that in the long term. Maybe you're trying to solve a solution, but the way you are trying to solve it is not the best way to do it and not the most maintainable way to do it. So don't take it personally. It's not against you. It's not because you are you because of whatever personal reasons really. In the end, I don't know Chris personally, but I'm sure the reason is just for the sake of the plugin else and its long term maintainability. That's all. So don't take it personally. I think you did your best to try to make a point and try to offer your solution to the plugin. But in the end, sometimes it doesn't make it. It doesn't mean that you shouldn't try to contribute to it again. It doesn't mean that you should stop contributing to anything on the contrary. Please continue. You will learn from that. And maybe next time it will be easier for Chris to understand your point or to understand what you are trying to add. One comment I would add maybe to improve the being of the pull request is your first message of the pull request is quite small. It can make sense to you. But maybe being a bit more descriptive on your first when you open the pull request will help a lot in the future. In many case, I prefer to have a five minute read when I open up something to read for five minutes when I first on the first message of the pull request. That sets what the pull request is trying to solve, why the problem was reported, how the pull request author tried to solve it. What is the context to reproduce the problem if it's a fix on what is the miscommunication or the misinformation in the documentation that you're trying to change? So half of the work of the pull request sometimes is the pull request description itself. OK, very good. I have a few comments before maybe letting somebody else. So first thing, it is a super ID Mucul to have raised that question. It's very interesting. And we would like to help you understand and see what happens. So the summary of what Adrian said, it is very important that we have efficient communication. The reason for that is that mentors or maintainers have a lot of parallel requests and things to handle. So the advice of having a strong description at start definitely helps to get the review going. The second thing that I've seen is that there were a lot of confusions in from what I've seen in it. So several topics and at the end, it was somehow related to the issue, but not really. And the idea has been picked and flagged as a request for enhancement. This is the meaning of RFE, if you are wondering what it means. So this is a request for enhancement. So he said, OK, this is an idea we need to keep note of. But at the end, looking at it, it was far too confused in too many things. It was better to start again on a blank page and take it over later. Mukul, does that make sense to you? And then I'll give work word to others if they want to comment on it. Mukul, go ahead. Yes, yes, yes. How did you feel about that? At first, solving that PR, firstly, I learned a lot. I learned Ruby. I explored the GitLab code base for this, like how they are approaching this and what they have done and on the GitLab plugin page, like how it is handled, why that bug was happening. So throughout this, I learned a lot, even though the PR didn't get accepted. But I want to like. Did you feel attacked? No, no, I didn't feel attacked. What Adrian said, I accepted what Adrian said, that my PR at start wasn't clear. Like it didn't mention the points that I had to mention afterward in the conversation. So and I didn't feel attacked. Like it was normal to have conversation. I didn't clear it out what I was trying to do in that PR. So but like what I want is to clear that what I can do in future that make my PR accepted faster. Based on the conversation that from Adrian and the summary that I tried to do, what would you do? What did you learn from it? Basically that at start, I have to summarize what I am trying to do in the comment, not comment, in the PR itself, like description of the PR, that like what I can converse later on, like what I can explain later on the through the chat, through the comments, like what I have tried to talk with the, with Chris, the maintainer, with Chris. I can do that there on in the comments, in the comment of the PR, like there is a while raising it. So this can clear it faster for the maintainer so that they can easily accept it when like they can easily understand it when they just go through it at the first time. OK, now, especially when you're learning and you're getting into a code base and things like that. So put yourself at the place of the person reading it. And ask yourself, how would I react? How would, because here it's a conversation of 35 messages or with just a limited number of information. So try to think, oh, he would like to know this or he needs this context. And so it's not because it's clear in your head that other people know what you have been thinking about. So take the extra step to to give the context, explain the problem you're trying to solve so that we have this flow of somebody else. And this is an important skill to to acquire. Is there somebody else who would like to to give a comment or ask something around that? I liked your question very much, Mukul. It means you're thinking much appreciated. And just to add a lot of the open source work is on communication as well. It's very important. We all work on different aspects. We have day jobs. We but we all are focused on the same object, at least for a period of time and communicating and expressing yourself is very important. So the this meeting, for example, is one way to do that. And we have other sign meetings in Jenkins community. We have the meaningless to get or discuss and so on and so on. And so we have many ways to communicate and through PR like you did everything. Yeah, it's very important. And in the end, if there is something that is not clear to everyone and mainly to the maintainer, that that's why it got closed in the end. That's my personal opinion is if there's I mean, if there's something that is not understood correctly by the maintainer, it's is right to to close. Yeah, now he's policing and organizing the work on his plugin and we need to respect it. He's responsible of that. So at certain times I hear this this conversation is leading nowhere. Maybe hint on. Maybe restart or. Or so or or take it up later. So especially as here. We are now in a special period. Where we try to concentrate on the proposals and only the proposal not to be influenced. By external things. So anyway, good, good question. And we'll try to explore that later in other discussions, how we can improve that. I have a question like in the Jenkins community, we have a lot of online meetings related to different stuff. And like I just I was just exploring. So should I try to attend every meeting? It's very hard to just try to get to know everything. Oh, where do you think I got my gray hairs from beside of my daughter? It's just it's a huge amount of information. So, yes, I know the pain. I know the pain and but. Here, the only thing I can say is. You're in front of a big mountain. And it looks very, very high and difficult. And once you start one step after the other. You will realize, oh, it's not that complicated. I'm in the middle, you will still be focused on the top. But if you turn around and realize. Oh, I know already all that. So I'm mastering these parts, these parts. I can help others that are lower on the mountain. So don't give up. And I know the feeling of this, this. Downing pressure there. The only thing I can say here, how exciting it is. There's so many things to explore, try to understand. But I stopped chatting. So there, but a good point, good point. Yes, it's actually very interesting to explore everything. And it's just so overwhelming, get to know everyone. Yeah, and the work. Now, I will take again my my. Lead mentor or lead or Gadmin, their hat and say here. This is really the interesting school. Of this open source adventure that you are embarking, that you embarked on are still in your learning many, many skills that will be very helpful for you. Professionally, later in your open source career and also as as a person. So you're you how do you organize your work, how you organize your your time, how you discuss with people, how do you learn a new topic? So this is an incredible tool to to in in the. Well, I'm advocating and selling it, but I think open source is is. Is a great way to invest your time outside of school. I shouldn't be so much advocating it, but I strongly believe that. And you made a good choice. OK, so this time will stop on time in three minutes, because we have so I have a meeting. In three minutes and even have a conflict between meetings. So I'll have to flip a coin to decide which meeting I'm going to. And I see Alyssa smiling, so she knows what I'm talking about. So we're going to end here. I'm just opening for a last minute comment or question or whatever. Otherwise, we're going to switch off. OK, so thank you very much for attending. It's great to meet you all in exchanging. Continue. The best and I'm very honored. To participate in that so. This said, I will close the call and move to other discussions topic. So I have a great week. Bye-bye, everybody. Thanks, and thank you. Thank you, everybody. Bye.