To minimize maintenance, we should point users to the project's own npu docs when available

[zheliuyu]

Motivation

The trigger was noticing today while browsing the verl documentation that some parameters in the provided startup scripts have been added or removed in newer versions, but the project hasn't documented these changes. This may cause errors during use.

To minimize the maintenance cost of Ascend/docs, I think directly referencing the NPU usage documentation already provided by open-source projects would significantly improve the usability of Ascend/docs.

Method

Currently, I'm considering one approach: using the git submodule command to link the NPU documentation from the open-source project into the ./docs/sources folder, and then referencing it in index.rst. The advantage of this method is that if the open-source project updates its NPU documentation, Ascend/docs would automatically update the corresponding documentation. Of course, this depends on the branch specified during the git submodule operation.

verl has comprehensive NPU usage documentation. If the community thinks this idea has merit, I could update the verl project documentation to demonstrate the effect after implementing this method.

[zheliuyu]

@fffrog @noemotiovon @lowdy1 Hi team, wanted to get your thoughts on this approach.

[noemotiovon]

The issue you pointed out does indeed exist: as projects like verl continue to evolve, if changes to startup script parameters are not synchronized in Ascend/docs in a timely manner, they can easily confuse users or even lead to usage errors. Reusing and referencing well-maintained NPU usage documentation from upstream open-source projects is therefore a direction worth serious consideration.

That said, I think Ascend/docs should primarily retain the upstream project’s quick start. For more detailed or advanced content, users can be directed to the upstream project’s official documentation. If you are willing to update the documentation in the verl project first and demonstrate the overall effect of integrating it into Ascend/docs via a submodule, we would be very happy to see that and look forward to the results.