Adding Contributing.md and authoring help (microsoft#15807)

* Adding Contributing.md and authoring help

* Update .github/ISSUE_TEMPLATE/Manifest_Request.md

Co-authored-by: Levvie - she/her <11600822+ItzLevvie@users.noreply.github.com>

Co-authored-by: Levvie - she/her <11600822+ItzLevvie@users.noreply.github.com>

.github/ISSUE_TEMPLATE/Manifest_Request.md

@@ -11,9 +11,6 @@ assignees: ''
 🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨
 
 I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
-1. It might be easier to add the manifest myself.
-1. It is probably faster if I add the manifest myself.
-1. I have looked at the [Windows Package Manager Manifest Creator](https://github.com/microsoft/winget-create).
 
 1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
 1. If I list multiple apps in this one issue, the core team may close my issue without further explanation or engagement.
@@ -28,10 +25,15 @@ All good? Then proceed!
 
 # Package Requested
 
+- [ ] I would like someone else to build the manifest.
+- [ ] I would like help so I can submit the manifest.
+- [ ] I have performed a search and couldn't find this package.
+- [ ] I think there is a new version available and I have provided the URL.
+
 Manifest:
 
 
-Fill out as much of the manifest as you can:
+Fill out as much of the manifest metadata you can:
 
 
 ```YAML

AUTHORING_MANIFESTS.md

@@ -0,0 +1,33 @@
+# Authoring Manifests
+
+First, we want to say thank you. Your contribution is highly valued. And we appreciate the time you have taken to get here and read this document. Let's start out with a few definitions to help you understand our vocabulary.
+
+## Definitions
+
+### What is a manifest?
+
+Manifests are the YAML files in this repository containing the metadata used by the Windows Package Manager to install and upgrade software on Windows 10. There are hundreds of these files partitioned under the [manifests](/manifests) directory. We've had to partition the directory structure so you don't have to scroll as much in the GitHub.com site when you are looking for a manifest.
+
+### What is a package?
+
+Think of a package as an application or a program. We use a "PackageIdentifier" to represent a unique package. These are generally in the form of `Publisher.Package`. Sometimes you might see additional values separated by a second period. We will explain why a little bit later.
+
+### What is a version?
+
+Package versions are associated with a specific release. In some cases you will see a perfectly formed [semantic](https://semver.org) version number, and in other cases you might see something different. These may be date driven, or they might have other characters with some package specific meaning. The YAML key for a package version is "PackageVersion".
+
+## Understanding the directory structure
+
+Once you have determined the "PackageIdentifier" and the "PackageVersion" it is possible to know the proper location for the manifest. We will use Microsoft Windows Terminal version 1.6.10571.0 for our example.
+
+`manifests / m / Microsoft / WindowsTerminal / 1.6.10571.0`
+
+The partition directory is determined by taking the first letter from the "PackageIdentifier" in lower case. The next directory must match the first segment of the "PackageIdentifier" (case sensitive) up to the first period. This pattern continues until a directory has been created for each section of the "PackageIdentifier" (case sensitive) separated by a period. The last directory must match the "PackageVersion".
+
+## First steps
+
+Before you invest the time to generate and submit a manifest, you should check to see if the package already exists. Start out with `winget search package`. If that doesn't yield anything, try a quick search using the search box in the top left corner of GitHub for the package "In this repository". If you still don't find anything, finally check to see if there is already a [PR](https://github.com/microsoft/winget-pkgs/pulls) for the package by putting the package in the filters box, and be sure to remove the "is:pr is:open" filters.
+
+## What next?
+
+You should take a look at our [v1.0 manifest specification](https://github.com/microsoft/winget-cli/doc/ManifestSpecv1.0.md). Don't worry. If this is starting to look too complicated you can create a new Issue and select [Package Request/Submission 👀](https://github.com/microsoft/winget-pkgs/issues/new/choose).

CONTRIBUTING.md

@@ -0,0 +1,141 @@
+# Windows Package Manager Community Repository Contributor's Guide
+
+Below is our guidance for how to report issues, propose new features, and submit contributions via Pull Requests (PRs).
+
+## Open Development Workflow
+
+The Windows Package Manager team is VERY active in this GitHub Repository. In fact, we live in it all day long and carry out all our development in the open!
+
+When the team finds issues we file them in the repository. When we propose new ideas or think-up new features, we file new feature requests. When we work on fixes or features, we create branches and work on those improvements. And when PRs are reviewed, we review in public - including all the good, the bad, and the ugly parts.
+
+The point of doing all this work in public is to ensure that we are holding ourselves to a high degree of transparency, and so that the community sees that we apply the same processes and hold ourselves to the same quality-bar as we do to community-submitted issues and PRs. We also want to make sure that we expose our team culture and "tribal knowledge" that is inherent in any closely-knit team, which often contains considerable value to those new to the project who are trying to figure out "why the heck does this thing look/work like this???"
+
+### Repository Bot
+
+The team triages new issues several times a week. During triage, the team uses labels to categorize, manage, and drive the project workflow.
+
+We employ a bot to help us automate common processes within our workflow.
+
+We drive the bot by tagging issues with specific labels which cause the bot engine to close issues, merge branches, etc. This bot engine helps us keep the repository clean by automating the process of notifying appropriate parties if/when information/follow-up is needed, and closing stale issues/PRs after reminders have remained unanswered for several days.
+
+Therefore, if you do file issues, or create PRs, please keep an eye on your GitHub notifications. If you do not respond to requests for information, your issues/PRs may be closed automatically.
+
+---
+## Reporting Security Issues
+
+**Please do not report security vulnerabilities through public GitHub issues.** Instead, please report them to the Microsoft Security Response Center (MSRC). See [SECURITY.md](./SECURITY.md) for more information.
+
+## Before you start, file an issue
+
+Please follow this simple rule to help us eliminate any unnecessary wasted effort & frustration, and ensure an efficient and effective use of everyone's time - yours, ours, and other community members':
+
+> 👉 If you have a question, think you've discovered an issue, would like to propose a new feature, etc., then find/file an issue **BEFORE** starting work to fix/implement it.
+
+### Search existing issues first
+
+Before filing a new issue, search existing open and closed issues first: This project is moving fast! It is likely someone else has found the problem you're seeing, and someone may be working on or have already contributed a fix!
+
+If no existing item describes your issue/feature, great - please file a new issue:
+
+### File a new Issue
+
+* Don't know whether you're reporting an issue or requesting a feature? File an issue
+* Have a question that you don't see answered in docs, videos, etc.? File an issue
+* Want to know if we're planning on building a particular feature? Create a discussion
+* Got a great idea for a new feature? File an issue/request/idea
+* Don't understand how to do something? Create a discussion
+* Found an existing issue that describes yours? Great - upvote and add additional commentary / info / repro-steps / etc.
+
+When you hit "New Issue", select the type of issue closest to what you want to report/ask/request:
+
+### Complete the template
+
+**Complete the information requested in the issue template, providing as much information as possible**. The more information you provide, the more likely your issue/ask will be understood and implemented. Helpful information includes:
+
+  👉 Tip: Run the following command
+
+  `winget --info`
+
+* What tools and apps you're using (e.g. VS 2019, VSCode, etc.)
+* Don't assume we're experts in setting up YOUR environment and don't assume we are experts in `<your distro/tool of choice>`. Teach us to help you!
+* **We LOVE detailed reproduction steps!** What steps do we need to take to reproduce the issue? Assume we love to read reproduction steps. As much detail as you can stand is probably _barely_ enough detail for us!
+* Prefer error message text where possible or screenshots of errors if text cannot be captured.
+* We MUCH prefer text command-line script than screenshots of command-line script.
+* **If you intend to implement the fix/feature yourself then say so!** If you do not indicate otherwise we will assume that the issue is our to solve, or may label the issue as `Help-Wanted`.
+
+### DO NOT post "+1" comments
+
+> ⚠ DO NOT post "+1", "me too", or similar comments - they just add noise to an issue.
+
+If you don't have any additional info/context to add but would like to indicate that you're affected by the issue, upvote the original issue by clicking its [+😊] button and hitting 👍 (+1) icon. This way we can actually measure how impactful an issue is.
+
+---
+
+## Authoring manifests
+
+Authoring a manifest is not intended to be a painful experience. We have been working to make it easier. Sometimes this is to our own detriment. Please take the time to read our guidance on [authoring manifests](AUTHORING_MANIFESTS.md). This will save everyone time, and it will reduce the frustration of other Windows users who are just trying to get their job done, or have some fun.
+
+## Contributing fixes / features
+
+For those able & willing to help fix issues and/or implement features ...
+
+### To Spec or not to Spec
+
+Some issues/features may be quick and simple to describe and understand. For such scenarios, once a team member has agreed with your approach, skip ahead to the section headed "Fork, Branch, and Create your PR", below.
+
+Small issues that do not require a spec will be labelled Issue-Bug or Issue-Task.
+
+However, some issues/features will require careful thought & formal design before implementation. For these scenarios, we'll request that a spec is written and the associated issue will be labeled Issue-Feature.
+
+Specs help collaborators discuss different approaches to solve a problem, describe how the feature will behave, how the feature will impact the user, what happens if something goes wrong, etc. Driving towards agreement in a spec, before any code is written, often results in simpler code, and less wasted effort in the long run.
+
+Specs will be managed in a very similar manner as code contributions so please follow the "Fork, Branch and Create your PR" below.
+
+### Writing / Contributing-to a Spec
+
+To write/contribute to a spec: fork, branch and commit via PRs, as you would with any code changes.
+
+Specs are written in markdown, stored under the `/doc/spec` folder and named `[issue id] - [spec description].md`.
+
+👉 **It is important to follow the spec templates and complete the requested information**. The available spec templates will help ensure that specs contain the minimum information & decisions necessary to permit development to begin. In particular, specs require you to confirm that you've already discussed the issue/idea with the team in an issue and that you provide the issue ID for reference.
+
+Team members will be happy to help review specs and guide them to completion.
+
+### Help Wanted
+
+Once the team have approved an issue/spec, development can proceed. If no developers are immediately available, the spec can be parked ready for a developer to get started. Parked specs' issues will be labeled "Help Wanted". To find a list of development opportunities waiting for developer involvement, visit the Issues and filter on [the Help-Wanted label](https://github.com/microsoft/winget-pkgs/labels/Help%20Wanted).
+
+---
+
+## Development
+
+### Fork, Clone, Branch and Create your PR
+
+Once you've discussed your proposed feature/fix/etc. with a team member, and you've agreed an approach or a spec has been written and approved, it's time to start development:
+
+1. Fork the repository if you haven't already.
+1. Clone your fork locally.
+1. Create & push a feature branch.
+1. Create a [Draft Pull Request (PR)](https://github.blog/2019-02-14-introducing-draft-pull-requests/).
+1. Work on your changes.
+1. Build and see if it works.
+
+### Testing
+
+Testing is a key component in the development workflow.
+
+### Code Review
+
+When you'd like the team to take a look, (even if the work is not yet fully-complete), mark the Draft PR as 'Ready For Review' so that the team can review your work and provide comments, suggestions, and request changes. It may take several cycles, but the end result will be solid, testable, conformant code that is safe for us to merge.
+
+> ⚠ Remember: **changes you make may affect both the Windows Package Manager and the schema support implemented in our validation pipelines!** Because of this, we will treat community PR's with the same level of scrutiny and rigor as commits submitted to the official Windows source by team members and partners.
+
+### Merge
+
+Once your code has been reviewed and approved by the requisite number of team members, it will be merged into the main branch. Once merged, your PR will be automatically closed.
+
+---
+
+## Thank you
+
+Thank you in advance for your contribution! Now, [what's next on the list](https://github.com/microsoft/winget-pkgs/labels/Help%20Wanted)? 😜