Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

[chore] Restructure developer docs

未关闭
#855 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
20/100
Issue 类型
文档
描述清晰度
需要澄清
活跃度
停滞
领域
documentation

调研方向

首先检查版本化文档结构,尤其是 Developer Guides、Core APIs、Plugin Types 和 Subsystems。比较 Output 等 API(包括 format_string 和 format_text)当前记录在何处,并确定应如何重新组织。完成标准是达成一项共识,采用更清晰的指南和指向实时文档的链接,而不是静态函数签名。

由索引模型根据 Issue 内容生成。

描述

help wanted needs-triage repo
What do we need to do?

When we started the devdocs we tried to consider to structure our existing content better.

We have, largely speaking, achieved that. However, the current structure is still somewhat confusing.

flowchart TD
    C[Versioned documentation]
    C --> GUIDES[Developer Guides]
    C --> API[API Guides]
    API --> FILES[Common files]
    API --> CORE[Core APIs]
    API --> PLUGIN[Plugin Types]
    API --> SUBSYSTEM[Subsystems]
    C --> DEVUP[Developer Updates]

Within each of API guide sections we have a fairly large list of APIs and information, and it isn't always clear which location docs should be in. For example, the Output API documentation which covers critical methods such as {{format_string}}, and {{format_text}} are under Subsystems, but arguably these shoudl be uder "Core APIs". For most people APIs such as these subsystem APIs are so critical to the daily development of Moodle that their categorisation as a subsystem is confusing when compared to a subsystem such as Task, Editor, Privacy, Check, Availability, etc.

I think we need to find a way to reduce these restructure some of these categories, and perhaps toimprove our "Developer guides" too.

Many of the se Core API and Subsystem docs would be better served as guides. It is not in our interest to store API documentation in any static form with function signatures in these docs. We should find better ways to link to the live documentation instead.

主要语言
TypeScript
星标
74
派生
652
平均合并
1 天 15 小时
30 天内合并 PR
9

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

moodle/devdocs 的其他 Issue

查看 moodle/devdocs 的全部 Issue

相似的 Issue

更多 TypeScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。