Dealing off the statistics data of the most read articles on my site I saw that this my 2014 article (in Italian) still has some success.
At the time I remember that I wrote that article because I had recently entered the open source world and began to make the first contributions and to work with free software in a virtuous way, or contributing.
Leveraging the site https://github-contributions.now.sh/ launched recently we can see my evolution. The number of commits per year has recently decreased probably from the work factor and from our private repo that can not be counted.
At the time I was hanging out also on KDE’s Bugzilla and on other projects that I was following so this need was born for me: if something does not work I open a ticket.
At the time it became a catchphrase for which people made fun of me but it was also the first step to make me understand more the open source. I still remember the anxiety of the first time I opened a ticket on Debian or replied to an existing one. If I wrote a bullshit other people would have made fun of or closing the ticket.
So over time I developed my technique in writing tickets so that it is difficult to answer rudely and even if my English sucks they do not take it.
For this I talk about Virtuosity, have a mastery of the instrument but also understand its importance. Some time ago I wrote another very read article that I have updated last year , about the reason for my activity in open source.
Following my personal philosophy, born from my Catholic experience, where everyone can make the difference and has the duty to make the best place for others, I realized I had addressed it in the Open Source world.
Simply if I find a project or a service if there is something wrong with the assistance that is a ticket or an email. Over time I have also written to GitHub or Appear to report problems or making suggestions to other projects that I find on the internet.
The advantage of making a report is that someone will think about what has been written so it is important to make the request “optimized” because probably someone will take charge (or perhaps ourselves) and we will have that thing that we absolutely need.
How to make a ticket
Do you want to open a ticket and want to be constructive? Do you want to help but do not have the time?
With these two questions it is easy to identify with those who will have to examine your request and then identify with them.
Who manages a project often has a lack of time so we need to provide as much as possible useful information and no complaints. Often providing some example or user case helps avoid superficial refusal and will force you to read the ticket to analyze it in detail.
So your vision of the problem or of the required functionality is very useful because it provides the context. Let’s say that they answer you after 2 months and ask for more details but you do not remember anything. Providing them immediately makes it easier for your request to be processed quickly because no exchange of information is required.
Instead, the style must be hearty. Nobody likes to read complaints, even if constructive, because often the problem could be a wrong use or something that has not been noticed. This approach is also useful with the assistance desk, which, being a friendly person, respond cordially and are more likely to help.
Often in cases of doubt, also close the message with something like:
- The first time I use the project and therefore I’m not sure
- I’m not sure I use it correctly
- Am I wrong or is it designed in that way?
These linguistic tricks bring you from a friendly point of view and that you want to know more about it and so answering is much simpler.
Honestly I have seen this approach work very well, in some cases of misunderstanding use the card even that my English is not the best or not being an expert has helped to decrease the tone and make the other participants more willing to explain and provide more information.
It also helps if you have to do many to not be unpleasant or asphyxiating so for work where speed and information collection are essential is better to play safe.
How to reply to a ticket
If the project is ours, how should we respond?
Simple following the same rules avoiding the “non-expert” part of course 🙂
Request more information, verify the request or even make references to the code in the response in the project (it helps to encourage others to make the change for you) demonstrate their professionalism and availability.
In any case, also documenting the closure of a request is important because the person took the time to do it and it is very bad to see it closed with an “It is not our priority”.
Moreover, a quick response is really appreciated because means that you are really interested in solving the issue.
Often I also make suggestions on how to apply the request for functionality or how to fix the bug in order to start a productive conversation and encourage the reader and the writer to do more and get excited about the project.
Also, let’s not have problems to take the blame in case of a problem because it shows honesty and allows to lower the level between maintainer and those who made the request.
The virtuosity of reporting
Let us think for a moment if you at all the complaints of every day or requests we receive constructive answers. Also, from the local authority, for example. How nice it would be!
We take the first step because it is difficult for an exhaustive request (not a complaint) and complete with examples and suggestions on how to apply it, to get negative answers or do not come to a compromise. Also in the daily environment.
From a personal point of view it also helps to think constructively and not be pissed off all day. It helps to be optimistic and be happy when the request is accepted and you can not wait to take advantage of it.
As in all things when something does not work you need to be felt only that there is a method that is constructive and willingness that in my experience has proved very useful to speed up and be sure of a resolution that interests us.
Obviously the method is not 100% foolproof, however, gives good security and makes the ecosystem more productive and easy/pleasant to live in (even if there is no time). In addition to creating useful documentation over time that can be useful for any things. I have often seen how my own articles or requests after time were current or unanswered and documenting them allows you not to get lost on Slack which is not good for that.