Information on contributing to this repo is in the Contributing Guide in the Home repo.
The documentation is built using Sphinx and reStructuredText, and then hosted by ReadTheDocs.
Watch a video showing how to get started building the documentation locally.
Once you have cloned the Docs to your local machine, the following instructions will walk you through installing the tools necessary to build and test.
-
Download python version 2.7.10 or higher (Version 3.4 is recommended).
-
If you are installing on Windows, ensure both the Python install directory and the Python scripts directory have been added to your
PATH
environment variable. For example, if you install Python into the c:\python34 directory, you would addc:\python34;c:\python34\scripts
to yourPATH
environment variable. -
Install Sphinx by opening a command prompt and running the following Python command. (Note that this operation might take a few minutes to complete.)
pip install sphinx
-
By default, when you install Sphinx, it will install the ReadTheDocs custom theme automatically. If you need to update the installed version of this theme, you should run:
pip install -U sphinx_rtd_theme
-
Install the Sphinx .NET domain:
pip install sphinxcontrib-dotnetdomain
-
Navigate to one of the main project subdirectories in the Docs repo - such as
mvc
,aspnet
, orwebhooks
. -
Run
make
(make.bat on Windows, Makefile on Mac/Linux)make html
-
Once make completes, the generated docs will be in the .../docs//_build/html directory. Simply open the
index.html
file in your browser to see the built docs for that project.
You can also install sphinx-autobuild which will run a local web server and automatically refresh whenever changes to the source files are detected. To do so:
-
Install sphinx-autobuild
pip install sphinx-autobuild
-
Navigate to one of the main project subdirectories in the Docs repo - such as
mvc
,aspnet
, orwebhooks
. -
Run
make
(make.bat on Windows, Makefile on Mac/Linux)make livehtml
-
Browse to
http://127.0.0.1:8000
to see the locally built documentation. -
Hit
^C
to stop the local server.
Before adding content, submit an issue with a suggestion for your proposed article. Provide detail on what the article would discuss, and how it would relate to existing documentation.
Also, please review the following style guides:
Articles should be organized into logical groups or sections. Each section should be given a named folder (e.g. /yourfirst). That section contains the rst files for all articles in the section. For images and other static resources, create a subfolder that matches the name of the article. Within this subfolder, create a sample
folder for code samples and a _static
folder for images and other static content.
docs
/client-side
/angular
/_static
controllers.png
events.png
...
/sample
(sample code)
/bootstrap
/_static
about-page.png
...
angular.rst
bootstrap.rst
Note: Sphinx will automatically fix duplicate image names, such as the about-page.png files shown above. There is no need to try to ensure uniqueness of static files beyond an individual article.
Author information should be placed in the _authors folder following the example of steve-smith.rst. Place photos in the photos folder - size them to be no more than 125px wide or tall.
Step 1: Open an Issue describing the article you wish to write and how it relates to existing content. Get approval to write your article.
Step 2: Fork the /aspnet/docs
repo.
Step 3: Create a branch
for your article.
Step 4: Write your article, placing the article in its own folder and any needed images in a _static folder located in the same folder as the article. Be sure to follow the ASP.NET Docs Style Guide. If you have code samples, place them in a folder within the /samples/
folder.
Step 5: Submit a Pull Request from your branch to aspnet/docs/master
.
Step 6: Discuss the Pull Request with the ASP.NET team; make any requested updates to your branch. When they are ready to accept the PR, they will add a (:shipit:
) comment.
Step 7: The last step before your Pull Request is accepted is to squash all commits into a single commit message. Do this in your branch, using the rebase
git command. For example, if you want to squash the last 4 commits into a single commit, you would use:
git rebase -i HEAD~4
The -i
option stands for "interactive" and should open a text editor showing the last N commits, preceded with "pick ". Change all but the first instance of "pick " to "squash " and save the file and exit the editor. A more detailed answer is available here.
Below are some common pitfalls you should try to avoid:
- Don't forget to submit an issue before starting work on an article
- Don't forget to create a separate branch before working on your article
- Don't update or
merge
your branch after you submit your pull request - Don't forget to squash your commits once your pull request is ready to be accepted
- If updating code samples in
/samples/
, be sure any line number references in your article remain correct