@danilo-leal 我们已经讨论了一段时间类似的事情，我认为无论我们是否有一个真正的"共享"文档空间，我们至少需要在mui.com/docs上有一个统一的页面来整合所有的文档。你怎么看？另外，如果我们继续推进这个项目，它应该看起来更像是一个营销页面，还是更像一个文档页面？我没有强烈的意见，但我倾向于文档风格，只是因为我希望在一个叫做mui.com/docs的页面上找到那样的东西。cc @oliviertassinari@michaldudak@gerdadesign

I have added a few more benchmarks. Looking at the benchmark, here are the problems that it seems they try to solve (doesn't apply to all)

• I have too many projects to link from the home header directly. Some developers prefer to follow the docs -> product user flow rather than the product -> docs user flow, let's offer them both option.
• To help users orient themselves, could be cool when have breadcrumbs to be able to reach the root, it even helps with SEO bots to crawl.

Regarding the problem that we would solve with this page that is described "What if they don't know which one to select?", none seems to have tried to solve it. I'm not sure it should be the role of this page, but more for the marketing pages, before starting to look at the docs. A bit like https://www.hashicorp.com/why .
On a related note, maybe miss pro-code docs, MUI Core + MUI X docs, or a welcome/home docs. All of this content feels out of place:

• Changelog https://mui.com/material-ui/discover-more/changelog/
• Roadmap https://mui.com/material-ui/discover-more/roadmap/
• Vision https://mui.com/material-ui/discover-more/vision/
• Sponsors & Backers https://mui.com/material-ui/discover-more/backers/
• Design kits
• Showcase
• Versions https://mui.com/versions/

我同意所有这些页面都更适合一个通用的文档区域。我喜欢将“为什么”页面作为我提议的“欢迎”页面的补充。欢迎页面可以是关于所有产品和文档本身的简短、信息丰富的介绍，而“为什么”页面可以从营销Angular 提供更多细节，说服读者尝试我们的产品。
在查看了您提供的额外基准之后，似乎大多数都给这个页面提供了标准的文档样式，而少数几个则将其视为集中式中心/搜索引擎。在我们的情况下，我认为前者可能是理想的选择，尽管我们可以将搜索栏突出显示以鼓励读者使用它/向他们展示如何使用。

帮助人们定位自己的目标对我来说是有意义的！从我这个新手的Angular 来看，一些可能有用的东西是描述这些文档是为谁编写的，在什么阶段使用什么，以及概述它们如何一起工作。也许这也能给我们一个更好的地方来存放那些隐藏在更深层次菜单下的 design resources ,设计师不太可能找到它们。我喜欢这里的许多示例都有一个简短的、一行代码的描述每个产品。
以下是一些额外的例子，我注意到了一个共同的主题，即“入门”部分有更多友好的介绍信息和视频。随着我们开发其他格式的教育内容，这可能是一个有用的地方。
Looker
Launch Darkly
AG Grid
Flutter
Kendo

很高兴看到这个项目正在进行中！我个人非常喜欢这个想法。虽然营销页面和/docs空间对我来说有不同的用途，但前者更多地是关于展示，依赖于更具视觉吸引力的元素，给定产品的核心功能或价值主张,而后者则涉及更深入的内容。
/docs似乎是我们打印到任何产品上的通用规范最合适的地方。我想到的一些例子：

• Composition:我可以很容易地将这视为Joy、Material和Base共享的组件组合哲学。它目前仅位于Material文档中。
• API design approach 是一个非常相似的情况。
• Vision:尽管它看起来有点过时，但我也可以看到我们将一些关键手册内容带到了这个环境中。
• Understanding MUI packages:这绝对是只在Material UI文档中才有意义的东西。
• Localization:这也是公司通用MUI的方法。

我相信可能还有其他的例子，但这只是为了说明。此外，我认为我们在会议上提到的一点是，这个潜在的通用文档空间与手册之间存在重叠。我们应该将/docs空间用于相关的客户/用户信息，并将手册保留为潜在/当前员工的相关信息。