-
Notifications
You must be signed in to change notification settings - Fork 3.9k
Issues list
On this page, learn how we use the issue list in this repo, including:
- How we use the issue list
- Issue templates
- What belongs in the issue list
- What doesn't belong in the issue list
- Our approach to closed issues
- Our approach to locked issues
- Our approach to notifying authors
- List automation
- Special actions
This repo contains three things:
- SharePoint Framework Web Part Samples
- Tutorials
- Issues related to the samples (questions, suspected bugs, problems, etc.)
The list is monitored and managed by the SharePoint PnP team, and numerous developers from the SharePoint community.
In early 2020, we introduced templates to the issue list. Now, when you create an issue, you're presented with three options for the type of issue to create:
- bug or error report: for reporting an anomaly or unexpected behavior with a sample from this repository.
- question: for submitting questions about a sample in this repository
- sample request: for asking members of the community for help building a new sample
- suggestion: for enhancements to samples in this repository, or the repository as a whole.
Each of these templates contains sections with guidance on what to complete
The issue list is used as the primary place for people to ask questions & report bugs about the samples.
What types of things belong on the issue list?
- Questions related to our samples
- Suspected bugs or problems with our samples
Equally important to what belongs in the issue list are those things that shouldn't be in the list. This includes the following things:
- Anything not directly related to a sample that exists in our repository. SharePoint development topics
- General SharePoint development issues (that's what the SP-Dev-Docs repository is for)
- Anything that is a SharePoint product issue
- SharePoint feature requests / suggestions (those go on the SharePoint Dev Platform UserVoice)
- Anything directly related to another project (for example, PnP PowerShell issues should be posted to that project's issue list)
- When possible, we'll transfer issues from this repo's issue list to the correct repo. However, we can only do this for repos in the same SharePoint GitHub organization.
Issues submitted to this repo's issue list incorrectly are tagged with one of two labels: type:invalid or type:invalid-not-sample-issue. This will automatically close the issue with a message explaining why.
Like most public repos on GitHub, we consider closed issues as a completed conversation.
Closed issues are not monitored for future comments. If you believe an issue was closed prematurely/incorrectly, please don't leave a comment on it... no one managing the list will see it.
Instead, create a new issue and reference the old issue using GitHub's automatic linking feature. Simply reference an issue with the # prefix (for example, issue 0000 would be #0000). This will also create a backlink from the target issue to your new issue.
Issues that have been closed for at least 7 days are locked automatically. We primarily lock issues to prevent people from adding comments that generally won't be seen by anyone.
If you believe an issue was locked prematurely/incorrectly, follow the same guidance above for closed issues: create a new issue and reference the locked issue.
All samples provided in this repository are provided by members of the community who volunteered their time to share how they approach solving a particular problem using SPFx web parts.
We have no control over -- and no right to expect -- whether an author will choose to maintain or update their samples.
We also don't know whether an author monitors this list issue.
As such, we try to notify authors once when a new issue is created by at-mentioning them, and hope that they will kindly take the time to respond to the issue.
That's why we always ask you, when creating new issues, to provide the sample name (so we can notify the original authors), your version of node (so we can cross-reference against the SPFx compatibility matrix), and other information that will reduce wasting the authors' and your valuable time.
There is a special process hooked up to the issue list that automates some tasks for us. This activity is performed by GitHub workflows. Some of the things it does:
- add comments to issues when they're tagged with certain labels
- close issues when they're tagged with certain labels
- tag issues with certain labels when issues become stale
- lock issues that have been closed for a period of time
Refer to the following sections for details on some of these automations:
At times we will ask the original poster (OP) of an issue for additional information on the issue they created. We do this by tagging the issue with the Needs: Author Feedback label.
If the OP doesn't respond within seven (7) days, the bot will add a reminder comment and the label no-recent-activity label to the issue.
If the OP still doesn't respond in another (7) days, the bot will automatically close the issue.
For most issue types, we expect the issue to relate to a specific sample. Every sample has a unique name (the folder name below the samples folder), and we ask you to provide that name when creating an issue.
If the issue does not relate to a known sample name, we automatically label the issue with status:wrong-repo or status:invalid-issue and close it.