mirror of
https://github.com/microsoft/PowerToys
synced 2024-11-21 15:53:19 +00:00
4f3d7009a8
1. Clearer Section Headings: Renamed sections like "Indicating Interest in Issues" to improve readability. 2. Conciseness and Flow: Shortened sentences and rephrased for directness. 3. Improved Organization: Streamlined instructions in sections like “Filing an Issue” and “Contributing Fixes/Features.” 4. Reduced Redundancy: Simplified repetitive language, especially in localization and contribution details. 5. Enhanced Call to Action: Adjusted "Help Wanted" and "Becoming a Collaborator" to guide users clearly on next steps.
73 lines
4.3 KiB
Markdown
73 lines
4.3 KiB
Markdown
# PowerToys Contributor's Guide
|
||
|
||
Below is our guidance for reporting issues, proposing new features, and submitting contributions via Pull Requests (PRs). Our philosophy is to understand the problem and scenarios first, which is why we follow this pattern before work starts.
|
||
|
||
1. There is an issue.
|
||
2. There has been a conversation.
|
||
3. There is agreement on the problem, the fit for PowerToys, and the solution to the problem (implementation).
|
||
|
||
## Filing an Issue
|
||
|
||
**Importance of Filing an Issue First**
|
||
|
||
Please follow this rule to help eliminate wasted effort and frustration, and to ensure an efficient and effective use of everyone’s time:
|
||
|
||
> 👉 If you have a question, think you've discovered an issue, or would like to propose a new feature, please find/file an issue **BEFORE** starting work to fix/implement it.
|
||
|
||
When requesting new features or enhancements, providing additional evidence, data, tweets, blog posts, or research is extremely helpful. This information gives context to the scenario that may otherwise be lost.
|
||
|
||
* Unsure whether it’s an issue or feature request? File an issue.
|
||
* Have a question that isn't answered in the docs, videos, etc.? File an issue.
|
||
* Want to know if we’re planning a particular feature? File an issue.
|
||
* Got a great idea for a new utility or feature? File an issue/request/idea.
|
||
* Don’t understand how to do something? File an issue/Community Guidance Request.
|
||
* Found an existing issue that describes yours? Great! Upvote and add additional commentary, info, or repro steps.
|
||
|
||
A quick search before filing an issue could be helpful. It’s likely someone else has found the same problem, and they may even be working on or have already contributed a fix!
|
||
|
||
### Indicating Interest in Issues
|
||
|
||
To let the team know which issues are important, upvote by clicking the [+😊] button and the 👍 icon on the original issue post. Avoid comments like "+1" or "me too" as they clutter the discussion and make it harder to prioritize requests.
|
||
|
||
---
|
||
|
||
## Contributing Fixes/Features
|
||
|
||
Please comment on our ["Would you like to contribute to PowerToys?"](https://github.com/microsoft/PowerToys/issues/28769) thread to let us know you're interested in working on something before you start. This helps avoid multiple people unexpectedly working on the same thing and ensures everyone is clear on what should be done. It's less work for everyone to establish this up front.
|
||
|
||
### Localization Issues
|
||
|
||
For localization issues, please file an issue to notify our internal localization team, as community PRs for localization aren't accepted. Localization is handled exclusively by the internal Microsoft team.
|
||
|
||
### To Spec or Not to Spec
|
||
|
||
A key point is for everyone to understand the approach that will be taken. We want to be sure that any work done will be accepted. Larger-scope items will require a spec to outline the approach and allow for discussion. Specs help collaborators consider different solutions, describe feature behavior, and plan for errors. Achieving agreement in a spec before writing code often results in simpler code and less wasted effort.
|
||
|
||
Once a team member has agreed with your approach, proceed to the "Development" section below. Team members are happy to help review specs and guide them to completion.
|
||
|
||
### Help Wanted
|
||
|
||
Once the team has approved an issue/spec approach, development can proceed. If no developers are immediately available, the spec may be parked and labeled "Help Wanted," ready for a developer to get started. For development opportunities, visit [Issues labeled Help Wanted](https://github.com/microsoft/PowerToys/labels/Help%20Wanted).
|
||
|
||
---
|
||
|
||
## Development
|
||
|
||
Follow the [development guidelines](https://github.com/microsoft/PowerToys/blob/main/doc/devdocs/readme.md).
|
||
|
||
### Naming Features and Functionality
|
||
|
||
Names should be descriptive and straightforward, clearly reflecting functionality and usefulness.
|
||
|
||
### Becoming a Collaborator on the PowerToys Team
|
||
|
||
Be an active community member! Make helpful contributions by filing bugs, offering suggestions, developing fixes and features, conducting code reviews, and updating documentation.
|
||
|
||
When the time comes, Microsoft will reach out to you about becoming a formal team member. Just make sure they have a way to contact you. 😊
|
||
|
||
---
|
||
|
||
## Thank You
|
||
|
||
Thank you in advance for your contribution! We appreciate your help in making PowerToys a better tool for everyone.
|