How we prioritize issues

[Frooxius]

Hello everyone!

We've had a number of questions on how we prioritize issues (features, tweaks and bugfixes) from you. To give you a good understanding and provide better transparency on this, we put together a "How we prioritize" document, which goes over the factors that go into prioritizing issues. You can read it here: https://github.com/Yellow-Dog-Man/Resonite-Issues/blob/main/HOW_WE_PRIORITIZE.md

I'd strongly recommend going at least over the quick list, but if you can, read out more about each of the factors too, as they provide more details, context and examples. We hope this will help you better understand our development process.

If you'd like to ask questions or discuss this, feel free to do so here! The document and our process isn't fixed, but it evolves with time, as the needs and capabilities of the team and community change and as we learn and figure out better ways to go about this.

[AmasterAmaster]

Found a couple of typos in the "How We Prioritize" document:

• In the "Signals that we use to prioritize issues" section, in the bullet point of "Descriptive title", the word "changes" should be "chances".
• In the larger section of "Impact on the software, community and team", in subsection "Stability" near the end of the sentence, "dealth" should be "dealt".
• subsection "Costs" also has one, "areas" (plural) needs to be "area" (singular) with that sentence.
• In the section "Complexity of the work", where the sentence starts with "Conversely, issues that wake weeks, months or even...", "wake" needs to be "take".

[shiftyscales]

I've made the requested corrections, thanks. 8815901

[paradoxical-autumn]

Quick question: if someone requests a new feature and creates an open source plugin (not mod!) adding in said functionality, does that affect its priority?

Such as if they request a new protoflux node, script the functionality into a plugin and link the source code in their feature request.

[XDelta]

It may help increase peoples awareness or interest in the feature if they get a chance to try it out earlier. This applies to both plugins and mods. I'd recommend linking to the relevant issues from the repo and link to the plugin/mod from the issue. From the Existing community solutions section it sounds like it may help increase or lower priority since there would now be a 'solution' that can be pointed towards, it depends and would be case by case. Mostly already described here:
https://github.com/Yellow-Dog-Man/Resonite-Issues/blob/main/HOW_WE_PRIORITIZE.md#existing-community-solutions

[shiftyscales]

As Delta had pointed out above, "it depends" is the best answer we can give here, @paradoxical-autumn - the specific around which can be found in that section of our document on how we prioritize issues.

[Frooxius]

It might. It's not a guarantee. In some cases it helped.

E.g. we added native PDF support, because of a plugin/mod that implemented it and showed that the API for the library is simple enough.

We didn't actually use any code from the plugin/mod itself - we did a fresh implementation, in part because the plugin approaches it in a "hacky" way (which is understandable for plugins).

However it helped to clear an important question - what is the complexity of the library to get bitmap data from a PDF file. It was low enough that the implementation took just about a day or two.

Generally things will follow this kind of pattern - we're very unlikely to use code from any mods/plugins (even if they're open source), but they can help as "proof of concept". It'll be very situation specific though.

If you're unsure, you can always ask in the specific issue if that would help or not and we'll give best answer we can.