25개 이상의 토픽을 선택하실 수 없습니다. Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

02-Writing.md 3.2 KiB

1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162
  1. # Writing NTFSAccess documentation
  2. One of the easiest ways to contribute to the NTFSAccess PowerShell module is by helping to write and edit documentation.
  3. All the documentation hosted on GitHub is written using *Markdown*. Markdown is a lightweight markup
  4. language with plain text formatting syntax. Markdown forms the basis of our documentation's
  5. conceptual authoring language. Creating new articles is as easy as writing a simple text file by
  6. using your favorite text editor.
  7. ## Markdown editors
  8. Here are some Markdown editors you can try out:
  9. - [Visual Studio Code](https://code.visualstudio.com)
  10. - [Atom](https://atom.io/)
  11. - [Sublime Text](http://www.sublimetext.com/)
  12. ## Get started using Markdown
  13. To get started using Markdown, see [How to use Markdown for writing Docs](https://docs.microsoft.com/contribute/how-to-write-use-markdown).
  14. The Open Publishing System (OPS) is the platform used by docs.microsoft.com. OPS uses DocFX Flavored
  15. Markdown (DFM). DFM supports all GitHub Flavored Markdown (GFM) syntax and is compatible with
  16. CommonMark. There are some [differences between DFM and GFM][dfm-diffs] that can affect content
  17. preview in GitHub or your editor.
  18. The default Markdown engine in OPS is built on the top of [markdig][]. This engine is based on the
  19. CommonMark specification and supports extensions for DocFX. In the latest version of the [CommonMark][]
  20. specification, many spacing rules have changed. Spaces are significant in Markdown. Don't use hard
  21. tabs in Markdown. For more detailed information about the Markdown specification, see the
  22. [Markdown Specifics](04-Markdown-Specifics.md) article.
  23. ## Creating new topics
  24. To contribute new documentation, check for issues tagged as ["in progress"][labels] to make sure
  25. you're not duplicating efforts. If no one seems to be working on what you have planned:
  26. - Open a new issue and label it as "in progress". If you don't have rights to assign labels, add "in
  27. progress" as a comment to tell others what you're working on.
  28. - Follow the same workflow as described above for making major edits to existing topics.
  29. - Add your new article to the `TOC.yml` file (located in the top-level folder of each
  30. documentation set).
  31. ## Updating topics that exist in multiple versions
  32. Most reference topics are duplicated across all versions of PowerShell. When reporting an issue
  33. about a cmdlet reference or an About_ article, you must specify which versions are affected by the
  34. issue. The default issue template in GitHub includes a [GFM task list][gfm-task]. Use the checkboxes
  35. in the task list to specify which versions of the content are affected. When you submit a change to
  36. a article for an issue that affects multiple versions of the content, you must apply the appropriate
  37. change to each version of the file.
  38. ## Next Steps
  39. Read the [Style Guide](03-Style-Guide.md).
  40. <!-- External URLs -->
  41. [markdig]: https://github.com/lunet-io/markdig
  42. [CommonMark]: https://spec.commonmark.org/
  43. [gfm-help]: https://help.github.com/categories/writing-on-github/
  44. [labels]: https://github.com/PowerShell/PowerShell-Docs/labels/in%20progress
  45. [gfm-task]: https://github.github.com/gfm/#task-list-items-extension-
  46. [dfm-diffs]: https://dotnet.github.io/docfx/spec/docfx_flavored_markdown.html#differences-between-dfm-and-gfm