我正在审查建议的修改,并决定尽管修改不正确,但该帖子仍有一些改进之处。因此,我单击“改善”并开始我的业务。
当我尝试提交编辑时,收到以下错误消息,告诉我该帖子是同时由建议者编辑的:

用户已经编辑了这篇文章的正文;您的编辑必须更具实质性才能覆盖当前的编辑。

稍​​后当我在标签Wiki上尝试时,我完全无益地表示“发生了错误”,并且再次无法执行任何操作但是取消并丢失了我的工作。
但是刷新页面后,我进入了建议的编辑页面,显示了建议的批准已批准,没有任何编辑痕迹。 (幸运的是,我将文本保存在了一边!)后来在标签Wiki上建议编辑,我被标记为已审查了建议,并带有“ edit”标记-否则就找不到我所谓的编辑的痕迹。
因此,如果改进建议的修改并同时获得批准,您会遇到以下情况:

没有链接到帖子;
如果返回,您将无法进行编辑;
如果按照指示重新加载页面,则会丢失您的编辑。

这里的错误是除非您采取额外的预防措施,否则当您将编辑内容复制粘贴到外部编辑器中时,您将丢失您的工作。
预期的行为
与正常的编辑冲突不同,对建议的编辑进行的编辑肯定是建议的编辑的衍生产品-因此,如果该修改被批准,然后提交了“改进的”版本,则该“改进”的编辑应应用于该帖子(复选框所指示的帮助状态不应影响任何事情。)
当两个不同的审阅者都选择改进建议的编辑时,冲突是不可避免的-应该根据编辑的大小来解决,这是正常现象。

评论

我认为建议的修改改进应该以与普通编辑相同的方式工作:1)它会检查其他人是否对帖子进行了改进并显示警告2),它将作为建议的修改的新编辑出现。
这就是为什么我总是复制输入任何内容的文本的原因。太多了,“登录。。糟糕,您又说了什么?”

我已经问了一个非常相似的问题(尽管不完全相同)...

我可以确认这仍然没有解决。我偶尔可以用自己的改进来覆盖批准的编辑,但是我经常会因为描述而陷入困境。也许是破损的“更彻底”的检查?从定义上来说,改进是更彻底的(错误#1),并且在同时进行改进的情况下,应该有一种检查(错误#2)和替代(错误#3)的方法。

+1。我自己才得到这个。警告用户已经编辑了这篇文章的正文;您的编辑必须更具实质性才能覆盖当前编辑。是在尝试提交我的修改时收到的(请注意,警告颇具误导性;这是因为最初建议的修改被批准,阻止了您提交改进内容,而不是其他修改或对该帖子进行进一步的修改)。理想的工作流程是,改进要覆盖您改善帖子所需的任何批准/拒绝。

这种情况在我身上也经常发生,如果经过审查的编辑本应被拒绝,甚至没有得到改善,那将更加令人沮丧。

有一个简单的解决方案,停止查看帖子。让网站所有者进行所有审核,直到他们修复审阅系统。就目前而言,它已经完全损坏了。

@Lundin:什么,就像主持人一样?不可能。

@GraceNote那么,有什么消息吗?已经6到8个月了,但错误仍然存​​在。

相关:允许手动覆盖编辑内容-但在改进建议的编辑内容时还存在其他问题,尤其是缺少在新标签页中打开帖子的简便方法,以及系统地将改进内容视为实质性低于建议的事实。

@ Shog9 6至8个月后,该错误仍然存​​在。你可以翻转一下吗?与其将对建议的编辑的改进不如对建议的实质性对待,而是对它们进行了更实质性的对待。

#1 楼

现在,在建议的编辑被批准之后的10分钟内,改进建议的编辑比批准的建议的编辑更具实质性。但是,如果2名审稿人在建议的编辑被批准后提交了改进,仍然可能会发生冲突-在这种情况下,我们将退回到标准的编辑冲突解决方案。在站点上。


编者注:自从提出此请求以来,当用户获得建议的编辑审阅任务时,现在有3分钟的独占时间。换句话说,在加载审阅任务后的前三分钟,不会向其他人显示相同的审阅任务,因此这种情况的发生频率应大大降低。仍然存在一些极端情况(例如,手动导航,从帖子而不是审阅队列访问建议的编辑,从建议的通知到自己的帖子等),但这很少见。


#2 楼

通常,当您在编辑并且其他人对同一帖子进行编辑时,您会看到一个漂亮的橙色框,表示该帖子已被编辑,并且可以刷新该帖子以查看更新的版本(如果您的编辑不是“更加重要”)。在此过程的这一点上,当他们的编辑获得批准时,帖子认为该内容已被编辑,不会再让我提交改进内容了(我不会像您声称的那样丢失我的编辑内容)。这简直是​​愚蠢的,因为我已经知道他们做了什么改进。感谢您告诉我,无知的人刚刚批准了我将要标记为无用的编辑,现在为什么要阻止我的编辑被提交?
我刚遇到的我的具体案例是在此帖子上,该帖子仅供用户使用建议对标题进行编辑。这不是一个很好的编辑,并且绝对应被拒绝为次要的,因为显然在该职位中还有大量其他内容需要修复。因此,我完成了自己的改进并尝试提交,但仍然看到橙色框。我进行的大规模修改几乎可以改变身体的所有内容,并且对标题的更多更改比我已经查看并确定需要改进的仅标题编辑要大得多,因此我单击了“改进”按钮。
TLDR;
当我改善帖子时,不应因为批准而继续禁止我继续编辑。如前所述,我已经看到了该编辑。我确切知道他们所做的更改,并且我想改进它。请停止增加不愉快的编辑带来的不便。

评论


从某种意义上说,编辑仍然位于浏览器窗口中,因此不会丢失。但是从某种意义上来说,它已经失去了,没有复制粘贴就无法提交。

–吉尔斯'所以-不再是邪恶的'
2012年11月20日上午8:08

我当前的解决方法:<!-\ nthis \ nedit \ nis \ nmore \ nsubstantiative \ ndarn \ nit!\ n->

– Ry-
13年3月31日在1:16



#3 楼

我在当前实施中看到的主要问题是,它不鼓励审阅者改善帖子。这是因为在您花费时间改进帖子时,其他审稿人很可能会接受或拒绝该帖子,尤其是在诸如SO等具有多个并发审稿人的网站上。失去工作或增加负担的形式的“惩罚”使评论者不得不停止改进,而是直接接受或拒绝建议的编辑。游戏化进一步增加了不改善的压力,游戏化根据评论者做出的评论数量向他们颁发徽章。最后,审稿人倾向于拒绝而不是改进,这可能会使建议编辑的人从一开始就不愿进行编辑。我不认为这不是我们想要的。

解决方案将尽可能轻松地成功解决“接受/拒绝同时改善”冲突,而不是“惩罚”审阅者以改进。在大多数情况下,分辨率可以/应该是自动的,如其他人所建议的那样。

评论


这是有关审查建议的编辑的最令人沮丧的事情。自从我选择改善几乎所有有效的编辑内容以来,我已经连续四次这样做了。

–男士
2013年12月25日下午6:03

#4 楼

同时进行编辑时,堆栈溢出应创建自动合并功能。这意味着,如果编辑不同的行,则可以将它们合并到新修订版中。如果对相同的行进行了编辑,则系统可以尝试识别是否对同一行中的不同句子进行了编辑,并在这种情况下进行合并。

我的意思是,我们希望对源代码所做的更改通常能够干净地合并,为什么不这样做呢?

如果发生冲突,则新屏幕应显示以前的编辑者以表单形式提交的内容(可以自动合并的部分)以及内容。您已经提出了建议,并给出了所有冲突位置的差异视图(类似于查看建议的修改内容)。

这意味着大多数冲突可以自动解决(也许会通知已合并造成的),即使是无法解决的冲突,也不会丢失任何工作。

评论


我们期望对源代码的更改通常可以干净地合并hm我大约十年前就放弃了这一期望-从那以后,我每隔一年或两年就重新发现自动合并不够可靠,无法自动运行

– gna
2012年9月9日上午10:30

主要讨论语义合并-这是源代码特有的问题。我提议对文本进行合并,由于重命名而导致的冲突不会导致“错误”。无论如何,我还建议无论如何都要通知您自动合并,因此我看不出问题出在哪里。

– ronalchn
2012年9月9日在11:22

什么是“线”?你是说一段吗?你是说一句话吗?对于基于行的源代码diff / merge而言,有意义的操作对于运行数百个字符的文本段落在遇到换行符之前可能没有任何意义。

–基督
13年3月16日在18:02

至少对于并发的“编辑”审阅,有这样一个功能:检查此审阅以及由此产生的历史记录。我的编辑包含完全相同的标记更改,并且系统正确地将我的更改与并发编辑合并。

– oberlies
2013年7月26日16:16



@tchrist,什么是“线”? ->一个字。

– Vi。
2014年11月30日,3:03

#5 楼

我已经多次遇到此问题(我当时想在此发布),尤其令人沮丧的是,它似乎是由于该帖子被批准而不是仅仅被编辑引起的,而且通常它不应该在全部。

实施用于检查的签入/锁定过程应该可以解决此问题,并鼓励进行更彻底的评论,而不是西方风格的评论中最快的枪支。

#6 楼

一个简单的解决方案是,如果2k +的编辑者进行了改进(我以为您必须2k才能获得改进的选择),那么只需对其进行编辑,覆盖已批准的建议编辑,就好像他们已经通过

仅当某人在建议的编辑被批准后编辑了帖子时,才会出现停止该过程的对话框(如果编辑者花了很多时间来完成该对话框,则可能会出现)进行编辑)。

#7 楼

堆栈交换应在帖子上创建锁。它应该只允许一个用户同时编辑同一条帖子。

一旦用户正在编辑一条帖子,则任何试图编辑同一帖子的其他用户都应收到该帖子的通知。已被其他用户锁定,当当前用户完成编辑后,您可以编辑帖子。

评论


我们基本上做到了。这里的问题是改进可以代替建议的编辑,但是如果建议的编辑同时获得批准,则改进的版本(否则将立即覆盖它)会替换改进的版本,从而完全删除它。

–本·布罗卡(Ben Brocka)
2012年10月19日,0:29

#8 楼

就个人而言,我认为无论如何都应允许您编辑自己的问题(因此它会覆盖所有其他编辑内容)。您的编辑应具有优先权。如果您认为您的问题需要编辑,那肯定是您的责任。对于您的情况,我认为应该将您的编辑通知其他人,然后必须等到完成后再检查您的编辑。

评论


是的,的确如此,但这是一种罕见的情况,值得单独提出一项功能要求,与此处无关。

–吉尔斯'所以-不再是邪恶的'
2012年9月9日17:53

#9 楼

是的,我同意在您进行了大量修改并收到警报后确实令人沮丧。

我建议每当有人编辑问题并且帖子已更新时,我们可以显示一个模式-带有消息的弹出窗口。


该帖子已经编辑,现在下面提供其内容。如果您仍然认为您的评论更有用,请提交您的编辑


。在弹出窗口中,我们还会显示当前编辑内容,如果用户在查看帖子后提交了自己的编辑,则应该获得优先权。

这样可以解决丢失已编辑内容的问题,并节省复制粘贴的步骤。

#10 楼

我同意animuson,所以我提出以下建议:


添加5-10分钟的宽限期。已发表评论的人可以投票,其他人不能投票。
因为在编辑已经有3个接受之后我们可以得到4个拒绝,所以我建议按以下方式更改接受/拒绝帖子的规则: br />

大多数人的最小差异需要为2(或在SO上可能为3)
一旦达到该阈值,就将其从评论队列中移除。


不显示导致进行审核的“编辑(1)”按钮。如果结果被接受,显示吗?


如果宽限期内的阈值发生更改,则建议的编辑审阅将重新添加到队列中。
主持人/ OP的投票具有约束力。在这种情况下,请勿使用宽限期。
改进使社区用户可以投票(就像以前一样)。我认为只有想改善帖子的人才能做到这一点,并且对机器人审阅者来说,改进编辑工作实在太多了。直到完成其他编辑。改进是一项其他编辑。



这样做的效果是:


您至少有10分钟的时间审查/改进帖子
有更多的人对有争议的编辑进行评论(建议的编辑队列几乎始终为空,因此听起来好像不是问题)
它允许OP(和♦)覆盖建议编辑评论的结果。

但是何时给建议者提供+2的代表?


我建议到达阈值后接受结果。
如果评论不再具有所需的阈值,则撤消信誉。


评论


我不明白你在开车。所有这些规则的意义是什么?这是一个简单的错误:现在,当您完成一项改进时,如果同时批准了该编辑,则系统地拒绝它。测试应该还原:系统地接受比建议更全面的改进。

–吉尔斯'所以-不再是邪恶的'
2013年12月13日在9:51