令人担忧的大量错误建议编辑被接受。例如:


对随机单词添加错误格式的编辑
破坏代码块格式的编辑
添加错误标签的编辑
将Wikipedia转储添加到标记Wiki的编辑
将链接明显替换为垃圾邮件的编辑
仅将无关内容替换实际URL的编辑
更改作者解决方案的编辑
添加的编辑对帖子的评论

(这些只是一些常见模式的示例。也存在相反的现象。)

我们应该怎么做才能教育评论者做得更好?

这是一个悬而未决的问题,而不是功能要求,因为我没有很好的答案。一些可能性:


提供一种通知审阅者的方法(“嘿,检查所提议的标签Wiki是否被s窃”)。
只要拒绝的工作流程,这样人们就不会因为工作量少而盲目批准。 (我不知道某些评论者是否倾向于这样做。)


评论

相关:在回滚时拒绝已批准的建议编辑,请帮助撤消不良建议编辑带来的危害

一个简单但可能没有帮助的想法是增加必须审核编辑的人员数量...但这只会使清除编辑队列更成问题,并且不能保证审阅者比他们现在更加关注。

@BenBrocka我们的队列没有足够的眼睛。每天每人的配额已增加(从40个增加到现在的50个),即使好心的评论者也无法提高评论的质量。此外,如果不良评论者的比例足够小,更多的眼睛只会提高可靠性:是吗?

@DaveNewton对于每种模式,我都举了一个例子。 #3显然不是家庭作业,不应将家庭作业标签摘要添加到其他人的帖子中。 #4是非法的(Wikipedia内容需要注明出处),除此之外没有帮助。

@DaveNewton讨论仍在进行中,但大多数人似乎都赞成摆脱家庭作业标签。这是绝对没有意义的,并且可能会严重损害网站的整体质量,因为它通常被用作废话的借口。
第二个示例中的块是错误消息,而不是代码。与原始帖子相比,此编辑稍有改进,但不如以后的编辑好。

虽然我确定不良的编辑是一个问题,但我严重怀疑大多数编辑的投票是不正确的,这将是唯一的情况,即更多的评论会使批准的可能性降低。而且,如果大多数编辑选票不正确,那么整个系统都需要进行大修(但我严重怀疑确实如此)

一方面,我们应该停止允许匿名建议的编辑。我想不起来是什至尝试遵循SE准则的。不参加这里的随机互联网用户不知道我们的工作方式。我们甚至不应该让他们的编辑获得批准的机会。

@BilltheLizard该块是错误跟踪。编辑破坏了源代码中的换行符,使迹线不可读且难以重新编辑为形状。这个特别的建议者喜欢这样糟糕的编辑,我记得我拒绝了他的许多编辑,然后回去修复他想找的一些帖子。终于,有一天,他获得了“复制编辑器”徽章并停止编辑…

解决此问题后,让我们修复由于投票或被接受而导致的错误答案

您知道的,我必须大声疾呼:stackoverflow.com/suggested-edits/344474。主持人批准100%窃的文本。标签Wiki流程是否可以快速在Google中搜索相似的短语,并在非常接近的匹配项时自动拒绝它?当拒绝投票被推翻时,我几乎放弃了对编辑的审查。

@LittleBobbyTables这是一个好主意,可能值得作为单独的功能请求发布。我通常会搜索是否看到类似于广告文案的内容,但我敢打赌,过去我已经批准了类似的标签Wiki编辑。

@LittleBobbyTables:其广告文案。您知道,他们想在互联网上找到的东西拉皮条他们的产品。 IP不能保护您喜欢的东西。我花了一点时间来添加归因。以防万一他们的广告人不满意他们的副本在经常访问的网站上的显眼位置。

爱的夏天结束了吗?我期待着我们的不满情绪消退。

@ Wo n't Shhh,不要让孩子们知道今年的“爱之夏”生意只是假装诱使他们更多,并在萨卡斯姆陷落中将其用作大炮饲料。

#1 楼

建议的编辑系统的问题之一是,提交接受投票或为此拒绝投票几乎需要零时间或精力。做正确的事情和改善错误的建议会花费更长的时间。

我经常尝试改善建议的编辑。有时,它们是很好的建议,因为编辑者修复了50个错别字,而恰好错过了一个错别字,但这很少见。在绝大多数情况下,我单击“改进”时,原始建议是无用的,怪异的,严重不完整的或什至是积极有害的,并且我取消选中“建议是有帮助的”。

取消选中该框太无用了,以至于我不确定为什么要打扰。每当我提出一个不好的建议时,我的工作都会被接受。到了我完全不鼓励使用改进选项的地步。



不采取行动投票后立即接受/拒绝投票(对于SO,则为两张同意的投票)。强制建议在队列中停留n分钟。


如果随时提交改进建议,请立即接受(就像当前的工作方式一样)。如果计时器的总票数(接受和拒绝)都达到某个阈值,则计时器计时结束,然后以多数票通过。
否则,将计时器增加m分钟,并希望有更多的人查看该帖子或供某人改进。


如果某人建议改进,请停止接受对该建议的接受/拒绝表决。

再也不要在队列中显示建议。
如果提交了改进,请立即接受(就像当前的工作方式一样)。
如果改进是已取消,请重新开始将其显示在建议队列中。
p分钟后,如果尚未提交改进建议,请假设改进者放弃了修正建议的尝试,然后再次将其显示在建议队列中。 />


当前系统的另一个问题是缺乏对参与者的反馈。建议审核者无法知道社区是否同意他们的决定,因此糟糕的审核者会继续明显地做得不好。只要审阅者批准不良编辑,建议不良编辑的用户就不会知道自己需要改进,更不用说要改进了,这篇文章的其余部分都不重要。

建议提交者有更好的选择,但这只是因为门槛太低了。他们可以通过重新访问自己编辑的帖子来确定他们的编辑是否已被接受,但是只有在编辑被审核之后,谁知道需要多长时间?他们还可以检查自己的代表,但这只会告诉他们批准的情况,而不是拒绝的情况,并且最多可以告诉他们1000个代表,甚至在他们的总代表低于2000时也是如此。那些反复提出不良修改建议的人会被自动禁止,但是该禁止的设计方式无法促进改进。

可能的解决方案(可以结合使用):


为编辑提供更多有关其建议是否不错的反馈。如果编辑被拒绝,请确保用蓝色级别的通知来解释原因。允许社区标记低质量的建议批准,并向编辑和审阅者提供反馈。 (即使在这个问题上也曾有人提出过此建议。)
使个人评论统计信息在用户个人资料中更加突出。这可能是一个隐藏的部分,例如当前有用的标志和投票部分。
在“建议所有所需的编辑”和“禁止一周内建议编辑”之间添加一个中间步骤,以某种方式告诉用户“由于X,Y和Z的原因,您的很多建议都被拒绝;您可能想重新阅读编辑指南。”
将审核者要求从完全基于编辑特权更改为部分基于审核者以前的接受/拒绝投票是否正确。 (部分受此想法启发。)这个想法在我的脑海中经过了无数次迭代,可能太复杂了,无法实现,但也许会有助于头脑风暴。实际上,跟踪审阅者的质量可能不像我想的那么牵强!根据开发人员Kevin Montrose的说法,某种“审核”系统正在开发中。


评论


我认为您的第一个解决方案没有任何意义,n取决于星期的时间和随机因素而有很大的不同。您的第二个建议确实有意义,并且可能会起作用。

–吉尔斯'所以-不再是邪恶的'
2012年8月12日21:35

有时我会先拒绝,然后向提交者提供反馈(并不是说这样做会做得很好,因为提交者必须经过多次讨论才能看到反馈),然后单击“改进”并确保取消选中“有用”框。但是,如今,仅键入自定义拒绝原因就足够了,可以接受糟糕的编辑!

–吉尔斯'所以-不再是邪恶的'
2012年8月12日21:38

@Gilles我想也许我在解释我的第一个建议时并不清楚,我已经编辑了。您能否再次检查并让我知道您是否仍然不同意?

– Pops
2012年8月12日在21:42



我不认为在固定的时间内等待另一个用户干预可能是一件好事。没有办法知道需要多长时间,最好尽快检查编辑。顺便说一句,我认为对编辑的反馈是必不可少的。可悲的是杰夫反对。

–吉尔斯'所以-不再是邪恶的'
2012年8月12日在21:48



好的,我可以理解这一观点。我只是认为,当前的问题要迅速审核并迅速接受不良修改,这比人为的时间限制要严重。

– Pops
2012年8月12日在21:51

我认为#2是关键。改善职位应始终比按原样批准优先。帮助用户发现并从他们的编辑建议结果中学习,这些建议看起来也与您的兴趣相关。

–布拉德·梅斯(Brad Mace)
2012年8月12日在22:34



正如大众需求所指出的那样,@ Gilles尽早批准建议正是问题所在。人们正在通过单击几乎出现的所有内容上的“接受”来尽快审查它们。正确处理是我们需要担心的。

–布拉德·梅斯(Brad Mace)
2012年8月12日在22:38



@BradMace批准建议是问题所在。但是快速(正确)检查它们是系统的目标。

–吉尔斯'所以-不再是邪恶的'
2012年8月12日在22:40

要/复习/复习!

–蒂姆·斯通(Tim Stone)
2012年8月13日19:51

@TimStone嘿,是的,我确实想过我写作时看起来多么愚蠢的“元审查”。但是,例如,如果有计时器系统,则实际上并不需要/ review / review。我已经思考了一段时间,特权系统应该更多地基于功绩而不是声誉,但是我意识到朝这个方向的重大改变不会很快发生,甚至永远不会发生。

– Pops
2012年8月13日在20:04

当我开玩笑地发表评论时,我实际上并不认为这很愚蠢。我不确定为什么人们只是为了加盖橡皮戳而出现要审查的事情,因为这可能比排队的情况有害得多。有办法教育或以其他方式制止这些人,这似乎是有好处的,但要保留原始编辑人员的问题。

–蒂姆·斯通(Tim Stone)
2012年8月13日在20:13



好吧,如果这一切都是愚蠢的,没有实质性的,我不会建议的。但是,有一个合理的问题:我们怎么知道/ review / reviewers会比/ reviewers更好?我们需要/ review / review / reviewers吗?在不知不觉中,它一直都是乌龟。任何形式的元审查最多都是绷带。真正需要发生的正是您(和我)所说的:人们正在学习如何正确地进行审查。

– Pops
2012年8月13日20:25



可能与审阅者审阅相关:审阅beta:低质量显然是个好答案

–蒂姆·斯通(Tim Stone)
2012年8月13日在20:51



#2 楼

我能想到的唯一一件事就是允许用户在发现已批准的错误编辑时标记特定的修订。如果发现针对特定审阅者的所有这些标记中的足够有效,请给它们一个暂停审阅的时间。您还同时审查了同一编辑。或者,在被禁止审核之前,可能只是较低的门槛。 >

评论


我会全力以赴将标志修订为不正确,甚至可能更好,将标志接受器标记为粗心。召集人们是一种不好的形式,但是我可以轻松地命名六个习惯接受错误编辑的用户。

– LittleBobbyTables-互惠生
2012年8月8日在0:48



#3 楼

到目前为止,似乎没有人提到过一件非常简单的事情:为审阅者提供基本说明。当前的说明很少(单击“更多”后):




批准您认为正确的编辑

拒绝那些您知道错了

改进以改进此建议的编辑

如果不确定并不确定要跳过此建议的编辑,则不确定




什么是正确的还是错误的?还不清楚这些词至少可以链接到FAQ或元讨论。更不用说“改善”的描述,基本上说“改善以改善”!

我现在没有任何有关新指令的建议,但我敢肯定我们可以提出经过足够的讨论,事情会变得更好(简洁)。

此外,我不认为这可以完全解决问题,但这仍然是向前迈出的一步。

UPDATE:我创建了一个“审核指南”常见问题解答提案。它仍然是草案,欢迎社区提供任何帮助。

评论


可能应该只是规范的“我如何查看帖子?”和“应批准/拒绝哪种编辑?”与评论系统相关联的元数据问题,并在人们首次开始使用该系统时立即摆在人们面前。然后,社区可以随时对其进行编辑。

–服务
2012年8月15日17:43



我们如何以一种实际上会导致人们阅读它们的方式呈现这些扩展的说明?经验表明,需要最多指导的用户对指导的接受最少。

– Pops
2012年8月15日在18:01

@PopularDemand也许说明框应默认为扩展状态,至少对于审查少于x个问题的用户而言。它不能保证他们会阅读它,但是比将其隐藏在“更多”链接下更好地面对他们。而且,我完全同意您的建议,为编辑人员提供更多反馈,并允许社区标记低质量的编辑内容。这些应该至少使某些人寻求有关如何编辑的更多信息。

– bfavaretto
2012年8月15日23:01

我对此表示同意。在黑暗时代,我什至尝试做类似的事情。我必须承认,如果我在不同的审阅队列上大都拒绝,那是因为我经常只是不确切知道我应该做什么。 (或者将废话编辑成形状太难了...)

– Benjol
2012年11月27日10:41



确实需要在这些基本说明中阐明正确的较小修改。否则,已经阅读过meta内容的编辑将知道会赞成拒绝还是改进,但是我们仍然会继续收到大量建议的编辑,以得到六种形式的接受,拒绝和编辑,其中有一个随机获胜,有人进行编辑,以及每个回到最后的结果,对最终结果感到沮丧。

–马克·赫德
2014年7月11日下午6:50

#4 楼

停止将编辑/审阅特权与信誉联系在一起。我坚信,您所享有的声誉与您的编辑能力之间没有任何关联。

您可以学习成为一名优秀的编辑,但只能通过编辑许多问题并获得有关问题的反馈,而不是通过赢得声誉。无需编辑任何问题,某人就能获得必要的声誉来进行审核和编辑。比。例如,说至少要进行250次编辑,批准率为90%。

批准无效的编辑所造成的损害要大得多,而不仅仅是让一些不好的问题过去。它教会了新用户错误的编辑和查看方式。

评论


IIRC的一名开发人员表示,很难将特权与声誉以外的其他事物联系在一起,不过我现在找不到该职位。在SO外部至少不能进行250次编辑,我认为整个SE上不可能有单个数字,这会使情况更加复杂。

–吉尔斯'所以-不再是邪恶的'
2012年8月8日在1:21

@Gilles在各个站点上获得特权的声誉也可能不同。例如。 “创建标签”在SO上需要1500代表,在IT安全上只需要300代表。因此,从最终用户的角度来看,这应该不是问题。

– S.L.巴特-恢复莫妮卡
2012年8月8日在6:15

相关:这个问题和这个问题。

– S.L.巴特-恢复莫妮卡
2012年8月8日在6:22



@Gilles我不同意250次编辑在SO之外太难了。我在Mi Yodeya上有很多类似的东西-如果您算上仅标签编辑的内容,那么更多,而我已经不到一年了。

–Scimonster
2015年1月1日17:32

@Scimonster这不是可行的问题,而是是否有足够的人可以达到目标,以便有足够的人来安排审核队列。在没有很多旧资料需要更新的年轻站点上尤其如此-例如,Emacs(约3个月大)的单个用户拥有250次编辑,但有17位用户拥有2000次代表,而35位用户拥有1000个代表(测试版网站的阈值)。

–吉尔斯'所以-不再是邪恶的'
2015年1月1日17:46

#5 楼

似乎大多数自动审查员都接受,因为那只是一次点击,而不是三次拒绝。因此,要增加点击次数才能批准错误的编辑,将会减慢机器人审阅者的速度。

如果编辑有任何拒绝票,请在单击批准时显示警告。它将显示类似“此编辑已具有x拒绝票。您确定要批准吗?”之类的内容。那里会有一个“仍然批准”按钮。然后可能会有一行,并且标准拒绝表单就在那儿。

我不会绘制图像,所以这是它看起来的纯文本格式:


此修改已有x拒绝票。您确定要批准吗?

<仍然批准>


拒绝此编辑


垃圾邮件或破坏行为
此编辑污损了该帖子以促销产品或服务,或故意破坏性。
毫无改善
此编辑无法使该帖子更易于阅读,更容易找到,更准确或更易于访问。更改完全是多余的,或者会严重损害可读性。
不相关的标签
此编辑引入的标签不会帮助定义问题的主题。标签应有助于描述问题的含义,而不仅仅是描述的内容。
与作者的意图明显冲突。
此编辑偏离了帖子的原始意图。甚至必须进行重大更改的编辑也应努力维护帖子所有者的目标。
尝试回复[1]
此编辑旨在解决帖子的作者,并且作为编辑没有意义。 。应该将其写为评论或答案。
造成伤害[]





这也可能适用于其他评论队列。

#6 楼

一种可能的解决方案是使拒绝比率更高的用户难以批准,拒绝它的拒绝也更容易:

if(reviewer is OP){
    1 app./rej. gets approved/rejected //current behavior
}else{
    if(Editor has at least 10 edits){
        if(  1/10  to   0/10 rejection) 2 app. gets approved, 3 rej. gets rejected
        if(2.5/10  to   1/10 rejection) 2 app. gets approved, 2 rej. gets rejected //current behavior
        if(  4/10  to 2.5/10 rejection) 3 app. gets approved, 2 rej. gets rejected
        if(  10/10 to   4/10 rejection) 3 app. gets approved, 1 rej. gets rejected
    }else{
        2 app. gets approved, 2 rej. gets rejected //current behavior
    }
}


数字可能变化,但我认为它们反映了最常见的类型:完美,中等,需要一些工作,而得不到适当的保护/障碍

评论


在绕过狂热的编辑者的审阅队列时,已经提出了类似的建议:“编辑权重数字/功能可以安排建议的编辑队列,以便来自“既定编辑者”的建议趋于首位...改写国旗重量的当前说明以使其符合要求”

– gna
2012年8月18日在7:29



#7 楼

一个相当简单的步骤是:不允许再次建议被拒绝的编辑。我发现:我和其他人拒绝的修改只是由同一用户重新提交,直到他们发现差评者为止。

解决方案:如果编辑被拒绝,则不允许建议者编辑该帖子/ Wiki再次持续24小时。我猜那应该很容易实现。

评论


这是有道理的,但这种情况很少见。大多数不满意的编辑者都会编辑帖子并继续前进,甚至不知道他们的编辑被拒绝了。

–吉尔斯'所以-不再是邪恶的'
2012年8月8日,1:11

@Gilles您的来源吗?我认为这没有受到监控(足够)。

– fuxia
2012年8月8日在1:12



没有关于拒绝编辑的通知,即使您想知道也要找出来,这很繁琐。已请求通知。我已经审查了整个SE的近10,000次修改,而且除了标签Wiki之外,我从未见过如此关注于一篇文章,因此,我敢肯定这种情况很少见。

–吉尔斯'所以-不再是邪恶的'
2012年8月8日在1:16



@Gilles没有通知?如果不知道结果的人通知我们,我们如何期望做出不好修改的人学到任何东西?

–布拉德·梅斯(Brad Mace)
2012年8月8日在18:18

@bemace因为Jeff不喜欢告诉用户他们做得不好。

–吉尔斯'所以-不再是邪恶的'
2012年8月8日在20:14



@toscho良好的一致拒绝会产生一定的影响:“来自多个用户的重复编辑建议拒绝会导致您的编辑建议权限被暂停(n)天,其中n当前为7”(引用来源)

– gna
2012年8月18日18:58



@gnat我在谈论不一致的拒绝。

– fuxia
2012年8月18日在19:03

@toscho确实不难。六次拒绝可以触发禁令-这是我一年前的经历

– gna
2012年8月18日19:34

就我而言,我尝试从每一次编辑中学习,以确保我不会重复犯错。但是,当我95%地确定自己是对的时候遭到不公平的拒绝时,我会感到非常沮丧。我必须承认,由于这个原因,我过去确实提交了两次修改。您的观点很不错,但这可能无法解决IMO的真正问题。

–ForceMagic
2013年12月18日上午8:05

#8 楼

我将把它作为一个单独的问题发布,直到遇到这个话题。如果该措辞似乎有误,那是因为它是作为独立文章发布的。

我相信我的观点与大多数已经提供的答案不同,因为它更多地侧重于提高意识而不是报复。

我在建议的编辑审阅队列中遇到的问题非常简单:人们通过批准编辑来鼓励编辑不足。

我看到了一个通过的大量编辑只能部分修复某些内容,或者简单地掩盖最终获得批准的帖子。以下是过去一小时的几个编辑示例(2个不同的用户),但这当然不是质量低劣的编辑的短暂涌动。

情况1

https://stackoverflow.com/review/suggested-edits/3667680

乍一看,这似乎还不错。然后,当您仔细观察时:


标题中的语言标记
代码格式不完整(StudentCourse保持未选中状态)
英语没有一个被固定
/>
查看此答案的总修订版时,您会发现它需要3个以上的修订版本才能构成正当的形状。 ://stackoverflow.com/review/suggested-edits/3667621


随机代码格式
未固定英语
未删除“谢谢”

再次单击一次{}按钮并将其他所有内容保留在其中的情况

https://stackoverflow.com/review/ proposal-edits / 3667617


标题中的语言标记
随机代码格式
代码格式的错误消息,使其难以阅读

唯一的实质性修改并不是特别有用。

情况4

https://stackoverflow.com/review/suggested-edits/3667520
这实际上被拒绝了,但仍然获得2票赞成票。
从字面上看,它没有任何用处:


未解决可怕的标题
随机代码格式化
添加了错误的英语
删除了两行空格,在其中留了三行,并且没有碰到缩进

他仍然获得了2票赞成票。

情况5、6和7

https://stackoverflow.com/review/suggested-edits/3667714https://stackoverflow.com/review/suggested-edits/ 3667686https://stackoverflow.com/review/suggested-edits/3667650

这些编辑中的每一个都获得批准,而它们所做的唯一一件事就是将jsfiddle链接放在一个词后并加粗一些已经

实际上,还有几个(次要)问题根本没有涉及。如果这些内容足以让其通过,那么其他内容也应足以拒绝编辑:


使用粗体而不是代码格式设置的代码
Irrelevant标签
代码没有缩进

我想用这个帖子做什么?

我相信这里有一些问题。
我通过纠正原始帖子和建议的编辑来浪费时间。
如果在我获得批准之前就批准了它,人们会读到质量差的帖子。
尽管没有实质性的更改,但仍被推到顶部。
间接地鼓励进行不充分的编辑,因为似乎其中许多被批准。网络。

我相信这里的主要罪犯是赞成这些建议并随后鼓励这种行为的人。作为审阅者,我们有可能阻止这些编辑进入系统,但似乎我们作为一个小组在大量时间内未能完成此任务。

我不会否认我可能将标准设置为高于通常接受的标准,但是我强烈怀疑这些建议是否应该接受。理想情况下,编辑应该解决帖子中的所有问题,而我发布的示例绝对不能做到这一点。他们要么简单地破坏职位,然后执行一种特定且通常不正确的操作(人员1),要么他们发明问题并进行不重要的更改。

我们该怎么办?

我认为向人们提供有关投票方式的反馈很重要。据我所知,除非您明确跟踪该编辑,否则我们将无法查看其余审阅者对该投票的看法。这项工作很多,需要打开许多标签,而不必首先进行。

建议无效编辑的建议在收到建议后应收到通知被拒绝了。我在2k之前的时间段内未进行任何建议的修改,因此我不可能(如果可以的话,请告诉我),但是如果“自定义消息”选项确实显示给该人本人,我们可以
主要针对那些进行无效建议狂潮的人,如果您正在进行审视狂潮,通常会得到一些建议。

然后,消息可能还不够。现在,有一个公式可以阻止人们在7天的时间内拒绝提出建议,如果他们收到过多的拒绝。

公式是

(rejects - (approvals / 3)) >= 5


这本身就是一个很好的公式,但我相信我们可以用它做更多的事情。当涉及到调整行为时,从无概念到完全停止并不是一个好主意。人们会因为太多的拒绝而被禁止,而他们基本上只有一种感觉:为什么我没有及时告诉我?

我认为这正是应该发生的情况。一旦达到特定阈值,您应该收到警告,表示您收到太多拒绝。通过分阶段工作并在人们与社区的其他成员变得更加亲密时积极批准他们,可以更容易地纠正此问题(我们将假定整个社区具有正确的判断,从而绕开任何哲学讨论)。 br />
通过添加这些警告,当用户遭到很多拒绝时,他们会更快地收到通知,并能够更快地改善他们的建议。同样,当系统告诉他们他们的建议得到更多认可时,他们将获得系统的积极通知。

简而言之:


给与我们的投票结果。无论是即时还是一天结束时,我们都可以通过社区决定我们裁定的案件。
让用户知道他们的建议何时被拒绝以及为什么。
在用户得到建议时提供警告接近锁定期。
当用户的批准等级上升时,提供肯定的通知。


评论


有一个长期存在的错误,建议不要使用“改进”按钮,尤其是在SO快速的情况下。我绝大部分时间都停止了对建议的修改的审查,因为我已经厌倦了无所不用其事的改进。

–吉尔斯'所以-不再是邪恶的'
2013年12月26日19:06



向编辑告知他们被拒绝的编辑是一项长期存在的功能要求。但是杰夫(当时的老板)不想要它。 Shog9(现在是老板)稍微合理一点,但是什么也没发生。

–吉尔斯'所以-不再是邪恶的'
2013年12月26日19:08



关于改进功能的非常有效的评论,通常是我得到这样的消息,即帖子已被批准,这迫使我去实际的问题,并用我之前所做的更改来更改问题的内容。

– Jeroen Vannevel
2013年12月26日19:14

@Gilles:看起来该错误终于得到修复和部署;检查您的链接。

– AndrewS
14年2月18日在21:41

#9 楼

记录下来,被拒绝,已批准和有争议的编辑所占的百分比随着时间的推移一直保持不变-但随着人们对这些系统越来越熟悉,总数已大大增加。因此,与其他所有工具一样,工具也必须随之改进。在实践中,批准这些似乎太容易了-更多关注它们应该有所帮助。


中期:实施此方法。如果提交的错误编辑次数较少,则效果会更好。


长期:继续监视此情况,并听大家的建议。 />

评论


您认为这会产生积极影响吗?我不认为缺少差评者。另外,为什么要增加SO以外的数字?我在SO之外(或也许在三部曲之外)的印象是,审阅者往往是更专注的用户,唯一真正糟糕的决定是标签Wiki中的Wikipedia转储,甚至大多数人都赞成。

–吉尔斯'所以-不再是邪恶的'
2012年10月16日20:23

@吉尔斯:我希望效果会很好,无论好坏。关于SO的有争议的批准数量约为15%,高于年初的7%(有争议的拒绝也有所增加,但数量明显减少)。在SO之外启用它的原因是,没有多个评论,很难跟踪有争议的评论。这意味着我真的无法告诉您在SO之外发生了多少有争议的批准或拒绝,因为通常无法对它们进行竞争!如果这是个问题,我想知道-轶事不会走太远。

–Shog9
2012年10月16日20:40

好的,那很有道理。我仍然想知道您如何知道无可争议的评论是不错的-我知道我看到过很多不好的评论,但是我无法给出可靠的统计估计。

–吉尔斯'所以-不再是邪恶的'
2012年10月16日20:47

除了查看每个人并记录我自己的(始终是客观的)意见之外,缺少寻找表明不同意的行动(反对票,回退等)的好方法,就没有判断“良善”的好方法。反对票是我现在拥有的最好的东西。

–Shog9
2012-10-16 20:49

正确的做法是遍历随机样本并将其分类为明显错误/边界/明显正确。我曾经想过要自己做,但是1.我从来没有找到时间,并且2.为什么无论如何你会信任我(我做了很多回顾,但是根据我自己的说法,这并不表明我我很擅长)。

–吉尔斯'所以-不再是邪恶的'
2012年10月16日在21:07

@ Shog9,您要我开始羞耻吗?在过去的一个小时里,我至少看到3次垃圾编辑的批准,这些垃圾编辑“无可争议”,这仅仅是因为eejit审核者比我早就到达了那里。

– Benjol
13年2月13日在7:39

现在,将其回滚@Benjol-如果您看到相同的审阅者经常弄乱了,请标记。

–Shog9
13年2月15日在2:47

#10 楼

Beta版审查系统启动后,队列中建议的编辑数量很少,这显然不像我们想象的那样好,并且导致该问题和此处提出的一个因素之一是缺乏审稿人需要付出的努力。但与此同时,Beta审核系统也导致缺乏工作。这确实是一个有趣的问题22。

但是问题不仅仅在于无需费力批准编辑,还在于用户提出建议的事实。我真的不知道他们在做什么。

我刚刚看到了建议的编辑,而且我不知道该怪谁。我是责怪审稿人做得很糟糕,还是建议者做出的修改有损于帖子(URL引用使我无法进入呈现的视图……只有降价视图使我了解了这种奇怪的情况) 。

因此,谁来接受更好的教育成为一个问题。在上述情况下,我更倾向于建议者-有了Markdown的更多知识,该编辑本可以非常有帮助(至少对我而言;链接到文档总是很好)。编辑的意图很有帮助,而且乍一看,我可以看到为什么审稿人批准了它(他们没有特别糟糕的批准历史)。编辑,它替换了指向YouTube视频之一的链接...并获得批准。在这种情况下,我显然倾向于审稿人。上帝知道他们的脑子里遇到了什么,这很可能是为了使队列保持清晰(尽管我不明白为什么这样做对他们有益,因为没有认可的奖励)。

所以我们陷入了僵局–我不认为有一种一致的方法可以消除问题,从而更好地教育用户。另外,我认为我们为帮助用户学习系统而建立的任何系统都足够有用。

但是我想提出一个论点,即高声誉和良好的评审技能之间是否存在关联。此处的用户认为不存在相关性,即用户无需进行一次编辑即可获得足够的声望来批准/拒绝。

确实如此,但请仔细阅读:唯一的一个赢得声誉的方法是问好问题并发布好答案(如果低于5000,则建议标签Wiki编辑,但+2则不重要)。这两个指标(至少对我而言)是某个人知道什么构成了一个很好的问题/答案,并且我可以相信他们批准了良好的编辑并拒绝了错误的编辑。

但是2000 rep是绝对没有足够高的阈值来确定用户是否真的了解好问题和坏问题之间的区别。因此,我的建议是将审阅建议的编辑所需的声誉(又由于两个特权相关联,因此可以自由编辑的声誉)提高到5000。审稿人(因为5000+告诉我他们有很好的问题/答案质量历史记录),并且批准了不正确的编辑次数。批准了YouTube编辑的垃圾邮件的用户遭到入侵或纯粹是为了踢kick脚...这个世界可能永远都不知道。)

#11 楼

人们会犯错误。你无法避免。建议的编辑界面易于使用。但是不幸的是,接受要比拒绝容易(您必须给出拒绝的理由)。并且当人们有疑问时,人们倾向于积极的一面(至少是有益的一面)。

此外,如果某个帖子已经有了接受或拒绝的投票,那么从心理上讲,进行第二次投票是很有吸引力的:

但是当我查看编辑队列的大小时,我认为并没有太多人活跃。因此,也许一些教育可能会有所帮助。也许是供审核者阅读的小型电子课程。

评论


已编辑有55个编辑建议被批准,39个编辑建议被拒绝。我会说一些用户失败的次数和成功的次数差不多。但是,他们的编辑却一直被“错误地”批准。

–user7116
2012年6月26日在21:51



#12 楼

除其他事项外,或作为一项单独的措施,我认为防止接受不良编辑的一种方法是允许发表原始帖子的人在任何其他人有机会之前批准或拒绝编辑。如果他们在经过一定时间后仍然不执行任何操作,或者他们主动断言自己不想采用任何一种方法,则可以将编辑放入审阅队列中,以进行其他适当的处理。我认为这是可行的,因为原始发帖人更容易理解和关心建议的编辑是否有所改进,也使他们有更直接的机会来学习应如何表达和格式化问题或答案。

请澄清一下,这是我要记住的工作流程:


用户A发布问题或答案。
用户B决定编辑用户A发表的帖子
用户C随即决定编辑该帖子,但由于用户A尚未做任何事情而不能编辑
用户A有机会接受,拒绝或跳过编辑


如果用户A接受编辑,则应用于帖子
如果用户A拒绝编辑,则回滚所做的更改,并且帖子可以由用户C编辑
如果用户A选择跳过编辑,则该帖子进入评论队列。
如果用户A在一定时间后不执行任何操作,则该帖子进入评论队列。




#13 楼

我实际上登录了meta来回答这个问题。
这是可以做的事情:

编辑经过同行评审和批准后,将其通知原始用户,并询问他是否会接受此作为编辑以及进行编辑的原因。
Ofc。编辑帖子的用户必须具有一定的声誉才能获得此特权。

原始海报不接受的每个编辑都必须使编辑返回到同行视图(希望这次是其他人)并根据该结果,必须由第一位编辑否定声誉。

感到困惑? ,则PQR会对其进行编辑,如果ABC的声誉为100(例如),他可以看到他的帖子已被编辑并带有编辑原因,并询问他是否喜欢建议的编辑,如果他喜欢,则表明编辑很好!并且已由即将到来的堆栈成员批准,如果只有它被ABC拒绝或不喜欢,这次,编辑将进入XYZ。如果XYZ批准PQR的编辑很好,则PQR得到+ rep else -rep。

这将实现什么?


编辑成员将收到反馈有关如何编辑而不是如何编辑的信息。
对自己的帖子进行了编辑并且也许喜欢编辑的成员将知道将来如何发布。此刻,当我是新手时(请参阅我的stackoverflow个人资料,我最近才加入)。有人编辑了我的帖子,我一直想知道更改了什么!!!相信我,我还是不知道!但是,在如何发布帖子时要牢记所有内容,甚至包括那些在搜索引擎上寻求答案的人。如果您可以看到我编辑的帖子很少,其中成员rep比我的要多得多,并且历史要比我的要长,但是,发布内容的感觉并没有按照他们的习惯进行创作。

,不是为了赏金,而是为了把事情讲清楚。你问的好! :)

评论


好吧,通常来说,帖子的最终编辑者通常是不知道如何编辑帖子的人们。当然有例外,但这不是普遍情况。

–服务
2012年8月15日17:45

@Servy我根据我在stackoverflow上的经验写了一个答案,确保各地到处都有巨魔(包括meta),他们在不理会原因的情况下对我的帖子投了反对票

–因果报应
2012年8月15日17:48



IMO,StackOverflow将是最糟糕的地方

–安德鲁·巴伯(Andrew Barber)
2012年8月15日17:50

嗯……也许,你最好呆在那儿……但是,想一想,每天很少有明智的人加入SO,特别是那些进入Android的人!

–因果报应
2012年8月15日17:51

欢迎使用Meta!我认为这具有涉及代码和/或措辞更改的编辑的潜力,因为OP确实是唯一可以判断帖子原始意图的人。另一方面,它可能对拼写/语法/格式编辑有害。如果OP不太经常访问该网站,则审核可能需要很长时间。而且由于OP首先犯了错误,因此他可能没有很高的判断力。

– Pops
2012年8月15日在18:10

嗯...有趣...

–因果报应
2012年8月15日在21:30

@KarmicDice鉴于您是此处的新手,请注意,此处的向下投票通常用于表示不同意。因此,如果您对收到的反对票感到困惑,那就不要。它们很可能只是表明“我不同意您的建议”。

–巴特
2012年8月15日在21:36

是的,我已经收集了!我的编码自我被保留在meta :)

–因果报应
2012年8月15日在21:40

#14 楼

我见过一次完全有效的编辑,只有一票否决票,因此,您提出的问题的反面也是同一问题的一部分-我们该怎么做才能阻止良好的编辑被拒绝?

如果您可以找到接受不良编辑的示例,这是有理由认为也有拒绝(相同数量的?)良好编辑的原因,因此这些编辑已脱离了我们的权限。数据向导之一可以拉取统计信息吗?对我来说,接受或拒绝编辑的百分比是多少?

在我看来,您提出的问题与问题或答案有关的问题更加令人震惊。 IMO会随着时间的流逝自动更正标签,这些标签对于有经验的用户来说是更可见的(因为我们是在自己的问题上使用它们)。一个问题可能会被不好的编辑默默地污染(或因缺少被拒绝的好的编辑而苦恼),并一直保持下去,直到有人“知道”为止。

我有两个建议,两个都涉及使用已经存在的系统来确保在做出决定之前要对一组合格的眼睛进行编辑:

建议的解决方案1(限制性最强)仅显示对问题的正文编辑或用户至少拥有青铜徽章的答案。这是有道理的-在我收到给定标签的100张赞成票之前,我可以准确地评估对该主题的问题或答案的编辑质量的可能性是多少?

我们可以继续向具有审阅权限的任何人显示标签Wiki编辑和问题标签更改,但我认为应该对那些有能力对其进行评估的人员进行-content-编辑的审查。 (限制较少),如果其中至少一项来自给定标签中带有青铜色徽章的用户,则需要2次拒绝/接受投票;或者,来自所有未标记用户的4次拒绝/接受投票。

同样,我们可以继续向具有审阅权限的任何人显示标签Wiki编辑和问题标签更改,但是我们需要更多的“不合格”投票或“受支持的合格”投票来更改正文或问题或答案。

评论


之前我曾问过有关拒绝错误编辑的问题;他们大多被拒绝,因为有些人拒绝错误修复是因为他们“改变了含义”。那是另一个问题。我不喜欢你的建议;许多建议的编辑仅涉及语言和格式,因此不需要主题知识,并且较小的标签没有铜牌,因此在其中进行编辑将很困难(即使使用修复程序#1也无法实现)。

–吉尔斯'所以-不再是邪恶的'
2012年6月26日22:32



反对派让我像马蒂·麦克弗利(Marty McFly)那样淡出,但我坚持我的建议:你不能吃蛋糕也不能吃。要么进行少量编辑,在这种情况下,一些可疑的批准就没什么大不了的,或者我们需要(用您的话说)受过良好教育的审稿人。拥有受过良好教育的审阅者的最好方法是使用网站的现有机制,以确保他们受到明显的教育:)

–克里斯
2012年6月27日在1:42

但是您的答案并没有说明受过良好教育的评论者。有关特定编程语言的知识与有关如何在Stack Exchange上编辑帖子的知识不同。

–吉尔斯'所以-不再是邪恶的'
2012年6月27日在1:47

唯一可用的其他类型的专业知识是英语,在这种情况下,我们应该将SE编辑评论的全部负担分配给作家的1万多名用户!

–克里斯
2012年6月27日2:10

我喜欢您的第3段,但是我不喜欢您的建议,因为我认为这些建议并非在所有情况下都有效。但是,您遇到了硬币问题的另一面! :)

–ForceMagic
13年12月18日在7:54