瀏覽代碼

Update projects.md

Signed-off-by: Jonathan Capes <[email protected]>
Jonathan Capes 3 年之前
父節點
當前提交
814bfc5201
共有 1 個文件被更改,包括 1 次插入1 次删除
  1. 1 1
      projects.md

+ 1 - 1
projects.md

@@ -28,6 +28,6 @@ Some notes:
 | Lua API Reference | @FiniteStateGit | Proposed project - Lua Documentation.  Determine what steps are required to generate online documentation of the Lua API.  Determine if o3de\Assets\Editor\Translation\scriptcanvas_en_us.ts is sufficient to generate an API.  If generating API documentation is technically feasible, proceed with documenting the API on the docs site.  Scope of proposed documentation: Reflected class_name, method_name, method_parameters, parameter_type. | :x: | :white_check_mark: | @FiniteStateGit |
 | Programmer Guide reorganization | @chanmosq | We have a discoverability issue on the documentation website: Information for core developers (and others) is scattered in locations where it can be difficult to find, especially with the website search not working well. We'd like to discuss finding a good way to reorganize the content and get people interested in content architecture working together. | :x: | :white_check_mark: |@chanmosq |
 | Minimum viable documentation | @sptramer | Right now there is no amount of documentation required for a feature for O3DE to be considered "DONE". This project will work to define reasonable docs-related requirements (including requirements on API reference) that we feel feature engineers _must_ meet in order to submit a feature. | :white_check_mark: | :white_check_mark: | @sptramer / @chanmosq | 
-| Website versioning | @sptramer + sig-release | The website needs to be versioned! This will become an increasingly important problem as we release versions which will be in production for longer stretches of time (Long Term Release, LTS). We also have an issue where the velocity of `development` is impossible to track correctly in tandem with website deployments - separating "stable" documentation for a box release will help us provide guidance for in-flight documentation processes, since there will be a whole docset based around `development`. | :stop_sign: | :white_check_mark: | @willihay |
+| Website versioning | @sptramer + sig-release | The website needs to be versioned! This will become an increasingly important problem as we release versions which will be in production for longer stretches of time (Long Term Release, LTS). We also have an issue where the velocity of `development` is impossible to track correctly in tandem with website deployments - separating "stable" documentation for a box release will help us provide guidance for in-flight documentation processes, since there will be a whole docset based around `development`. | :white_check_mark: | :white_check_mark: | @willihay |
 | API reference generation | @sptramer | Currently API reference is generated on a manual basis "when I (@sptramer) remember to do it." Obviously this is not acceptable, especially under website versioning! This project requires an RFC (for process and infrastructure approval), and implementation work (to provide the system for generation). Templates and tools being used to generate the documentation in its current state will be made available. | :x: | :white_check_mark: |@chanmosq |
 | RFC for Feature Grid | Linux Foundation | Required by the TSC for the overall feature grid. See: https://github.com/o3de/o3de/issues/6821 - docs requires its own specialized breakdown since we operate in a different way from the code base. Any RFC should consider the fact that API documentation coverage is important. | :white_check_mark: | :white_check_mark: | @Finite_State |