Depending on what kind of position you're in (e.g. ops, dev) this situation from my workplace might give you a hint on how information exchange should happen:
At work we are dealing with a lot of technologies, systems, applications, each with their own quirks.
None of us can be a jack of all trades there.
So we are asking each other.
You ask others who might be the best to ask for a certain task.
If you express your willingness to learn to others you will likely end up in a "I'll show you one instance of how to do this so you can do the rest" situation.
This is for our business stuff, like "how to rollout an SSH key" or "how to install a webserver certificate".
One thing that is very useful in our job, as GNU/Linux server administrators is to be able to use the shell effectively.
This is something you do every day, at almost all times.
It is something that not everybody is more than 80% comfortable with.
Often the problem with programs you use at all times is that you find "your way" to do things, even if there's an unobvious but way faster or "better" way.
It can help for someone experienced with the usage of your $tool to sit beneath you for a few minutes while you are using it.
This might not be possible in all cases.
15 Minutes.
Every week we have one presentation taking about 15 Minutes.
This need not be anything that is interesting for everyone but a sufficiently large group.
It's a presentation that just sums up a small topic.
Examples include "hey, I found this awesome framework for writing CLI tools in python" or "How I use $tool".
It's also good to make these presentations accessible to everyone, not just those who need it at work.
Onboarding.
You wouldn't believe how important that is.
Write certain things down.
As others already suggested, there's lots of Wikis or Wiki-like things to put information into.
Document known processes.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Depending on what kind of position you're in (e.g. ops, dev) this situation from my workplace might give you a hint on how information exchange should happen:
At work we are dealing with a lot of technologies, systems, applications, each with their own quirks.
None of us can be a jack of all trades there.
So we are asking each other.
You ask others who might be the best to ask for a certain task.
If you express your willingness to learn to others you will likely end up in a "I'll show you one instance of how to do this so you can do the rest" situation.
This is for our business stuff, like "how to rollout an SSH key" or "how to install a webserver certificate".
One thing that is very useful in our job, as GNU/Linux server administrators is to be able to use the shell effectively.
This is something you do every day, at almost all times.
It is something that not everybody is more than 80% comfortable with.
Often the problem with programs you use at all times is that you find "your way" to do things, even if there's an unobvious but way faster or "better" way.
It can help for someone experienced with the usage of your $tool to sit beneath you for a few minutes while you are using it.
This might not be possible in all cases.
15 Minutes.
Every week we have one presentation taking about 15 Minutes.
This need not be anything that is interesting for everyone but a sufficiently large group.
It's a presentation that just sums up a small topic.
Examples include "hey, I found this awesome framework for writing CLI tools in python" or "How I use $tool".
It's also good to make these presentations accessible to everyone, not just those who need it at work.
Onboarding.
You wouldn't believe how important that is.
Write certain things down.
As others already suggested, there's lots of Wikis or Wiki-like things to put information into.
Document known processes.