 |
| Fig 1. A priceless artefact from antiquity. |
Humans are a terrible bunch; Give them ancient, priceless artefacts to care for, and they'll snap the beards off them and stick them back together with pound shop (99c store) epoxy.
In August 2014, that literally happened.
Apparently, the museum has world class conservation equipment, and experts. So repair was carried out internally, at the museum.
Imagine that you were responsible for advertising for the job of "Repair Man for King Tut's Beard".
What would that advert look like ?
 |
| Fig 2. Required: Repair Man for King Tut's Beard |
Using just the features of blogger, I have conveyed everything important about the problem with a picture and a few words.
The words could have been almost anything "Help Required with Broken Things" would have done the job.
Asking for Help
Every one of us depends directly on code that was authored by somebody else. That may have always been the case to some degree, but in the modern ecosystem, we can directly contact the authors the majority of the time; We can open a bug on github, or some other bug tracking software.
Directly interacting with the authors of some code, so quickly, and with such little effort, feels pretty new to me; a product of our collaborative ecosystem.
Another, less obvious product, might be the programming language barriers that are erected by interactions between ecosystems that support, mutually or otherwise, other ecosystems; Such as the internals ecosystem which speaks in C, and the userland ecosystem which speaks in PHP.
Language barrier or not, we appear to make assumptions about the authors of some code, that we know are not true for code that we have authored ourselves.
This can lead us to omit almost everything important from our bug reports, or when asking for help ...
Our bug reports and questions can tend to have content that amounts to "Help Required with Broken Things".
The Ideal
If a bug is caused or effected by configuration or environment, then that's important information, however it is rarely enough to describe the configuration, environment, or even content of your code.
In the cases where only description is enough, it is obvious.
In cases where we think code is paramount, we are mostly aware.
What we are not always sure of, is how to include "our whole application" in a bug report, or question.
Stackoverflow has an excellent description of what reproducing code should look like, and even how to create it.
The Real World
We don't live in an ideal world, and we can't always create MCVE's.
I don't want to discourage anyone from reporting bugs or asking questions, at all.
So, open your issue, report your bug, ask your question, with whatever information you have.
But, you already know that it may not be actionable until it contains a MVCE.
A worthy observation is that in the course of trying to create an MVCE, you will, at the very least, find that you are able to describe the problem in more and more detail.
Trying can either lead to reproducing code, or the kind of detail that might make your query actionable.
Please try ...
