On Encouraging more user involvement and information in issues up front

[rocky]

I've been doing open source work decades. In the early days there was definitely more of a spirit of when something doesn't work, try to fix it or do a work up front to isolate and narrow the problem and get as far as you can to fix a problem.

Nowadays, not so much.

When I see a Mathics issue, the first thing that comes to mind is the immediate impact of adding the feature, and who is asking for this. Usually neither is stated and it would help me out if I understood this before spending the time to read the issue.

If there is an easy workaround like writing code in Mathics for Diagonal or implementing some Sparse Matrix function, unless this of interest to you, the let's encourage writing it in Mathics or WL and move on.

For myself, there are so many fundamental other problems that no one else is likely to address, that I it doesn't make sense for me to be interested in the fact that Diagonal doesn't work. Whenever it happens that I need Diagonal for something I am interested in, or someone makes a case that is is important to the project at that point, I can then try to write it Mathics/WL. And then if performance is of interest, I can take that and revise it.

But if others feel this way even to a lesser extent, I think it might be good to set up guidance when opening issues to suggest what's up and what to expect. (The default alternative which is to ignore the issue, I don't think is as good.)

In on opening an issue we might as people to include (as appropriate):

• Is this a problem for which there is a workaround, such as writing some Mathics/WL code?
• What is the impact of this bug? For example:
  • I noticed it so I am reporting it
  • I need it for something I am doing, here you list what you are doing and what level of activity e.g - this hobby, homework assignment, research, work
  • If it blocks something important, then a description of why it is important, e.g like making a release of Package foo in Mathics
• If the bug reporter has special qualifications we should consider in assigning priority, that might sway me. e.g. I am a Sympy maintainer, or I wrote some WL package that is important, or I am trying to get Amazon interested in using the package.

See https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/configuring-issue-templates-for-your-repository for how create an issue template.

[rocky]

See also #246