How Can I Contribute?
There are many ways for you to contribute to RESTier. The easiest way is to participate in discussion of features and issues. You can also contribute by sending pull requests of features or bug fixes to us. Contribution to the documentations is also highly welcomed.
You can participate into discussions and ask questions about RESTier at our Github issues.
When reporting a bug at the issue tracker, fill the template of issue. The issue related to other libraries should not be reported in RESTier library issue tracker, but be reported to other libraries' issue tracker.
Pull request is the only way we accept code and document contribution. Pull request of document, features and bug fixes are both welcomed. Refer to this link to learn details about pull request. Before you send a pull request to us, you need to make sure you've followed the steps listed below.
Pick an issue to work on
You should either create or pick an issue on the issue tracker before you work on the pull request. After the RESTier team has reviewed this issue and change its label to "accepting pull request", you can work on the code change.
Steps to create a pull request
These are the recommended steps to create a pull request:
- Create a forked repository of https://github.com/OData/RESTier.git
- Clone the forked repository into your local environment
- Add a git remote to upstream for local repository with command git remote add upstream https://github.com/OData/RESTier.git
- Make code changes and add test cases, refer Test specification section for more details about test
- Test the changed codes with one-click build and test script
- Commit changed code to local repository with clear message
- Rebase the code to upstream via command git pull --rebase upstream master and resolve conflicts if there is any then continue rebase via command git pull --rebase continue
- Push local commit to the forked repository
- Create pull request from forked repository Web console via comparing with upstream.
- Complete a Contributor License Agreement (CLA), refer below section for more details.
- Pull request will be reviewed by Microsoft OData team
- Address comments and revise code if necessary
- Commit the changes to local repository or amend existing commit via command git commit --amend
- Rebase the code with upstream again via command git pull --rebase upstream master and resolve conflicts if there is any then continue rebase via command git pull --rebase continue
- Test the changed codes with one-click build and test script again
- Push changes to the forked repository and use --force option if existing commit is amended
- Microsoft OData team will merge the pull request into upstream
All tests need to be written with xUnit. Here are some rules to follow when you are organizing the test code:
- Project name correspondence (
X -> X.Tests). For instance, all the test code of the
Microsoft.Restier.Coreproject should be placed in the
Microsoft.Restier.Core.Testsproject. Path and file name correspondence. (
X/Y/Z/A.cs -> X.Tests/Y/Z/ATests.cs). For example, the test code of the
ConventionBasedApiModelBuilderclass (in the
Microsoft.Restier.Core/Convention/ConventionBasedApiModelBuilder.csfile) should be placed in the
- Namespace correspondence (
X.Tests/Y/Z -> X.Tests.Y.Z). The namespace of the file should strictly follow the path. For example, the namespace of the
ConventionBasedApiModelBuilderTests.csfile should be
- Utility classes. The file for a utility class can be placed at the same level of its user or a shared level that is visible to all its users. But the file name must NOT be ended with
Teststo avoid any confusion.
- Integration and scenario tests. Those tests usually involve multiple modules and have some specific scenarios. They should be placed separately in
X.Tests/ScenarioTests. There is no hard requirement of the folder structure for those tests. But they should be organized logically and systematically as possible.
Complete a Contribution License Agreement (CLA)
You will need to complete a Contributor License Agreement (CLA). Briefly, this agreement testifies that you are granting us permission to use the submitted change according to the terms of the project's license, and that the work being submitted is under appropriate copyright.
Please submit a Contributor License Agreement (CLA) before submitting a pull request. Download the agreement), sign, scan, and email it back to email@example.com. Be sure to include your Github user name along with the agreement. Only after we have received the signed CLA, we'll review the pull request that you send. You only need to do this once for contributing to any Microsoft open source projects.