Explain what it does, probably also by explaining the problem it solves. If you can do that in big type (somewhere between the size of a Stack Overflow question heading and the text of the actual question) in 2-3 sentences, so much the better, you can link to the "learn more" page where you do the deep dive.
Make it very easy to download a copy and get started. (A big "download now" link is good. MoFo did this very well with the Get Firefox site and that pattern has spread appropriately. If it's a package install e.g. a Ruby gem, spell out the steps.)
Show where people can go to ask questions, and/or the documentation. You do have documentation, right? (Or you're working on it?)
Beyond that, link to the necessary stuff: code repository for those who want to browse, a more detailed "about" page (that might be part of the documentation), list of contributors (might also be part of the documentation) but the big part is to answer Why and How as succinctly as you can.
Basically, that's the story. Your first page is the first slide or two of your presentation.
Users of your project are interested in this things, in order of purely subjective importance:
Downloading your apps
Knowing what your apps does (project descriptions, screenshots)
Get Help and Documentation
How to report bugs
How to get access to the source and to contribute
How I would do it is to have a huge download link in the first page, with a short description of what your program is (max. 1-2 paragraph). Then there should be a link in obvious place longer description; forum/mailing list and documentations; and how to contribute and to report bugs.
Rationale
Why download links first instead of project description first?
Your user likely come from two sources:
articles referring your project, or your project announcement forums
search engine
In both cases, it is very likely they already have an idea of what your project is about before landing on your page. In the first case, they have read the article; while in the second case, they are searching for a tool similar to your project.
However, for the second case, it is likely that they are still not sure that your project really are what they are looking for; that is why you add a brief project description on the side of the download link. This is to ensure them your project is/is not what they are looking for.
Why "Help and Doc", "Bug Report", then "Contribute"?
That's the order that user will do when they have problems with your program. First, they will look at the help and documentations, then maybe ask a few people in the forums; failing that, now they will file a bug report or feature requests; then if nobody took interest on the bug report/feature request, some will then have have the willingness to contribute.
发布评论
评论（4）
以下是我在开源项目的登陆页面上寻找的一些内容，按优先级
Here are some things that I look for on the landing page of an open source project, in approximate order of priority
解释它的作用，也可能通过解释它解决的问题来解释。如果您可以用大字体（介于 Stack Overflow 问题标题和实际问题文本之间的大小）用 2-3 个句子来完成此操作，那就更好了，您可以链接到“了解更多”页面，您可以在其中链接到“了解更多”页面。进行深潜。
让下载副本并开始使用变得非常容易。 （一个大的“立即下载”链接很好。MoFo 在 Get Firefox 网站上做得很好，并且这种模式已经适当传播。如果是软件包安装，例如 Ruby gem，请详细说明步骤。）
显示人们可以访问的位置提出问题和/或文档。您确实有文档，对吧？ （或者你正在研究它？）
除此之外，链接到必要的东西：为那些想要浏览的人提供的代码存储库、更详细的“关于”页面（可能是文档的一部分）、贡献者列表（可能是也成为文档的一部分）但最重要的部分是尽可能简洁地回答为什么和如何。
基本上，故事就是这样。您的首页是演示文稿的第一张或两张幻灯片。
Explain what it does, probably also by explaining the problem it solves. If you can do that in big type (somewhere between the size of a Stack Overflow question heading and the text of the actual question) in 2-3 sentences, so much the better, you can link to the "learn more" page where you do the deep dive.
Make it very easy to download a copy and get started. (A big "download now" link is good. MoFo did this very well with the Get Firefox site and that pattern has spread appropriately. If it's a package install e.g. a Ruby gem, spell out the steps.)
Show where people can go to ask questions, and/or the documentation. You do have documentation, right? (Or you're working on it?)
Beyond that, link to the necessary stuff: code repository for those who want to browse, a more detailed "about" page (that might be part of the documentation), list of contributors (might also be part of the documentation) but the big part is to answer Why and How as succinctly as you can.
Basically, that's the story. Your first page is the first slide or two of your presentation.
对于新/潜在用户：
我认为您的大部分回访将来自使用您项目的开发人员；想想您作为开发人员可能需要什么：
For new/potential users:
I think the majority of your returning visits will be from developers using your project; think of what you as a developer might need:
您的项目的用户对这些事情感兴趣，按照纯粹主观重要性的顺序排列：
如何我会做的是在第一页上有一个巨大的下载链接，并附上您的程序的简短描述（最多 1-2 段）。然后在明显的地方应该有一个更长的描述的链接；论坛/邮件列表和文档；以及如何贡献和报告错误。
理由
为什么首先下载链接而不是项目描述？
您的用户可能来自两个来源：
在这两种情况下，他们很可能已经拥有一个在登陆您的页面之前了解您的项目是关于什么的。在第一种情况下，他们已经阅读了这篇文章；而在第二种情况下，他们正在寻找与您的项目类似的工具。
然而，对于第二种情况，他们很可能仍然不确定你的项目是否真的是他们正在寻找的；这就是为什么您在下载链接一侧添加简短的项目描述。这是为了确保他们您的项目是/不是他们正在寻找的。
为什么是“帮助和文档”、“错误报告”，然后是“贡献”？
这是用户在使用您的程序时遇到问题时会执行的顺序。首先，他们会查看帮助和文档，然后可能会在论坛上询问一些人；如果做不到这一点，他们现在将提交错误报告或功能请求；那么如果没有人对错误报告/功能请求感兴趣，那么有些人就会愿意做出贡献。
您可以从以下位置获取想法：
Users of your project are interested in this things, in order of purely subjective importance:
How I would do it is to have a huge download link in the first page, with a short description of what your program is (max. 1-2 paragraph). Then there should be a link in obvious place longer description; forum/mailing list and documentations; and how to contribute and to report bugs.
Rationale
Why download links first instead of project description first?
Your user likely come from two sources:
In both cases, it is very likely they already have an idea of what your project is about before landing on your page. In the first case, they have read the article; while in the second case, they are searching for a tool similar to your project.
However, for the second case, it is likely that they are still not sure that your project really are what they are looking for; that is why you add a brief project description on the side of the download link. This is to ensure them your project is/is not what they are looking for.
Why "Help and Doc", "Bug Report", then "Contribute"?
That's the order that user will do when they have problems with your program. First, they will look at the help and documentations, then maybe ask a few people in the forums; failing that, now they will file a bug report or feature requests; then if nobody took interest on the bug report/feature request, some will then have have the willingness to contribute.
You can get ideas from: