You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Features are often requested as a solution to a problem. Users are free to suggest solutions but we also need to take into account good API design, opportunity for extensibility, and general viability. Scripters don't always take this into account, and will sometimes delegate more work (in terms of logic) to MTA than is necessary.
To achieve all of the above, we should encourage users to tell us what problem they are trying to solve, and we can properly develop an API and solution that will not be pigeonholed into solving their specific problem, but solve similar problems as well.
We should also encourage feature proposals to be made before sending pull requests. This ensures that we have properly designed a feature and prevents contributor fatigue in both suggesting improvements and implementing those improvements.
Sometimes suggested solutions are excellent (e.g. #620, #784)! However, if we felt that this API was not suitable, it would be demotivating to ask the author to change everything. Thankfully in that pull request, this is not the case. Requiring feature proposals first will mitigate this issue.
Sometimes suggested solutions to problems have alternatives. In the example of #752, the core problem is "some models are only visible at certain times". The suggested solution is to be able to control what time a model is visible. An alternative solution is to make the model always visible (and let a script determine when the object should appear). It's difficult to discuss a change here when other implementations require further work.
Suggested solutions are good to get an idea of what scripters really want, but we should strike a balance between giving them what they want, and giving them the tools to achieve what they really want.
This discussion was converted from issue #887 on December 29, 2020 15:08.
Heading
Bold
Italic
Quote
Code
Link
Numbered list
Unordered list
Task list
Attach files
Mention
Reference
Menu
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Is your feature request related to a problem? Please describe.
Features are often requested as a solution to a problem. Users are free to suggest solutions but we also need to take into account good API design, opportunity for extensibility, and general viability. Scripters don't always take this into account, and will sometimes delegate more work (in terms of logic) to MTA than is necessary.
To achieve all of the above, we should encourage users to tell us what problem they are trying to solve, and we can properly develop an API and solution that will not be pigeonholed into solving their specific problem, but solve similar problems as well.
We should also encourage feature proposals to be made before sending pull requests. This ensures that we have properly designed a feature and prevents contributor fatigue in both suggesting improvements and implementing those improvements.
Sometimes suggested solutions are excellent (e.g. #620, #784)! However, if we felt that this API was not suitable, it would be demotivating to ask the author to change everything. Thankfully in that pull request, this is not the case. Requiring feature proposals first will mitigate this issue.
Sometimes suggested solutions to problems have alternatives. In the example of #752, the core problem is "some models are only visible at certain times". The suggested solution is to be able to control what time a model is visible. An alternative solution is to make the model always visible (and let a script determine when the object should appear). It's difficult to discuss a change here when other implementations require further work.
Suggested solutions are good to get an idea of what scripters really want, but we should strike a balance between giving them what they want, and giving them the tools to achieve what they really want.
Describe the solution you'd like
Additional context
The overarching aim here is to improve our open-source practices. Good resources for this are GitHub's Open Source Guides and some of Mike McQuaid's blog posts.
Beta Was this translation helpful? Give feedback.
All reactions