- "Problem"
- "Does not work"
- "Broken"
- "Failure"
- "Mistake"
- "Bug"
- "Does not work"
- "Breaking"
- "I can't line up"
- "Failed to install"
- "Does not work"
- "Help"
- "Doesn't compile"
- "Mistake"
- "Doesn't connect"
- "Problem"
Excellent. Nothing special.
The vast majority of open source projects were born in the same way. Desire to quickly solve a personal problem or learn something.
Why not post the code? This can be useful for other people, and it is convenient if the code is archived and indexed on GitHub.
The first lines of code have been written. This code is ugly, but it already partially solves the original problem. It's time to submit it to GitHub. This seems like a great achievement.
The bug tracker can quickly start filling up. “Thank you, this is exactly what I need” - it would be very nice to read this, but you will never see such a comment. Most likely,
"It doesn't work."
Obviously, the project DOES "work". You've been using it daily for a couple of days now, and it does exactly what you need it to do.
The reporter may not have been able to install it, customize it the way they wanted, or use it to solve a problem other than yours.
They are actually asking for free support services. In real life, asking for help directly seems natural. It can even start with “hello” and end with “thank you”.
We do not ask for help on the issue tracker GitHub. We complain about what we tried to do but “didn't work”.
Of course, this is a problem tracker. This is a place to complain rather than leave positive reviews.
However, the psychological impact this can have is often overlooked.
Each new completed question is akin to a new item on the project developer's to-do list. This has to be dealt with somehow. Reading and trying to understand it, and answering it to solve the stranger's problem. This alone exerts some psychological pressure. Watching the list of open issues grow is stressful. It’s like an endless to-do list that you never asked for, and a solution to which will not improve your own problems.
The vast majority of these support calls are negatively worded. If the user was unable to install the software on their device, they will call it an error. If there is a syntax error in their config file, they will report that "a failure is occurring." Everything else is "problem", "not working" or "failing."
While this was certainly not the intention, this endless negativity has consequences. This makes developers gradually feel like crap. Their software is just a bunch of rubbish that can do nothing but fail.
As the number of projects you release as open source grows, so does the number of problems. Complaints come even about projects that you no longer use. Can these problems be ignored? Every time you publish a new project, you sign an implicit agreement with the "community" to support it for life. And support is not so much about fixing bugs as helping users solve problems that you never have, the root causes of which are often completely unrelated to your projects.
Reporting an actual bug that can be easily reproduced with a successful software installation already running and which also affects developers is highly welcomed. Unfortunately, this practically happens.
Adding categories and templates doesn't help. Testimonials that "It Doesn't Work" to address individual issues will eventually fall into categories in which you can expect actual bug reports. Thus, you still need to check what is behind each description “not working” in case the real bug report is hidden behind it.
Some of these “not working” problems hide anonymous employees of the company who open problems with accounts that have no activity on GitHub, in addition to opening support tickets and “feature requests”. With thumbs up votes from similar accounts appearing immediately after posting. "Does not work. We are waiting for a solution. " If this is not an application “does not work”, then this is the command: “Check the new release. This is blocking our processes. "
There is no "we". I am not part of your team and should not be doing the work you get paid for, whether you are using one of my projects or not.
There is a feeling that installing free software gives you the opportunity to receive free support from the maintainers. And to some extent this is so. Because it's hard to say “do your homework” and close the application. Every closed submission requires a rationale that will live forever in the history of the issue tracking system, and what people will look at, even years later. As such, you may have to keep solving user problems, even if they are completely unrelated to how you run the software yourself.
"Cannot install on Titan platform running BeOS for iPhone 4 (Chinese version 2.7 Pro)"
Some claims refer to equipment and tools that you may have never heard of. Or custom builds. Or configurations insanely more complex than any you've ever used.
“I don’t know” and “I don’t care” would be honest answers. The former is not a compelling reason to close the issue. The latter will backfire. So, you spend your time searching for this weird thing on Google, trying to figure out a user's problem based on pieces of a puzzle that you somehow manage to put together, and first find a reliable answer. All you really need is to solve this problem in the best possible way: by the users themselves.
Meanwhile, the stress increases. Each new application creates stress and anxiety. Not about the content, but about what needs to be done to close it. How much time and effort it takes.
Only with the hope that I will have time to really work on the project. Time spent helping people is not wasted writing code.
The accompanying projects know how to install and use the software. And for their use case, it works. If the documentation is incomplete, you need to remember that this very documentation was written as a gift to help other people. If a project doesn't work in an environment that developers don't use, they shouldn't be blamed for it.
Feedback is great. Knowing that a project is beneficial to others is great and encouraging. The ability to report bugs and make suggestions is very effective. But that's not what the GitHub issue tracker is mainly used for. It is used to make a complaint or ask for personal help, describing something that has been tried but failed as a "bug" or as a "problem" in software that is "broken", "crashes" and "does not work."
Support people have to deal with much more painful situations throughout the day. For this alone, they deserve great respect.
However, they have trainings. They know how to handle different types of clients. They can be passed on to other people. They have the relevant skills and experience.
The maintainers of the project do not have this. In addition, support staff support the company's products. They certainly share a corporate culture, but the complaints are about the company's work, not their own.
The application “does not work” in the personal tracker of project problems is what we undertake. There is no one to turn to for help in order to solve this problem in the best possible way, there is no manager or colleague to whom the case could be transferred. Ignoring it won't make it disappear. It will continue to appear every single day until it eventually closes.
Until that moment, the accumulating “does not work” requests make your work unnecessary and unpleasant.
The GitHub issue tracker has made me cry on more than one occasion. I could not sleep after I closed the applications for no good reason. Sometimes I still feel like saying "please leave me alone" as support requests keep coming in. And the "ping" messages sent on old problems, which I have postponed because it was not easy to decipher the real problem described.
On some projects, I eventually had to give up and close the issue tracker. But the “not working” problems continued and appeared in the form of comments on old commits, because they cannot be turned off.
However, the problems vary greatly from one project to the next. In a project intended to be used only by people already familiar with the subject area, “not working” problems are much less common. But instead of a free customer service center, an issue tracking system can become a free consulting service where people ask how to create an application or protocol when your software is being used in some way. It's hard not to help. It's hard to say no. So, spend your time solving other people's problems while you struggle with your own unrelated work? Only in this way will they decide the issue themselves. If you want to close it early, you need a justification. “Sorry, I don’t have time” is not a reason to leave the application open. Even if it's true and the bestwhat you can do for your own mental health.
Open communication is great and necessary. And the issue tracker is definitely a very valuable tool. But this is a many-to-few topology that fuels a constant stream of negativity (in its form) that can ultimately be destructive to the mind.
Mitigations
In about 24 months, after repeated nervous breakdowns due to problems with GitHub, I did several things that helped me a lot.
Probably the most important decision was to set a hard limit on the time spent on solving problems on a daily basis, trying to convince yourself that it is okay not to react immediately.
With github-auto-locker, closed tasks are automatically locked after a couple of months. If the question is closed, the case is closed. “Me too,” popping up on a topic that was talked about many years ago, is annoying. If there is anything new, open a new proposal, especially since the software may have changed a lot since the initial discussion and the context may be different.
After 30 days of inactivity, problems are closed with a timeout label. If there has been no activity for so long, it is unlikely that anything will change if the application is left open. It may have been a feature request that no one is interested in implementing. The compiler may have been asked to provide details, but he is not going to provide them. Maybe no one knows how to answer the question or what it means at all.
The timeout label does not mean that the problem will be ignored. A closed, unlabeled question may be worth taking a fresh look at later, when time permits. Many feature requests were closed in this state, but were eventually implemented later.
It helps a lot. This helps reduce the size of the to-do lists displayed every time you log in, while the same issues are re-displayed along with their age, reminding you that the clock is ticking. A shorter list with more recent issues is slightly less depressing.
Finally, I learned to say "no" or "I don't know." Sometimes harsh, just for the sake of closing the application, but it was necessary for my sanity.
- Russia's first serial control system for a dual-fuel engine with functional separation of controllers
- There are more lines of code in a modern car than ...
- Free Online Courses in Automotive, Aerospace, Robotics and Engineering (50+)
- McKinsey: rethinking electronics software and architecture in automotive
About ITELMA
List of useful publications on Habré