 Welcome, everyone, to my talk about asking for help. And thanks for sticking here for the last day afternoon. My name is Jakub Schultz. I work as an engineer at Red Hat. And I'm also a maintainer of the community, which is called Strimsy, which is cloud-native computing foundation project, which is about running a Pachikavka on Kubernetes. And I guess as many of us, I kind of have the experience with asking for help from both sides. On the Strimsy part, I'm often the go-to guy who has all the answers. But then, for example, in the Kafka community or in the Kubernetes community, I'm the one asking others for help. And I kind of see a lot of inefficiencies in how this works, usually. So that's why I kind of decided to give a try with this talk to improve it a bit. So I think that helping others is kind of one of the most common parts of the open-source community life. It's quite normal that there are people who come and ask whether some feature is supported. There are people who ask about how to use some feature, how to implement something, how to architecture something. And there are, of course, also many people who come. They already run the project in production and then suddenly run into some issues. They don't know how to solve it. And they come screaming, help, help, my production is down. So these are just some examples of how people might be asking for help in the different communities we work in. And in general, this is an important part of the community life and of the community process because it obviously helps us get new users. It helps us onboard the users and kind of make them from people interested in the project into the users of the project. But it also facilitates feedback. When we see that a lot of people are asking about some features, then maybe if we don't have the feature, then maybe this is something that the people are interested in and we should consider adding support for it. Or if it's a feature which we have support for, but a lot of people are asking about it, then maybe our documentation or maybe the way it's implemented, the usability is not really good enough. So that's another kind of feedback. And finally, if someone has some problems somewhere in production, then maybe it's some bug somewhere which should be fixed. So this is kind of a big part of that. And another part is that when people ask about something in some forum, then usually that's kind of safe, that's archived, and it's searchable. So it serves also as a kind of knowledge base and as a material for further learning. So other people might then see the questions, they might read the answers and see, oh, this is something I didn't know about. And this is really something that's not unique to open source communities because that happens everywhere. Colleagues are asking for help. Or if you have paid support for some software, then you might be asking some support hotline for help. What makes this a bit unique for open source communities is that a lot of this happens on a voluntary basis. Even at Red Hat, many of us are basically paid to work in the open source communities. There's still a lot of time which we spend there over the weekends or evenings trying to answer some questions, which is not really paid. So really a lot of this is for free and voluntary. And this makes it a bit special and that's why is one of the reasons why I think we should kind of try to make sure that this is as efficient as possible and doesn't consume time, which it doesn't need to. So how does this consume the time or how can this be inefficient? If people ask the questions in the wrong way, then maybe there will be several loops and several iterations where someone has to kind of, OK, you said this, but can you please share the configuration? Can you please share the lock and so on? And all of this takes time. In between that, people need to kind of switch focus. So maybe they were working on writing some code. Now someone asked the question. So they have to switch the focus, try to answer something, and so on. So that can be quite inefficient. And I believe that improving this and making this as efficient as possible is kind of a win-win situation for both sides. Because if you look at what the users typically want, then yeah, sure, if they ask for some help in any form, they usually want to get the help as quickly as possible. If it's some production issue, then it's maybe super urgent. If they are just asking about some feature, maybe they don't care whether the answer is in one hour or in one day. But yeah, they usually want to get these answers. But at the same time, they want probably the software, the project to get bug fixes. They also want the project to get some new features. Because if you are using some kind of project, some software, or if you are planning to use it, you don't really want to start using something that will not get any bug fixes for the next six months. Because everyone from the community is busy answering questions. So it's in their interest that the kind of answering the question and answering, providing the help, doesn't consume all the time, but that there is time for other things as well to keep the project alive. And similarly, if you are some kind of committer in the project, then of course, you are interested in helping your users. One of the reasons why we are doing this is that we want to have users. We want to have usually as many users as possible. So yeah, we want to provide the help. And we want the users in general to be quite happy. So yeah, sure. But at the same time, a lot of the people in the community, the commuters, they don't really want to spend all their time just answering some questions. Some of them might prefer to write code most of the time. Some of them maybe want to do some testing. Some of them want to write docs or do some other parts of the community work. But not everyone wants to just spend the time answering, answering, answering, answering some questions in some forum. So they also want this process to be as efficient as possible. So let's win-win for everyone. Now, how can you improve it? And I believe that the right way or easiest way how to improve it is by asking the questions in the right way. And actually, that means that maybe if possible, you should try not to ask the question at all. And you should first try to help yourself. That means that, for example, you can try to Google the question and try to get the answer from Google. But it can also mean that you should use the documentation. Most projects have some documentation. People invested usually quite a lot of effort into writing the documentation. So please try to use it. And don't worry. It doesn't mean that you have to spend hours and hours reading hundreds of pages of some documentation. Most projects have this kind of single-page version of the documentation, so you can just open it, press the magical Control-F button, and then try to search in it. And maybe you find the answer. Maybe you don't. But you at least try it. And if you try it and it didn't help, I think it's great to kind of mention it in the next step when you actually ask the question. Because A, let's be pragmatic. If the people trying to help you see that you actually tried to help yourself first and you tried to do something on your own, it will be kind of a bonus point for you. But there's also more pragmatic part about it. And that venue, for example, started the question, I'm looking for this and I searched in the documentation for this term. It again provides a feedback to the project. Maybe the documentation calls this feature with one term and it turns out all people are coming and searching for a completely different term. So the community can kind of go and change the documentation to do some rewarding and use the other terms there as well to make it easier to find for the next users. It wouldn't be a 2023 talk without mentioning ChatGPT, right? So I actually see it used from time to time by our users to kind of ask the question to ChatGPT instead of the community. My experience with it is very mixed. It sometimes gives very good answer, but sometimes it makes up some complete nonsense. In any case, it's always absolutely super confident that it's 100% correct and it is answering the absolutely right thing, right? So yeah, maybe that's an option. Maybe not. Maybe it will get better in the future. One thing which this definitely doesn't do is that the community doesn't really know what you are asking to the ChatGPT. So all this kind of feedback loop, knowing what features are people interested in, what problems they are running in, that's kind of lost because it will be only ChatGPT we will know about these things and the community will not see it in some selection. OK, so you tried to help yourself first, but didn't find the answer. So you have to ask, right? So the first thing to start with is finding the right place because there are quite often many different places where you can ask. There are mailing lists. There's Stack Overflow. There are GitHub issues. There's Slack, Discord, GitHub discussions, LinkedIn, all these different places. Some people try to ask for help, even with DMs on Twitter, for example. But there's always many options. And you should try to find the right place. And that can depend on several different things. First of all, what is the community actually using? And it's quite common that in the readme file in the GitHub repo, for example, most communities kind of have some section which is like ask for help or discussions and mailing lists and so on. So you can kind of find that and check the information there which is about whether they are using Slack or something else, whether they are using some mailing list. And all these things are often there. You should also think a bit about what type of question you are asking and how suited it is to the place where you are going to ask it. So for example, Stack Overflow is a great place. Vool from us didn't use it for at least something, right? But it's kind of well suited for specific kinds of questions. If you, for example, want to ask whether some feature is supported or for something fairly simple with fairly clear answers, it works well. But if you have a production problem where kind of analyzing it and debugging it ends up in a huge chain of questions, answers, logs being shared, it doesn't really work that well because the lengths of the posts are very limited. You can't really attach easily logs to it. And it doesn't have really that well integrated kind of the flow for questions and answers. So for that Stack Overflow might not be the best option and maybe some GitHub discussion where you can easily attach things or some Slack might be much better option. And obviously a little bit, it also depends on your preferences. Some people simply prefer to send the email and then read the answers next day. Some people prefer more real time communication and then they would, for example, go for Slack where they can kind of get questions and answers in a more conversation style. Something to think about is also whether you really want to ask the same question on five different places. There are people who go and ask the same question on Stack Overflow, Slack, GitHub issues, GitHub discussions, mailing lists, and all of that within two minutes, right? What is the expectation from the people in the community to handle this? Do you really expect them to kind of prepare the answer and copy paste it into all these different places? Or do you expect that kind of someone will reply here, someone will reply there, and you get kind of like a second opinion with some doctor? Or will they reply just in one place and all the other places will remain unanswered, but probably searched by the index, by the search engines, and then popping up in the search queries? So yeah, really think about whether this is the right approach and whether it isn't better to ask in one place and then give it some time for the answers before asking somewhere else. And it's also important to ask in the right community. Like I have here some friends from the Debezium community, and a lot of Debezium users use Debezium with the Strimsy project, which I'm working on. And in our community, we get a lot of questions about the Debezium project, and we don't know really how to answer them. And there's not really many people who know how to answer it in our community, because it's not really our software. It's more this other project. So by finding the right project, you can also save people's time, because you ask it in the right place. And also it much improves the chances that you get the answer, because if you ask in the place where the people have the answers for your question, then you can actually get the answer. Of course, sometimes it's quite hard to kind of know the boundary, know which project you are actually asking about. So it's not possible to do this always perfectly, but you should at least try. Another thing is that you should share as much as possible. You should share what versions are using. You should share the configurations. You should share the locks. You should share the steps, how to reproduce it. You should share what you actually expected to happen. You should share how the environment looks like, and all these things right away. I have two examples of questions which I see very often in our community. And you might not understand the details if you don't know Apache Kafka, but they hopefully give kind of the idea of the wrong type of question. So this one is, my Kafka producer fails with following error, not authorized to produce messages to topic, my topic. Anyone has idea of what the problem might be? And I have their idea right away, right? The problem is that the producer is not authorized to produce messages to topic, my topic. And if you look at the questions like this, then that's pretty much the only answer you can give to it. Now, typically this represents some bigger issue. The person asking this might not know how to use the authorization. Might not know kind of the right way how to use the authorization. They may have misconfigured something, or there might be some bug, right? But without kind of having all the other informations, it's basically impossible to say the right answer. So how this will end up is that someone will come and ask for more details, ask for the locks, ask for the configurations, and it's again, all these kind of empty cycles will just waste time and don't add anything real. Here is a similar question. My Kafka consumer is not receiving any messages, and this is what I see in my locks, and then single randomly picked line which the person thinks is actually the problem, right? And you might know Kafka, but I know Kafka and trust me, this is not the problem. This is just a regular info message. So when you are asking questions like this, you obviously don't know the answer. So you should not assume that you know exactly which line from the lock will lead to the answer, right? So sharing the full lock, sharing the configuration, again can be super helpful to actually find out what the issue is, and this is again another question which I see very often, but which will basically just follow up with some interrogation about sharing more information and more details. So yeah, if you ask the question, make sure to read what you are actually sharing and think whether kind of some magical answer can be provided based on that or not, and you should not assume if you don't know the answer that you know what will lead to the answer. So you should really try to share everything what you can or the configuration's locks, but you should also try to share the kind of more soft things, like what were the steps you were doing when this problem happened to you, or what were actually your expectations to happen because sometimes people just do something and something happens, they think it's wrong, but it's actually the thing which others expected to happen and which is there for some reason. Many of the projects use issue templates on GitHub which kind of can give you hints for what might be the points which you should share, like typically there might be some kind of form with questions, what version are you using, how you install it, on what Kubernetes version, for example, are using it and so on. So you can use this often as a guidance at what might be the important information you should share right away. And then a lot of projects have also some kind of troubleshooting tool which generates a report for you and kind of collects all these information. So you can check that out as well and if they have it, then you can kind of use this to easily collect all the important information. So share as much as possible and what's also important is using the right format. Probably several of us at least here use quite often Kubernetes and use YAMLs and what's special about that is that the white spaces in the YAML document are super important and if you just copy paste some YAML into some GitHub issue without proper formatting, then it doesn't show the white spaces and it's basically unreadable and nobody who sees it, it's hard to read but nobody can even say whether the indentation is correct or not whether the YAML is correct. So formatting it to making it readable is super important and ideally you should also think such as locks try to share them as a file so that they can be searchable or that they can be easily read on devices such as smartphones or tablets instead of for example making a screenshot of your whole screen, ideally with a phone instead of using some print screen tool and then sharing that. So you should share as much as possible but you should try to keep the secrets, right? So one of the dangers with sharing everything is that quite often you share things which are confidential, which should not be shared and some of these things are quite obvious like you shouldn't share any passwords, you shouldn't share any TLS certificates and private keys and stuff like that. So you can kind of try to look for these obvious things but there's kind of bit more to that, right? Different organizations might have different rules for what they consider as a confidential so in some cases you might be actually not even allowed to ask a question in some open source community with your company email because they don't want everyone to know that they are using this project and that they have some problem or question. In many cases IP addresses or host names will be considered confidential by most organizations as well and so on. So it's good to understand based on your organization what you can actually share and what's not allowed to share and what you might maybe anonymize and sometimes there's no other way how to do that then go through the locks, anonymize it, replace all the places but keep in mind the details matter and that you should use for example if you are replacing IP addresses you should always use different placeholder. You should not just flat out replace every IP address with some IP placeholder. You should for example use IP one for one IP address, IP two for the next one and so on so that it can still possible to see from the locks who communicated with whom and things like that. A lot of people try to work around these limitations by saying oh hey I will send you the lock in a direct message on Slack for example to do it privately to not share the locks publicly. Now first thing to consider is whether the community really wants to do this and whether the people trying to help you really want to do this so for example when it comes to me I'm not really doing the community support as a private support for individual persons on direct messages but other people might be fine with it but you should still consider some other aspects even if the people are fine with it. First of all the question and the kind of discussion will be not really useful for any kind of learning or any kind of knowledge base because if you have some discussion then some lock shared somewhere else and then the discussion continues you don't really know what was in the lock so if you are trying to solve something but seemingly the same problem but the lock is missing you don't know is it really applicable to me is it not and so on. But also maybe a bit more important are you actually allowed to share this thing with some random person on the internet through a direct message and usually the answer will be no in the same way as you are not allowed to share the locks with the IP addresses and so on in some public channel you will probably not be allowed to send it to some random person on the internet just because he works on some open source community project. The person will have no non-disclosure agreement or anything like that. You don't know how is his computer secure maybe he downloads it there and the next day someone hacks him or maybe it's just his son using the computer at the time and so on. So you should really consider whether this is actually something you should do in the first place or not. Okay, one other thing to talk about is kind of this language barrier. Who have you seen these four characters? W, D, Y, M. Raise your hand, nobody saw them? Yeah, most of you probably know what that means. So this W, D, Y, M stands for what do you mean? And so this title basically says what do you mean with what do you mean, right? And that's actually kind of something what I was asked by a user in our community but it's often the situation that in our teams in our kind of daily communication we are quite used to use these acronyms. What do you mean as far as I know thank you if I remember correctly for your information and so on. But other people might not really know what do these mean and might not understand them. So one of the things you can do is you can try to avoid them and you can try to write them in a full word because that will be more understandable to everyone on the internet. It's obviously using shortcuts and acronyms is not the only problem which comes with regards to language. I'm afraid the only help which I have with regards to the language is that again if you share the things, if you stick to the things such as the locks, the commands, the configurations these things are usually not translated, right? So if you have some cube Cuddle command or if you have some Linux Shell commands or things like that they are usually always the same in Czech, in English and probably in most other languages as well. The same applies for lock. Maybe you will have in different language the kind of error or info and so on translated but the message is issued by the applications. They are often always in English. So you can kind of use these and share these and they really help to understand the issues because that's something you can read. And from my own experience you can quite often answer a question which is for example written in Chinese without knowing anything about Chinese. But you for example see the commands, you see the lock and the configuration and you know oh this is probably this problem which someone else had before, right? And just from kind of these well-known things you can figure it out. One other thing I would add is that a lot of the people answering the questions on trying to help you they might not have bad intentions. They are just probably used to use the language differently with their colleagues. They might not be always able to easily kind of switch to a different mode and use a simple language when answering. So don't be afraid to ask something to be repeated or maybe to be repeated in some easier language or don't be afraid to kind of try to rephrase your question if you think it was not understood. Usually the people are kind of fine with people who maybe don't have such a great language skills as they do and they will try to do their best. It's just sometimes that they need to kind of realize that they should do this. Another advice is to be patient and give the community some time to actually get back to you to answer it. This is often different person by person. Some people don't like to kind of the switching context between different things. And for example, at the end of the day have one hour spare for answering questions on some Slack channels and answering emails and so on. So sometimes you have to wait for them to kind of get into this time which they have scheduled for this and then they will reply. For smaller projects it's also quite common that for example all the people working on them are in North America or in Europe or in Asia and they don't really cover all the different time zones. So if you live in the wrong time zone so to say and ask the question of wrong time everyone might be maybe sleeping and they reply only when they wake up. So be patient but you should also be aware that just because nobody answered doesn't mean that nobody cares about your question or that nobody saw your question. It can also happen that just nobody knows the answer and they just don't know what to reply. The last thing I would like to mention is that you should also try to give back to the communities when asking for help. Because yeah, let's be realistic. People always tend to help more to their friends and people they know than someone who's completely strange to them. And you don't really need to spend weeks contributing some software patches or new features to the project. You can do several simple things. If you already know something about the project you can for example try to help others who have some simple questions. And then when you ask something yourself the people will know, this is the person who was answering all these questions. Let's help him now. Similarly, a lot of the open source projects have some kind of adopters list or some kind of website with the logos of the users. And again, you can quite easily open a PR to add your organization to that list. And then when you need some help then the rest of the community will know, oh, this is the person from this organization. We have their logo on the website. They are our users. Let's try to make sure that it works for them and let's try to fix their production issue for example. So these are kind of some things which you can do very easily and which can kind of help to give back to the community. And that's it. Hope this was at least a little bit useful and I think we should have a few minutes for questions. So the question was that sometimes you try to help someone and you maybe help them successfully and then they start to kind of ask you more and more questions and they start to kind of use you as a personal search engine, personal Wikipedia and kind of ask at any time of the day and so on. So how you can kind of try to do, deal with this in a polite way. I hope I capture it correctly. So I think that's not easy and to be honest I'm maybe not the right person to ask about doing things in the polite way. So I think one thing which I do often is as I said if someone tries to DM me for example on Slack with questions, I usually tell them you should ask this in the channel shared with everyone and not ask this on the DMs. Often people simply just kind of CC you on Slack personally instead of just asking everyone in the community and then you get notifications and then other people might feel like that's especially for you and they should not reply. So again I try to kind of politely say please don't do this, don't kind of mention people in random questions if there's no real connection to the person and ask really just the community. And to be honest sometimes it works, sometimes it doesn't. I had a person who when I told them to kind of that something is documented they should look there for details. They told me that they will not look into documentation because asking and getting answer from someone else is much easier. So yeah sometimes it's hard to answer politely and kind of solve this in a polite way. Maybe to just try to rephrase what was said in the discussion from Publikum that it's important to kind of try to keep your time and your own energy under control and kind of try to make the people to understand that something is for example involuntarily and they cannot expect the same reply times and kind of handling in some paid support for example and so on, does that somehow capture it? Yeah, I think it's completely fine to simply explain that you don't have time that this is a voluntary based support. One of the things you can also do is kind of you can try to take more and more time to reply which kind of instead of replying every time in 10 seconds then if you reply in few hours next time and then in few days next time sometimes kind of you undo the thing that you are always being asked. You had a question? So the question was if someone asks a question in the wrong channel better the kind of question can be somehow easily transferred or something like that? Do you learn it? Yeah, so to be honest it depends a bit on where you ask. Like I don't think you can move the messages between channels on Slack that easily for example you can just reshare them in some other channel. On GitHub for example if someone opens a bug instead of opening a GitHub discussion you can normally use GitHub functionality to kind of transfer the issue into a discussion. So it depends on the platform. What I kind of try when someone doesn't ask the wrong question 10 times per day that I kind of try to tell them look this might not be the right community there might not be that many people who will have the answer for you maybe you should try to ask in the right community. So like I usually try to kind of direct them but yeah again that's something that costs time and sometimes until someone gets to that it might take a long time but I don't, I'm afraid there's no better and easier solution. Anyone else, Jakub? So the question is basically whether some communication guidelines might help to kind of reduce these things. To be honest I didn't try that so I don't have a real answer from the experience. I think it might be interesting thing to try and it might make it kind of easier to kind of point to these guidelines. But at the same time I hope talks like this would help to convince the people to first start looking into things like documentation. So I'm not really sure I would expect people to first read some communication guidelines before asking these questions. So like I think they can make it easier to reply but they might not make it easy to kind of avoid the questions in the first place. Yeah I think that it's interesting idea which might be worth trying here. Anyone has any other question? Yeah? So the question was whether there is some tool or some service which would kind of automatically hide the things such as IPs. And to be honest I don't know about any like in the Strimsy project for example we have this kind of report tool which collects the information. So we make sure that we don't kind of copy there the passwords and the certificates but we for example don't mask any IPs there or anything like that and I'm not sure about I'm not aware of any other tools which would be doing that. Okay we are out of time so thanks a lot for staying here and for watching I hope it was useful for you.