-
-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
New blog post:
Why You Shouldn't DM Developers
- Loading branch information
1 parent
0426cb3
commit 0d2b033
Showing
2 changed files
with
136 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,68 @@ | ||
--- | ||
title: Why You Shouldn't DM Developers | ||
description: Explanation of why direct messaging developers is not an effective way to solve problems in open-source projects. | ||
authors: | ||
- wopox1337 | ||
keywords: | ||
- developer communication | ||
- open source collaboration | ||
- GitHub issues | ||
- community engagement | ||
- troubleshooting | ||
- open source contributions | ||
- public discussions | ||
- developer time management | ||
tags: | ||
- open source | ||
- community building | ||
- collaboration | ||
- GitHub | ||
- developer guidelines | ||
- volunteer support | ||
- problem solving | ||
--- | ||
|
||
# Why You Shouldn't DM Developers | ||
|
||
Every day, open-source developers encounter questions and problems from users. But did you know that sending questions via direct message is far from the best way to get an answer? In reality, many issues are solved much faster and more efficiently when discussed in public channels. This applies to the ReHLDS project and many other open-source initiatives. | ||
|
||
When you DM, the issue remains "in the shadows." Only you and the developer are aware of the problem. Posting a question or bug on GitHub Issues or GitHub Discussions allows not only the developer but also other community members to assist you in finding a solution. After all, the open-source community operates on the principles of mutual help and knowledge exchange. The more people involved in solving the issue, the quicker it will be resolved. | ||
|
||
{/* truncate */} | ||
|
||
## Why Post on GitHub, Not DM? | ||
|
||
Developers are busy people. Every direct message response takes time away from tasks like fixing bugs, adding new features, or optimizing performance. While the developer spends time gathering information about your issue, other users could be offering a solution. | ||
|
||
Why is this important? | ||
|
||
1. **Open discussions**: When an issue or question becomes public, other users can share their solutions or suggestions. This fosters an active collaborative atmosphere. | ||
|
||
2. **Public visibility**: Everyone can see your question and help you find a solution, significantly increasing the chance of a quick resolution. | ||
|
||
3. **Resource conservation**: Developers' time is limited, and it should be focused on addressing larger and more complex issues, not resolving simple cases that could be handled in public spaces. | ||
|
||
## The Effectiveness of Communication in Open Source | ||
|
||
Platforms like GitHub Issues or Discussions are designed for users and developers to discuss projects and their issues. It's important to understand that end-users can't always objectively assess the scale of a problem. Sometimes, what seems like a critical bug may actually be a simple misunderstanding or installation error. This is why open discussions help all project participants assess the real importance of an issue and resolve it as quickly as possible. | ||
|
||
## How to Ask Questions on GitHub | ||
|
||
1. Be specific: Describe the steps that led to the error. | ||
2. Provide context: Specify the system you're using and the versions involved. | ||
3. Attach logs: This significantly speeds up diagnosis and issue resolution. | ||
|
||
Instead of DMing, create an issue with a detailed description of the problem. This will not only speed up the resolution but also help you avoid unnecessary waiting and uncertainty. | ||
|
||
## Contributing to the Project | ||
|
||
Remember, every question or message in public channels, whether it's a discussion on GitHub or in a chat, is a contribution to the project's development. This is much more valued than just communicating via DMs. Public channels help create a community where knowledge and ideas are exchanged faster than they would be in private messages. | ||
|
||
## Resources | ||
|
||
- [GitHub Issues](https://github.com/ReHLDS/ReHLDS/issues) | ||
- [GitHub Discussions](https://github.com/orgs/rehlds/discussions) | ||
- [Discord Community](https://rehlds.dev/to/discord) | ||
- [GitHub Boards](https://github.com/orgs/ReHLDS/projects) | ||
|
||
By creating issues, pull requests, or simply participating in discussions, you're already making an important contribution to the project's development. All discussions, bugs, and suggestions help not only you but also other community members, improving the project for everyone. |
68 changes: 68 additions & 0 deletions
68
...ru/docusaurus-plugin-content-blog/2024/12-12-why-not-to-dm-developers/index.mdx
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,68 @@ | ||
--- | ||
title: Почему не стоит писать разработчикам в личку | ||
description: Объяснение, почему общение в личных сообщениях не является эффективным способом решения проблем в open source проектах. | ||
authors: | ||
- wopox1337 | ||
keywords: | ||
- общение с разработчиками | ||
- сотрудничество в open source | ||
- задачи на GitHub | ||
- взаимодействие с сообществом | ||
- устранение неисправностей | ||
- вклад в open source | ||
- публичные обсуждения | ||
- управление временем разработчиков | ||
tags: | ||
- open source | ||
- построение сообщества | ||
- сотрудничество | ||
- GitHub | ||
- рекомендации для разработчиков | ||
- поддержка волонтёров | ||
- решение проблем | ||
--- | ||
|
||
# Почему не стоит писать разработчикам в личные сообщения | ||
|
||
Каждый день разработчики open source проектов сталкиваются с вопросами и проблемами от пользователей. Но знаете ли вы, что задавать вопросы в личные сообщения — это далеко не лучший способ получить ответ? В реальности, многие задачи решаются гораздо быстрее и эффективнее, когда они обсуждаются в публичных каналах. Это касается и проекта ReHLDS, и множества других open source инициатив. | ||
|
||
Когда вы пишете в личку, вопрос остается "в тени". Только вы и разработчик знаете о проблеме. Публикация же вопроса или бага на GitHub Issues или GitHub Discussions позволяет не только разработчику, но и другим участникам сообщества помочь вам с решением. В конце концов, сообщество open source работает на принципах взаимопомощи и обмена знаниями. Чем больше людей вовлечено в решение проблемы, тем быстрее оно будет решено. | ||
|
||
{/* truncate */} | ||
|
||
## Зачем писать на GitHub, а не в личные сообщения? | ||
|
||
Разработчики — люди занятые. Каждый ответ в личных сообщениях отнимает их время, которое могло бы быть потрачено на исправление багов, добавление новых фич или оптимизацию производительности. И пока разработчик тратит время на сбор информации о вашей проблеме, другие пользователи могли бы предложить решение. | ||
|
||
Почему это важно? | ||
|
||
1. Открытые обсуждения: Когда проблема или вопрос становятся публичными, другие пользователи могут поделиться своими решениями или предложениями. Это создает активную атмосферу сотрудничества. | ||
|
||
2. Публичная видимость: Все могут увидеть ваш вопрос и помочь вам в поиске решения, что значительно повышает шанс на быстрое устранение проблемы. | ||
|
||
3. Сохранение ресурсов: Время разработчиков ограничено, и оно должно быть направлено на решение более глобальных и сложных проблем, а не на разбор простых случаев, которые можно решить в открытом доступе. | ||
|
||
## Эффективность общения в open source | ||
|
||
Платформы, такие как GitHub Issues или Discussions, предназначены для того, чтобы пользователи и разработчики могли обсуждать проекты и их проблемы. При этом важно понимать, что конечный пользователь не всегда может объективно оценить масштаб проблемы. Иногда то, что кажется критическим багом, на самом деле может быть простым недоразумением или ошибкой в установке. Именно поэтому открытое обсуждение помогает всем участникам проекта оценить реальную важность проблемы и решить её в кратчайшие сроки. | ||
|
||
## Как задавать вопросы на GitHub | ||
|
||
1. Будьте конкретны: Опишите шаги, которые привели к ошибке. | ||
2. Предоставьте контекст: Укажите, с какой системой работаете, какие версии используете. | ||
3. Прикладывайте логи: Это значительно ускоряет диагностику и решение проблемы. | ||
|
||
Вместо того чтобы писать личные сообщения, создайте issue с детальным описанием проблемы. Это не только ускорит решение, но и поможет вам избежать лишнего ожидания и неопределенности. | ||
|
||
## Вклад в проект | ||
|
||
Не забывайте, что каждый вопрос или сообщение в публичных каналах, будь то обсуждение на GitHub или в чате, — это вклад в развитие проекта. Это ценится намного больше, чем просто общение в личных сообщениях. Публичные каналы помогают создать сообщество, где знания и идеи обменяются быстрее, чем если бы они оставались в личных переписках. | ||
|
||
## Ресурсы | ||
|
||
- [GitHub Issues](https://github.com/ReHLDS/ReHLDS/issues) | ||
- [GitHub Discussions](https://github.com/orgs/rehlds/discussions) | ||
- [Discord Community](https://rehlds.dev/to/discord) | ||
- [GitHub Boards](https://github.com/orgs/ReHLDS/projects) | ||
|
||
Создавая issue, pull request или даже просто участвуя в обсуждениях — вы уже делаете важный вклад в развитие проекта. Все обсуждения, баги и предложения помогают не только вам, но и другим участникам сообщества, улучшая проект для всех. |