我将使用细齿梳来遍历前面的线程，以尝试找出有效的方法和已损坏的方法，并确定一种更有用的机制-如果根本不需要。我也欢迎社区中有关如何继续捕获意外发生的正确事情的建议，鼓励社区停止并定期检查自己的表现。
因此：如果您对如何让社区监督自己的问答质量并有所反省的想法，请随时在答案中大声疾呼。通过创造性地使用按站点功能切换的应用程序，我们关闭了评估，除了在当前正在运行的少数几个站点上。一旦这些评估顺利进行，就不会在网络上的任何地方启动任何新评估。
#1 楼
好的，我会介绍一下网站质量指标，自由地借鉴一些在MSE上发布的想法。以下是IMO连续判断站点进度必不可少的主要部分：用户
问题
答案
审核
尽管SEDE查询中已经实现了一些指标，但如果可能的话，将它们组装在一个地方以供mods和CM以及普通公众细读是有意义的。 >用户
最重要的一组指标。
上周有多少用户发布了两个或更多推荐的答案？最好显示分布而不是总数。这是网站<1>的专家核心。
下图：该图将Space Exploration SE的用户描绘为节点和边（从X到Y），与“用户X的答案为正分用户Y的得分为正的问题”。地狱实际上是核心。
上周的核心大小与六个月前的相同指标相比如何（专家核心增长）？ （理想情况下，这里需要一个时序图）实际的实现由Isaac Moses提供，是SEDE查询/图形。歪斜统计数据）
下面的插图是原始三部曲的图表：截至2016年1月（表明趋势持续存在）： br />
2015年7月：
堆栈溢出核心
2016年1月
2015年7月
服务器故障核心
2016年1月
/>
2015年7月
超级用户核心
从上周的数字来看，一年前六个月以来的核心用户比例是多少？该措施（100％-专家倦怠率）。如果核心用户很快就感到无聊，那就是个问题。
SEDE查询
（100％-年倦怠率，在第15周进行测量以避免北半球的假期） />
2010 2011 2012 2013 2014 2015
SO 80.71 78.32 80.32 82.14 84.51 82.17
SF Jeff 81.51 83.57 82.60 78.04 87.27
SU N/A 90.90 84.80 86.72 91.07 89.88
Mathematics N/A N/A 63.30 69.84 69.55 71.39
U&L N/A N/A 70.00 88.09 74.07 80.70
上周每个用户每天的平均投票数。 （参与度投票）
与上述相同，减去具有101个声誉的用户的投票。这是对SuperCollider直接驾驶投票（更正的投票参与）的更正。
问题
自我评估结合了对问题和答案的评估。最好将这些项目分开。
上周和上个月每天的问题数量。根据新的毕业指导原则进行自我解释，但数字必须是最新的。 Area51 QPD的数量尚不清楚，还不够。被问到，积极的投票评分，上个月未关闭或删除的问题（1 /查看问题转换）。 “问题的比率”）。
上个月达到SuperCollider又名“热网络问题”的问题数量。不言而喻-我们不必衡量算法和副作用，而必须测量整个网络的站点可见性。
答案
平均答案长度，用言语。上个月的平均值。如果专家们懒得打字，这对网站来说是个问题。分发会很好。
每个答案的超链接/书籍或论文参考的平均数量，仅适用于分数为正的答案。上个月的平均值。不确定如何自动执行此操作-refs有多种用法，没有一个正则表达式可以捕获整个复杂性。此度量标准不适用于跨站点比较，但是众所周知，使用等式/图片/示意图/超链接/引用/代码片段的答案很好，一张图片价值一千字。这也有助于保持读者的注意力。由于缺乏更好的术语，我将其称为“丰富的内容比率”。每小时取样。 （关键审核指标）
上个月审核失败（如果启用）的比例。
上周拆分投票审核措施的比例。
上周未经主持人有约束力的表决而解决的行动比率与上次行动总数的比较（1-主持人升级比例-欢迎使用替代名称）
CM上个月解决的行动总数。挽救（关闭，编辑，重新打开）问题占噪声（关闭和删除）问题总数（上个月的平均值）的比率，由TildalWave提供，并恰当地称为Tildal Wave Ratio或挽救问题比率。
上周行动次数超过5次的非主持人审稿人/闭门投票人数（主持人核心人数）。 （针对编辑评论的SEDE查询，包括mods和非mods）
六个月前有多少位审核核心成员上周仍在积极进行审核（再次为1，审核倦怠率）？上周新的元视图到同一时期主要站点的视图（元相关性比率）。 >StackExchange活动根据星期几变化很大。选择一周进行平均，以消除这种影响并保持CM，mod和用户对观看不断变化的数字的兴趣（当数字始终保持不变时，这很有趣）。 （准确地说，是过去四个日历周）。 />
#2 楼
Engineering SE计划在几天之内开始进行站点自我评估。如果要在“本周”关闭它们，我希望会发生以下两种情况之一：在我们开始之前将它们关闭；或者，如果触发器在我们开始之前没有被拉动，请允许正在进行的站点自我评估运行到完成。消失。
评论
据我了解（我会检查以确保我是对的），当前正在运行的评估程序将正常运行，只是没有计划在6个月内再次出现。
–hairboat♦
15年7月29日在15:10
@abbyhairboat任何正在进行的评估都将立即停止。
–亚当·李尔♦
15年7月29日在17:26
对于标记了我的评论的人的澄清：我说的是如果/当切换开关时会发生什么。我是一名开发人员，而Abby是一名CM（ish），因此无处可提。 :)她和我一起检查了它的表现。我纠正了她的评论。
–亚当·李尔♦
15年7月29日在23:51
并完全关闭循环：我将等待拉关闭触发器，直到没有评估运行的时刻，所以我们最终不会在子元数据上出现一堆骨架评估帖子。
–hairboat♦
15年7月30日在20:03
永远不要说我知道我在做什么...忘记我们有网络级设置以及每个站点的覆盖，因此当前评估将按计划完成，而不会启动新评估（假设我们记得关闭（在接下来的几个月中的某个时候，目前每个站点将覆盖4个）。
–亚当·李尔♦
15年7月31日在5:40
#3 楼
我从未参加过评论，但是在阅读了上下文和其中链接的示例后，我认为最重要的一点是“结果是秘密的，通过电子邮件发送给公司内的少数人，并很快被人们遗忘了”。 />虽然可以像Deer Hunter所说的那样将统计信息自动化和发布，但对于在公共场所进行的任何讨论都非常有用：即使是聊天室或（公共）邮件列表（！）也比私人电子邮件要好。评论
当然是。无论我们可以创建哪种系统，理想的结果都是让很多人（主要是社区成员和主持人，偶尔有SE Inc.社区经理参与进来）消除质量问题和其他“我们做得如何”？在开放的网站metas中提出想法。
–hairboat♦
15年7月30日在20:34
#4 楼
我参与了一个beta站点的站点评估，并且我认为这是朝“毕业”（本身正在重新思考）迈进的一方面。但是，评估结果是在网站的Meta上共享的，因此它并不是“秘密”的，而是被描述为“普通用户忽略了由社区用户发布的meta线程”的情况。由于参与这些网站评估是自愿的，因此这些评估必然会受到偏向那些有能力和意愿表达意见的人们（例如我自己）的偏见。从数字上我认为，考虑到站点活动的数量，参与是合理的。
，我对评估答案（或多或少侧重于说明）与基本问题选择之间的混淆感到困扰不大进行这样的自我评估。
重做这种练习至少应将对问题和答案的评估分开。
评论
好点子。 “这个问题与您在更大的互联网上找到的其他答案相比如何？”是几乎没有任何意义的提示。
–hairboat♦
15年7月31日在19:32
评论
我不知道这是否是Right ^ TM选择，但我很高兴大家都在批判性评估已经存在很长时间的事情，而不是被传统束缚！我们对网站进行了社区评估吗？
@Robotnik每6个月，仅在Beta版网站上。
@abbyhairboat-我知道这是个玩笑：P
@Robotnik我以为可能是这样，但是我玩得很安全，却开了个玩笑。因为我讨厌玩。
我同意我不认为网站的自我评估非常相关，也无法提供良好的结果。当我完成所使用的Beta版网站时，我常常会想：“谁选择了这些问题？” ...这些是随机的还是什么？在不作进一步考虑的情况下，我会仔细研究所有问题，并尽力做到最好，试图诚实地进行评估。我相信这有什么好处吗？不，这也可以玩。我对此没有更好的解决方案，所以只待评论。提出一些更好的自我评估方法……这是必需的！
我从一开始就放弃了“一刀切”的想法。我知道一开始这是不切实际的。但是事实是，某些交易所永远不会有很多流量，但是仍然有很多价值。
@ouflak是的，可以肯定-价值和流量并不总是直接相关。实际上，他们经常不这样做。我们认为这种自我评估（从概念上讲，不是我们过去几年的实施方式）的部分原因是，鼓励人们在流量，活动等度量标准的背景下谈论不太实际的质量和价值等。
关于自我评估的自我评估...多数民众赞成...