Replies: 2 comments
-
|
Thank you for the suggestion. I will treat adopting a CoC as a high priority. I also think this situation clearly exposed the absence of one. Until now, I had expected participants to engage with the project in good faith and with a basic level of restraint, but that expectation alone was evidently not enough. That said, regarding the following point:
I want to clarify that this was not the reason for the block. Even low-context reports were answered as consistently and as structurally as possible. The actual problem was not volume alone, but the repeated continuation of the same pattern despite prior explanations about scope, expectations, and submission quality. The zoom/pan case was a particularly clear instance of this pattern. It had already been explained as outside the responsibility of the base Image control, and it had also been communicated that it would only be addressed in the form of a customizable, non-maintained example #109. Even so, the same customization point was raised again afterward in the form of a short issue. Along with adopting a CoC, I will also review the labeling and triage suggestions you mentioned. |
Beta Was this translation helpful? Give feedback.
-
|
Captured in #130, so close this now. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
@al6uiz I hope you can use this as a chance to reconsider both the product roadmap for MewUI and the project’s issue triage process.
It is good that the README clearly describes MewUI as an experimental prototype. That helps set expectations for users and contributors from the start.
You may also want to publish a Code of Conduct:
https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/adding-a-code-of-conduct-to-your-project
It would also help to make better use of issue Types and Labels for triage.
For example, issues that you want to address sooner could be marked with labels such as
priority:high. Issues that are lower priority, can be solved with app-level customization, or are not urgent for the framework itself could be marked with labels likepriority:low,workaround-available, orhelp-wanted. Many projects use this kind of structure so contributors and users can better understand what is likely to be worked on soon and what may take longer.Blocking a user simply because many open issues were created by them does not reflect well on the project. If they are actively using MewUI in real apps, it is natural that they will raise issues according to their own needs and priorities.
Beta Was this translation helpful? Give feedback.
All reactions