首先，我知道这里可能不是提出这个问题的合适地方，所以如果这个问题被关闭了，绝对不会有什么冒犯。
我更像是 LaTeX 的最终用户，而不是程序员。我怀着敬畏和好奇的心情，经常感到完全困惑，因为越来越多的 LaTeX3 问题或答案一点一点地出现在 TeX.SX 中。但我总是想着“我希望我可以做到这一点”和“我很乐意帮忙，但是......”。
所以：
严格的最终用户或几乎是新手可以通过什么方式帮助 LaTeX3 项目？（是的，“避开”是一个绝对可以理解的答案。）
什么是合适的对于和我水平相当但不一定想深入研究肠道的人来说，有没有什么阅读清单？
我还需要了解什么？
答案1
正如我在回答这个问题时尝试解释的那样，“LaTeX3 与纯 lua“我对 LaTeX3 的设想实际上是一个具有多层的系统，为不同类型的角色提供接口。这些层是
- 底层引擎（一些TeX变体）
- 编程层（核心语言，即
expl3） - 排版基础层（为排版提供更高级的概念）
- 排版元素层（所有类型文档元素的模板）
- 设计器界面基础层
- 类设计器层（其中定义具有特定设置的文档元素实例）
- 文档表示层（提供输入语法，即作者如何使用元素）
如果从用户角色的角度来看，那么至少有三到四种角色可以清楚区分：
- 程序员（模板和功能提供者）
- 文档类型设计器（定义哪些元素可用；抽象语法和语义）
- 设计师（排版和布局）
- 作者（内容）
因此，LaTeX3 项目需要不同类型的帮助，具体取决于我们所关注的层或角色。
“作者”正在使用列表结构，方法是\begin{itemize} \item在他的文档中指定一些内容。或者可能是通过书写<ul> ...</ul>或 UI 表示提供给他的任何其他内容。
“文档类型设计器”定义了什么样的抽象的文档元素可用，以及这些元素在作者级别提供哪些属性或参数。例如，他可以指定某一类文档提供显示列表“枚举”、“逐项列举”和“说明”。
另一方面，“程序员”为此类文档元素（例如显示列表）实现模板（提供自定义功能）。“程序员”应提供何种自定义功能属于“文档设计师”的职责范围，他决定设计需要何种灵活性。在大多数情况下，“文档设计师”应该能够简单地从模板库中提取模板（已编写），并只关注设计，即使用值实例化模板，以便创建“逐项”列表等所需的布局。
在现实生活中，一个人最终可能会扮演多个角色，但重要的是要认识到所有角色对界面和功能都有不同的要求。
编程层
程序层由核心语言层（称为expl3（经验值埃里门塔尔大号特克斯3) 由于历史原因，现在我们被它困住了 :-)) 和另外两个组件：“排版基础层”，我们目前正在研究，以及将为设计层提供可定制对象的“排版元素层”。expl3在许多部分已经相当完整和可用，另外两个正在建设中。
此层需要帮助
- 通过扩展和完成回归测试套件来帮助
expl3 - 帮助提供良好或更好的文档
- 可能有助于编写额外的核心功能，但与前两点相比，这需要大量的投入和核心语言的经验，否则危险太高，最终结果会不一致
一旦我们对“排版基础层”有了进一步的了解，我们就需要帮助
- 提供更高级别的功能，或许利用扩展的可能性重写元素的现有包/代码
再往前走两步（一旦“设计层”接近完成），我们将需要帮助
- 开发各种元素的模板
总而言之，对于这一部分，我们需要对 TeX 编程感兴趣和expl3/或有兴趣提供文档的人的帮助（但为此，彻底理解编程概念也是必要的）。
设计层
设计层的目的是提供允许以声明方式指定布局和排版样式的接口。在实现方面，有许多原型实现（最值得注意的是xtemplate和最近重新实现的ldb）。这些需要统一为一个通用模型，这需要更多的实验，可能还需要一些进一步的思考。
但这一层真正的重要性不在于其接口的实现，而在于其概念视图：提供丰富的声明性方法（或多种方法）来描述设计和布局。也就是说，使设计师能够从视觉表现和关系而非程序的角度进行思考。
因此，对于那些觉得自己不需要或无法编写 TeX 碗的人来说，这是一个很大的帮助领域。非常有帮助的（实际上不仅限于 LaTeX3）是
- 收集并分类巨大的一套布局和设计
- 单个文档元素的设计（例如标题、目录等）
- 包含文档元素之间关系的文档设计
- 思考声明式好的指定此类设计的方法
- 需要具体说明什么
- 在多大程度上以及具有何种灵活性
我相信这是一项艰巨的任务（但本身就很有价值），收集现有设计规范的第一部分将是一项重大任务，需要协调，可能还需要大量工作。但稍后测试此层的任何实现和接口将是一笔巨大的财富。
文档接口层
如果我们正确地完成了分离，那么这一层实际上应该只提供用于解析文档语法并将其转换为内部标准化形式的前端。这意味着在这一层上，我们不应该看到任何（或很少）编码或计算。
设想可以提供替代的文档语法模型。目前我们有一个草案解决方案，该xparse软件包提供 LaTeX2e 风格的文档语法，即带有*-forms、括号中的可选参数等，但带有一些附加功能，例如更通用的默认值概念、支持参数的附加分隔符等。不过，这是相当传统的。此外，在编写时，层的明确划分尚未明确定义，因此该软件包还包含用于条件编程的组件，我认为这些组件不再应该存在。
这一层需要做的底线是
- 从“作者”的角度思考提供文档内容的良好语法
- 从“应用到排版”的角度思考提供文档内容的良好语法，即自动排版的语法和结构，其中内容是由系统/应用程序而不是人工准备的
两者可能需要结构（事实上最有可能需要，因为自动化在没有太多替代可能性和快捷方式等的结构下工作得更好），即使只看人类作者，也有很多未解决的问题需要回答。这些答案可能会或可能不会在所有情况下（或者可能在任何情况下？）痛苦地坚持现有的 LaTeX2e 惯例。
这些都不需要编码或expl3经验。它需要的是熟悉现有的输入概念、了解当前的痛点所在，以及愿意思考和讨论替代方案和扩展方案。
总之
基本上，任何级别的帮助都是可能的，而且不需要涉及编程。以上文章中散布着各种想法，但这里还有一些亮点：
- 帮助开发/改进核心编程层
- 加入改进测试套件的努力
- 帮助改进现有（或不存在）的文档
- 参与制作核心或辅助代码模块的努力
- 设计层上的帮助
- 收集和分类设计任务（需要什么......）
- 思考并建议以声明方式描述布局要求的方法
- 帮助塑造文档界面层
这些概念及其实现正在 LATEX-L 列表中讨论。您可以通过发送邮件至加入此列表，该列表仅用于讨论未来版本的 LaTeX 的想法和概念[电子邮件保护]包含行
订阅 LATEX-L 你的名字
一旦您订阅，您可以通过电子邮件将帖子发送至[email protected]。
Gmane 托管一个 Web 界面，其中包括 LATEX-L 列表的档案：http://news.gmane.org/group/gmane.comp.tex.latex.latex3。如果您如上所述订阅了 LATEX-L，则可以使用此 Web 界面参与列表上的讨论，否则您只能阅读其他人的条目。
目前该列表的访问量相当低，因为实际的实施和开发任务通常由少数活跃的实施者直接讨论。但如果有更多的人加入，这种情况可能会改变。
还有一些其他的东西...
LaTeX3 团队也致力于保持 LaTeX2e 的稳定性，尽管现在没有太多事情要做，但仍需要解决错误报告（如果它们涉及 2e 核心），偶尔提供新的发行版等。所有这些都是工作需要付出努力或仍未完成或未完成的工作。因此，如果我们能获得帮助以释放资源，这将对 LaTeX3 工作有所帮助。
最值得注意的是：我们最近重新开始努力让 Babel for LaTeX2e 重回正轨，欢迎任何帮助。如果您想加入这项工作，请联系@JavierBezos 或我本人，或者通过 LATEX-L 联系我们。