ASP.NET Core Development Sprints
A sprint is an in-person or virtual event where community members can contribute to the ASP.NET Core project, with the help of ASP.NET Core maintainers.
Participation is open to anyone with experience developing C# and familiarity with ASP.NET Core.
Read through this document which outlines:
- how to set up your development environment
- the criteria for a pull request submission
- issues available to work on
It's recommended that you read through the first three sections before the day of the event to get familiar with the process and expectations. You can review the first section to identify issues to work on.
In addition to asking questions on the GitHub issue or pull request you are working on, you can ask questions on the ASP.NET Core discord in the #aspnet channel under FRAMEWORKS.
Once your pull request has been successfully implemented, reviewed, and merged, it'll ship in an upcoming release of .NET. To figure out what release your PR will ship in, you can check the "Milestone" attribute on the PR to determine the version it will be released under. You'll receive a shout-out on the release blog post for that version.
Sometimes, your pull request might contain a new feature or major change that cannot be shipped in an upcoming release, such as an RC. In that case, your pull request may be closed. Don't worry though, it'll be re-opened and your commits will be reused in the event that we decide to take up the feature for a later release.
Mentors are available to help you set up your development environment, guide you if you are stuck debugging, help out with the design process, and more. During the sprint, mentors will be focusing on helping participants who are working on pull requests. If you need help with a general ASP.NET Core issue or have an unrelated bug to discuss, please open an issue in this repo.
You can find complete setup instructions for this repo in the build documentation.
Before starting work, it's worth making sure that your change is likely to be accepted. We recommend:
- In most cases, it's best to find an existing issue to work on. Try looking at the lists of good first issues and help wanted. When you find one you'd like to work on, post a message to the issue saying you're getting started to be sure you're not duplicating effort with others.
- If you want to work on something that has no existing issue, or the existing issue isn't labeled help wanted, then please contact someone on the ASP.NET Core team to check whether it's an area we're ready to accept changes in.
If you're going to do a meaningful amount of work on an issue, or if your contribution will involve any changes to ASP.NET Core's public APIs, you should first post a description of your planned approach on the issue and speak with a ASP.NET Core team member about it.
All merged contributions will end up in many thousands of projects and will run on millions of end-user machines. Any APIs you add will have to be supported by Microsoft for many years. We have to be sure that it's secure, will perform well, will make sense to other developers, and fits in with longer-term plans for how the framework should evolve. That's why we're very careful about what gets added! Since you're also invested in the long-term success of ASP.NET Core, we hope you agree with these goals.
- You find an existing issue with the "help-wanted" label or discuss with the ASP.NET Core team to agree on adding a new issue with that label
- You post a high-level description of how it will be implemented, and receive a positive acknowledgement from the team before getting too committed to the approach or investing too much effort implementing it
- You add test coverage following existing patterns within the codebase
- Your code matches the existing syntax conventions within the codebase
- Your PR is small, focused, and avoids making unrelated changes
- Changes that break backward compatibility
- Changes that are only wanted by one person/company. Changes need to benefit a large enough proportion of all ASP.NET Core developers.
- Changes that add entirely new feature areas without prior agreement
- Changes that are mostly about refactoring existing code or code style
- Very large PRs that would take hours to review (remember, we're trying to help lots of people at once). For larger work areas, please discuss with us to find ways of breaking it down into smaller, incremental pieces that can go into separate PRs.
- Ensure the formatting adheres to our editor config
- Make sure that tests properly dispose of resources
- Verify that the code compiles and tests run.
- Follow our coding guidelines as listed here: https://github.com/dotnet/aspnetcore/wiki/Engineering-guidelines#coding-guidelines and https://github.com/dotnet/runtime/blob/master/docs/coding-guidelines/coding-style.md
- When making changes to a public API surface, follow the instructions listed in APIBaselines
To get started, you'll need to find an issue you're interested in working on. Issues that are available for community contribution are labeled with the "help wanted" tag on GitHub. This GitHub query lists all the issues that are available to work on.
To get started with contributing:
- Set up your development environment based on the instructions above.
- Find an issue in the query above that you are interested in working in.
- Post a GitHub comment on the issue saying you're interested in working on it.
- If you have some ideas on how a particular issue should be resolved, post these ideas in the comment.
- If you have some questions about the issue, add these as well.
- If your issue doesn't require any design work, this is where the coding starts.
- If your issue does require some design work, you should find a mentor on the Discord channel to flesh out elements of the design before coding.
- Code up your PR keeping the guidelines above in mind.
- Submit the PR for review and mention a mentor or someone on the team in the open PR.