The XY Problem Guideline Removal Proposal (Should it be removed?)

[AmasterAmaster]

--- Preface ---
First things first: This is a discussion, a proposal if you will, about removing the XY Problem rule from the submission process of Yellow Dog Man Studios GitHub (or at least making it more clear and understandable as the alternative). I want this to be civil, respectable, and well thought out. I want a proper discussion that talks about if there should be this rule in the first place. Be respectful to everyone here, especially to the dev team as they try their best with development and policies, there should be no hate. Consider both sides of the arguments presented, it does not need to be a full on debate, as we are all learning through the process (no matter in what capacity). Everything here in this post is my opinion, my research into the matter, and what I think possible solutions are, and no one has to agree with anything I say here (I realize this is a hot take). With all that being said, here is my proposal:

--- The cons to having the XY Problem Rule ---
When I first learned how to make issues on GitHub here, as well as thinking in the mindset of a new user that ran into an issue for the first time, the issues I personally wrote up were not written or expressed the best, and everyone starts out somewhere, however I found a couple of roadblocks/pain points that makes it feel bad to even go through the process of writing up an issue. This effects more of the non-developers, non-creatives, and users that just want to be social on the platform. I will start with the opposing arguments first:

• Having to keep in mind of the XY problem, writing up issues are generally harder to convey across the idea without sounding like it is a generic issue. An example of this is when a user writes up something about an issue in Resonite, it is too tempting of a new user to state that "hey, I would like to have this feature for a thing I am making", then later feel bad when they get told that "oh, that sounds like an XY Problem". This gets doubly bad when there is no clear or obvious solution, or no path at all to make it work, such as no existing component that can make that idea come true for that user. For specifics, text cursor control in text fields, no component or flux exist, yet gets treated as an XY Problem when there is no clear or available solution.
• Basic suggestions get thrown out, when all ideas should be cherished and appreciated. I heard from several places (inside and outside of Resonite) of different opinions to this. Some claim that the devs don't want to work on it because it is not of their interest or they don't care, some will claim that they are too busy and are working on other features at the moment. Both are valid statements, yet in the context of the XY Problem only, it just feels bad to hear that an issue gets declined (or worse, ignored) because of the combination of the two ideas. Assuming is wrong, but no transparency is just as bad.
• Asking for features should not be an XY Problem issue. This comes up from time to time, and usually the community does a good job at correcting individuals with proper information, like alternative suggestions of using a component rather than 10+ flux nodes to do the thing they want to do. However, sometimes suggestions are a good thing to have, as all ideas should be treated with respect. Like a better design for the variable flux node that can display a value that is stored inside it. Instead of just saying to use a display node, that idea should be considered before throwing it out completely (by stating that a display node already exists, it is as if the point was ignored in favor of showing off that it is an XY Problem and that it "should" stay as it is). Maybe better explanations or awareness could help with this problem, but I am unsure how that could be expressed.

--- The benefits to having the XY Problem Rule ---
Don't get me wrong, I think it is wonderful to have the XY Problem rule, and it does serve well for developers and creatives (but not everyone knows it exist until they are exposed to the idea of it). Here is the pros to keeping it on the requirements on the page:

• It is great when you know exactly what you want to ask for (either as fixes or feature requests). As a developer would know that a problem could be broken down into multiple steps, and solve each problem one part at a time. A user that has never developed or created something before might not know what the exact wording, terminology, or phrases are used in a given platform (who could blame them, they are new to the whole system, especially to the idea of the XY Problem if they never heard of the concept before). For the most part, when you know specifics, this works amazingly well.
• When a feature is supported or already exist, this works extremely well. As the community and the dev team can use what already exists as a reference point. Having an item or object that can do exactly what a person is asking for is loads better than having that same user never see it before and writing up an issue/feature request for something like that item or object. Knowledge is power here and guiding users to places (like to the wiki or GitHub) to learn that things exist already is what makes this rule very helpful.
• It is standard practice to ask follow up questions when there is miscommunication, or at least a misunderstanding of the goals a user would want to achieve. This rule helps with getting to the bottom of things and there is nothing wrong with that (but it is the execution of using the XY Problem that can be up for interpretation when a user gets confused on a situation, that should be looked into, maybe have better questions to ask?)

--- Resolutions to the proposed problem ---
As with any pain point for users, nothing is perfect, but a discussion about this could help. All, Any, or None of these solutions could be implemented to help ease and educate users on what is and is not the XY Problem, or maybe there is no need for it and a better process to determine solvable solutions to the issues could be created. I have a couple of resolutions that I can state here that may ease users, or to encourage users, to submit issues using the GitHub platform:

• Complete removal of the XY Problem rule. The benefits to this will allow for more creativity and flow of ideas for Yellow Dog Man Studios to use, implement and creatively support in their own free will. The bad part of this change may increase the number of submissions to this platform with a more deviating range of quality in reports. However, more ideas and suggestions could boost the idea pool that the devs can utilize from.
• A complete rewrite and explanation of the XY Problem: This is the next best option if removal cannot be done. I would like to see a crystal clear explanation in the rules stating what is and is not the XY Problem. One of the pain points that many users face when making issues is being told constantly that "this is an XY Problem", and then pasting it into the issue from the reporting requirements page. Better explanations, or having a clear statement of what it is may help with this.
• A clear list or obvious and understandable example list, at least enough items in the list to let the user know what is and is not an XY Problem. An example could be something like this:
  • X: Don't say - I want to make a cheese burger. --> Y: Say - I want to be able to put a cheese on a patty when making my burger.
  • X: Don't say - I want to make a string parser for my incoming network string. --> Y: Say - I want to extract escape characters from my string.
  • X: Don't say - I want a node that can do this and that. --> Y: Say - I have a problem, and adding a node or component would help as a feature.
• No Change: This is undesirable as nothing would change and new users will keep hitting the same pain points over and over again. However, I will not judge the actions that may or may not happen, as it is the devs that have the final say on what is in accordance to their policies.
• X should just be answered, especially if it is obvious. Doing this would just save time in the long run.

--- Conclusion ---
I feel this should be discussed and possibly find a solution that is easier for new and old users looking to submit bugs and features, as well as to properly write them up with the best quality possible for the dev team to understand it well enough. My take on this may not be garnered well with the community on this one as I don't feel the XY Problem excuse is adequate enough to express (or even to teach users) on what even the XY Problem is. I don't want this XY Problem to be itself an XY Problem, so there has to be a solution for this, unless there is nothing that can be done, which means that users will continue to encounter this meta-issue. And if users feel bad about writing issues or requests, they are less likely to write one up to help Resonite as a whole.

--- References to issues that should not have been treated as XY Problems ---
These are examples, not the rule. This showcases when and what happened, and should only be for further reading on this.

• A way to load a world with all protoflux disabled #2008 - Safe mode for Resonite should be a feature request, but got marked as an XY Problem.
• A mechanism to quickly check the stored Value/Object/Reference of a DataModelStore node #2627 - A suggestion as a feature request provided as an idea, but marked as an XY Problem.
• Make a component that can sequence key presses for the user #1778 - A feature request that got misunderstood and also not having a solution available within Resonite, making it being marked as an XY Problem.

--- Other References ---

• https://en.wikipedia.org/wiki/XY_problem
• https://meta.stackexchange.com/questions/346503/what-is-the-opposite-of-the-xy-problem
• https://xyproblem.info/
• https://wiki.resonite.com/XY_Problem

[AmasterAmaster]

I am also documenting this concept to help as another possible solution to help guide users to understand this problem in a deeper way. Maybe a wiki page would help this? If you have any information about the XY Problem, or any stories to why this problem came to be and why it is used, I would love sources and articles talking about this. It will help with documenting this and enlighten other users to why this is a concept. Thank you in advance.

[XDelta]

https://xyproblem.info/ is another reference

This one poses it as Y is the thing that gets asked instead of asking about X.
Hence stuff like 'asking whY' or 'whY are you asking that' would come up as a response to an otherwise odd inquiry

[AmasterAmaster]

Should I edit my post to include it or leave this here as a comment?

[XDelta]

Doesn't hurt to add the reference in the main post as well

[charlie-sans]

I think we should ban or at least remake the xy rule, it sounds like a whole load of bs that no one needs and harms idea creation.

but the thing is, the XY problem actualy fixes the issue. if Y is the issue, then X must be a fix for something. regardless if the issue is actually trying to point the correct direction.
if X is not a good option, then think of a different way to implement it.

i'm not trying to hate on anyone but this " i think this is the case of the XY issue." doesn't seem to make any sense.

say i'm a new user right? i'm working on something and i think of a great feature that will help everyone.
so i go make a github issue about it and be like " hey i was making and i was wondering if we could have " then someone says yeah that's a really good idea and gives it a thumbs up.
some od 5 thumbs up and you get told "i think this is the case of the XY issue.", i think harms the chance the user will want to make more feature requests.
now, i've seen some times where issues have been left untouched for months and a new user comes along and makes a new issue, say's the same thing but layed out differently and then gets hit with XY problem.
i don't think the XY problem being a thing is good. how about it's more like,
" i know what your getting at, this might be the case of XY but let's brainstorm how this could help people when making things".

i'm not trying to be rude here but the XY problem plagues people and i know people who just straight up refuse to make more feature requests because their afraid that they might get hit with it again.

i hope what i know can help anyone who reads this.
i only have good intentions with the things i do.

[charlie-sans]

with that, more idea's can be made and can help to the conversation if what they are talking about is relavant.

[ProbablePrime]

I found your comments hard to read Charlie.

When applying the XY guidance its important to not focus on X or Y or you end up speaking in Algebra.

From my reading of your commentary, it is likely that it is not being applied correctly in some cases though.

[XDelta]

Atleast in 2 of those issues linked, it looks like attempts were being made to ask for more details or what problem they were trying to solve in before/while mentioning it looks like an xy problem.

[AmasterAmaster]

I wonder if those 2 instances could have been less jarring when it was mentioned, but of course "beating around the bush" is not a good solution either. And maybe I can return to my write up and update it to be more clear. I don't know, many things could be improved in that regard.

[lxw404]

The XY "problem" is more of a nudge to recognize an extremely common engineering fallacy.

I've been prone to this fallacy myself and it just wastes time and leads to poor communication. From a new user perspective, there certainly can be less friction when this is pointed out by possibly modifying some of the wording in the guide or improving the understanding of how to write good issues, however the guidance should NOT be removed in any capacity as it will inevitably lead to poor tracking of real issues and not fully thought out user-provided solutions. It further confuses the development team and can lead them in wrong directions, wasting their precious time.

A solution-first approach to a problem that is happening is the almost always the wrong approach if you're not intimately involved with the complexities and design of the entire system revolving around that issue. What is recommended in the github requirements for issues in this repository is that you focus on the high-level issue first which is a generally good way to approach thinking about any problem.

Instead of assuming that falling into this fallacy means that your issue is completely invalid, a user should recognize and be assured that it is just a means of clarifying and reaching a true issue not yet fully articulated. A solution that is not aligned with the development team's current goals should also not be a stopping point for discussion around how to resolve a problem that is occurring.

[ProbablePrime]

This isn't a rule, it's guidance that is attributed to the requirement "Focus on the high-level issue first, not a specific solution"

The problem we have a lot of times is that the problem is left behind and solutions become the subject of the conversation. This guidance is meant to remind us all to remember to "Focus on the high-level issue first, not a specific solution".

While this topic is healthy and discussion is welcome, the inclusion of the word "rule" is misleading. It has never been a hard rule.

[AmasterAmaster]

Ah, my bad then. It always felt like a rule in the way it was used, but never considered to it just being a guiding tool for it. Good to know.

[shiftyscales]

In effect, everything we specify in our reporting requirements, and similar documentation are tools intended to help users to better work with us to ensure that issues are well and thoroughly communicated so that we may effectively resolve the user's issue / request.

Specific to enhancement / feature request issues- this is why we have sections that first and foremost- ask if the feature request is related to a problem they are experiencing, as well as having a separate section for their desired solution afterward.

Keeping issue titles more generic / focused on the underlying issue also makes it easier to read what an issue is at a glance / why something is being requested.

The end goal is just ensuring that all parties understand each other as clearly and concisely as possible so that the underlying issues / requests are well-understood and can be resolved. :)

---

With regards to the XY problem portion of this discussion- did you have any specific misunderstandings of it you would wish to highlight? You had mentioned the addition of examples to our reporting requirements- but the linked resource https://xyproblem.info/ already contains examples of what is meant by this, and is already being included in responses indicating it to users (for the examples of issues you had linked), as well as being a part of our reporting requirements: https://github.com/Yellow-Dog-Man/Resonite-Issues#reporting-requirements

[AmasterAmaster]

I appreciate the explanations to this, as I am still trying to understand it just in general (hence this discussion), and I wondered how people felt about it in general as well. I even made a wiki page about the abstract concept so other users that don't know why they are being told that it is an XY Problem can understand on why it is a thing in the first place. Because I know when I was first told that when I did my first few submissions, I originally did not think it would apply to me before posting and my emotions were all over the place that day (I don't experience those emotions any more, but other users might when they first do submissions, and I want to avoid any bad experiences for users that may have the same notion of thought).

The link resource (https://xyproblem.info/) was recommended to be added to the original post, and it would help bring the bigger picture together of what it is for this discussion. Maybe using the Wikipeidia link would have been a better substitute to the reporting requirements section?

But besides that, most of my concerns are listed in the main posting. If I do have a more specific concern, what would be the best way to contact you for further inquiry @shiftyscales?

[shiftyscales]

Discussion pages like these are fine, otherwise, you could create an issue, or pull request with requested changes / feedback to the file. I read everything that is submitted to this repo (comments, issues, discussions, pull requests, etc.)

[Dusty-Sprinkles]

Maybe a better way to address potential XY problems could be rather than opening with "this seems like an XY problem" working to find the solution that fits best and if it does wind up being an XY problem, noting that afterwards?

Most of the issues where I've seen it come up it can kind of feel like the person making the issue is being "punished" for failing to identify what they need initially.

I don't think it should be "gotten rid of" or anything like that though, because its good to have guidelines for clarity and at the core of it thats really all it is

[AmasterAmaster]

I agree, as being "punished" for trying to help should not happen. It would definitely save new users from that friction of worry or nervousness if it was worded a bit better.

[TheNovaBeast]

I don't know much or I can't say much, but a lot of things are heavy bias. I hated it the most when a request got linked to another request with a horrible write up and hardly any information and was told it was suitable... (then someone else who had the same issue as another got instantly approved, even with the same arguments as me or someone else, where does that make logical sense, oh yeah because they are well known and get rite of passage apparently) ((Some other things also are linked to similar experiences not just the one I addressed) as a new user it seems very unprofessional.

Even when people put effort into something completely different, they get crossed with something else that doesn't even tangle with the user request and gets shrugged off.

There needs to be better standards for the entire interactions of this GitHub not just the XY problem. Those are my thoughts as a new user.

Thanks for reading.

(Sorry for not providing any examples but as a whole it shows my disinterest in using the Git with its current status)

[Frooxius]

We do have pretty extensive write-up. There's a lot more to this than XY problem, on how issues are prioritized: https://github.com/Yellow-Dog-Man/Resonite-Issues/blob/main/HOW_WE_PRIORITIZE.md

I don't quite understand what exactly you're referencing. If you can provide examples, we can look into those, but without examples, it's hard to say anything.

I can tell you there's no "rite of passage". User being well known doesn't generally factor into prioritization of issues.

[Frooxius]

I'm going to say upfront - we will not remove this guideline. It's a very important one and following it makes our (engineering) work much easier to do.

What is important to understand here is - we get A LOT of issues and requests and our time is very limited. We are always looking for ways to implement things that will help the most people with least amount of engineering work and for that, it's important to understand the underlying issues behind people's requests - it lets us, the engineers, to come up with best solutions to solve those problems.

When people ask for a very specific solution, you effectively remove that ability from us (or at least, make it much more difficult to do), which hurts both us and hurts other users - if we need to spend a lot more time trying to figure out your issue, that time is taken away from working on other issues from other users.

---

With that said, we could definitely focus on improving the wording, guidance and explanations on why this is being done.

From our perspective, what we really need users is to be "This is the end goal of what I'm trying to achieve" first, without focusing on "How" and through which means, rather than "I want feature that does XYZ specifically".

When you work on an issue, it's almost like you "zoom in" on the way you want to solve it. And when you make a request about that "zoomed in" feature, that makes the work harder for us. What we need users to do is "zoom out" and give us the big picture of what they've been trying to do, so we can look if there's better approaches and solutions.

The difference between the two from our perspective is huge.

[AmasterAmaster]

I respect the decision, and I would love the guidelines to be clearer for users, that would help so many people. And I do have a question for already existing opened GitHub tickets: Would it be beneficial to you all as the dev team, if we reworded and clarified the issues to make it more "zoomed out"? I am unsure if that also relates to the "Needs more information" tag as well with the XY Problem, but I would like your thoughts and opinions about it.

[shiftyscales]

"Needs more information" as a tag is just applied anytime we request / require more information on the issue to resolve / better understand it. E.g. if a bug issue were missing log files / a replication object / etc. that makes it easy for us to replicate the issue- it'd need more information.

Likewise, if we have any specific clarifying questions of the issue poster it can be applicable there too.

As mentioned elsewhere in other replies in this discussion already- our underlying goal is to be able to have users submit their issues in a way such that both sides adequately understand the issue / what is trying to be solved.

In the case of a bug- that is the questions of- what is the issue? What is the user's expected behaviour in the scenario they've presented? Everything else- log files, replication objects, screenshots, video, a clear and concise but descriptive title, etc. are all requested to make it easier for us to be able to look at an issue and understand it as quickly as we are able.

In this scenario, specificity can help. Simplifying the replication steps, and replication object as far down as possible to minimize variables.

With enhancements / feature requests- the main question is- what problem is this feature trying to solve / make easier? So keeping things 'zoomed out' is a good idea to focus on the overall goal of the request / what is trying to be achieved. The user can then also discuss possible approaches / paths they could see to having their issue resolved, but that goal is secondary to establishing what it is that they need.

[Frooxius]

Basic suggestions get thrown out, when all ideas should be cherished and appreciated.

Just focusing on this part - we appreciate all the ideas and suggestions, they still give us some information on what people want.

However the important part to understand here is - that doesn't mean we can/will work on all of them. That's simply unrealistic. Issues will have to be closed and some things we just cannot do and there some things we won't do, because we have to ensure the codebase and engine will remain maintainable and we don't code ourselves into some corners that will be hard to get out of.

It sucks, but there's only so much we can do.

But that's also why XY guideline (as well as others) are important - the easier you, the community, make the work for us, the more efficiently we can get through the issues and implement more of them.

If we remove the guideline, you will effectively make the opposite happen - we will have to ignore and skip a lot more issues, because each one will take more of our time than it otherwise would have.

[AmasterAmaster]

Yea, that makes sense. And also why I mentioned both sides of the argument that yes, you would be flooded with so many requests (as the counterargument being you get more creative ideas). You can correct me if I am wrong, but this current implementation of the guidelines is a fine middle ground where users can submit anything and you pick and choose what is relevant? I can see how that is working well so far at least.

[Frooxius]

To give you an example of XY problem and why it's important in a more demonstrative example.

Imagine you have a chair. The chair is rickety, because one of the legs is shorter than others. So you try to solve it, by putting a book under the leg that's the perfect length. But you can't find ones that are perfect length for it, so you figure that if you counter-balance it on other sides with other books, you can make the chair perfectly level.

So you go and create a request saying "Implement book searching algorithm that finds 4 sets of books whose page lengths sum up to the same number with ability to offset each set by a given value."

When we look at that issue we'll be like "That's... really weird and very complicated to implement. Why would anybody want to do that?!".

We might not commit any resources towards implementing that kind of feature, because we don't understand its usecase, it's complex in implementation time and it seems very niche - like it wouldn't help other stuff. This makes the user frustrated, because their problem - rickety chair, is not resolved.

What we really need the user to do in that case - and what XY problem is really about, is to "zoom out". Focus on what is the initial problem that led you to that request.

If instead of that particular issue you made issue that says "My chair is rickety", we'll just be like "Oh that's super quick fix, we'll just replace the chair leg, 5 minutes and done."

Just by changing that, you made the issue go from "hours worth of figuring stuff out and weeks worth of engineering for a confusing and niche feature" to "5 minute quick solution" - that's potentially hours (and weeks if we decided to implement it) saved, your issue resolved and we can do a bunch of other issues in that time!

We actually get a fair bit of requests that are pretty much like this - which is why we want people to think about the XY problem when making issues.

[AmasterAmaster]

That is an excellent explanation to it, and it makes it more clear. And I am surprised that more users don't know that it exists. Even if they do read up on it, it still happens (I am guessing the temptation is too great to want a solution to a weird problem)... How can a user do better when doing ticket write ups? But I guess I am asking the million-dollar question there. And I can guess that spreading awareness of the XY Problem could alleviate that. But thank you for the enlightenment on this.

[TheNovaBeast]

That is an excellent explanation to it, and it makes it more clear. And I am surprised that more users don't know that it exists. Even if they do read up on it, it still happens (I am guessing the temptation is too great to want a solution to a weird problem)... How can a user do better when doing ticket write ups? But I guess I am asking the million-dollar question there. And I can guess that spreading awareness of the XY Problem could alleviate that. But thank you for the enlightenment on this.

#2628 (comment)

Still need this to be noticed Somewhat.

[shiftyscales]

I've already read through that, @TheNovaBeast - but without examples provided, there's not much I can speak on as to why decisions would have been made the way they do- it's possible mistakes were made- but I couldn't say without seeing what you are referring to in specific.

I always do my best to assess / triage issues objectively and fairly, and details such as who wrote the issue have no bearing on that process. There have been occasions where I make a mistake and misunderstood the intent / purpose for which someone was requesting something- but where possible we try to work through that to better understand what the issue is, and how it can be resolved.

[Psychpsyo]

Isn't the XY-problem just "State your problem instead of requesting a thing that would fix it"?

[AmasterAmaster]

If it were worded like that (and only that), then maybe the confusion would not be so great to warrant this conversation XD Yet users still get confused even today with this.

[ProbablePrime]

This has been bouncing around in my head all afternoon for some reason.

I think we can resolve this with some wording tweaks then.

I will update the Readme with a PR and link it here.

But additionally, if all folks responding to issues could just replace, "This sounds like the XY Problem" with "Could you elaborate more on the problem you are trying to solve as right now it sounds like you're talking more about a solution" or equivalent.

With both we should be solved.

[ProbablePrime]

#2718

[ProbablePrime]

Merged this, hope it helps!