Skip to content

Latest commit

 

History

History
72 lines (45 loc) · 5.18 KB

CONTRIBUTING_feedback_and_requests.md

File metadata and controls

72 lines (45 loc) · 5.18 KB

Contributing ideas, feedback, and requests

The WinUI team greatly values public feedback. We combine this feedback with our own internal strategy goals, weighing it alongside our existing commitments, resources, and private partnerships, to deliver maximum value for you.

The guide below outlines how you can formulate this feedback for maximum effect and influence on WinUI's direction.

Phrasing constructively

When experiencing a pain-point, it can be natural to focus on the negatives and resolving things from the perspective of the negative. However, telling the team what you'd like to prevent is less helpful and actionable than telling the team what you'd like to achieve.

Your feedback is most effective when it is a constructive call to action on the team, and is clear and detailed – especially on the "why" so that we can make sure whatever it is that we arrive at together appropriately focuses on your goal and your intended outcome from start to finish.

Examples of constructively phrased feedback:

Instead of:

  • The state of the platform is disappointing. I am not going to consider WinUI until my trust has been earned.

Try this:

  • Deprecation of past frameworks has left me burned. The following would go a long way in earning my trust because my company is trying to launch an app next year and will need it supported for at least 5 more: 

    • OSS
    • High-confidence 5-year roadmap
    • Guaranteed support timeline

    This feedback provides clear actionable items that the WinUI team can take into consideration and address.

Sample areas where your feedback can have large impact

  • Features

    • It's very helpful to specify the "why" behind your request, even if it seems obvious. Comparisons can help, but shouldn't replace explanation.
    • Ex: "I need <feature> so that I can achieve <goal>. Otherwise, I have to <alternative>."

    There are also usually great opportunities to have feature-related impact in our spec repo. Here, you can give direct feedback and help shape the new features and APIs that we're currently building.

  • Future/Roadmap

    • We strive to be transparent about our product roadmap. Great examples of feedback to help us achieve this are:
      • "I'd like to know the roadmap through <timeframe>. Otherwise, I can't do <goal>. "
      • "The roadmap <certain aspect - e.g., changes too much, not detailed enough, etc.>prevents me from being able to do <goal>. If you would instead <proposed alternative>, that would result in <clear benefit>."
  • Ecosystem

    • It's helpful to be complete in explaining what another solution achieves for you and why it is important to you.
      • Ex:"I'd like WinUI 3 to work with <framework, language, library, technology, etc.>. Without this, I can't do <goal>."
  • Prioritization within WinUI

    • There is often trade-off required when adjusting priorities - please be clear in comparing what is more important vs. less important to you, and the reason why.
      • Ex: "I think <specific area or feature set> should be prioritized before <other specific area or feature set> so that I can achieve <goal>. Without this, I have to <alternative>. "
  • Engagement

    • Engagement includes feedback about learning materials and resources. It is always helpful to know where you prefer to be engaged and how you prefer to learn.
      • "I would like to hear more about <specific topic> in <resource> so that I can achieve <goal>."
      • "<Resource> could be more inclusive and accessible if you considered <alternative> because <benefit>. Have you considered making these changes?"

    Many of the resources we provide are also open source themselves! It can sometimes be more effective to leave feedback on the more specific repo. This includes:

  • Team Process

    • Team process includes feedback about our repo and overall communication. Suggestions for improvement and proposed alternatives are very helpful here.
      • Ex: "<specific aspect of team process - e.g., response frequency, format> of the repo is making it hard for me to achieve <goal>. Please consider doing <alternative> instead because that would help <action>"

Mutual respect

We strive to be respectful & empathetic toward each other, and we extend this to our fantastic community as well.

Our conduct guidelines help to ensure that discourse and feedback follows this same pattern of respect & empathy, and they also make it clear that non-constructive or hostile feedback is unacceptable. By following these guidelines, we can all enjoy the mutual respect that each WinUI team member, and each community member, deserve.

Refer to our conduct guidelines for more guidance here.