Talk:Edit hints

Too much discussions

"Too much discussions" is a problem? Heck, I'd rather which some users would even now and then use the discussion page before editing full steam a controversial article. I'd cede, that there are some cases where people abuse a talk page as pseudo USENET thread. But there's the point, that not the article and how to enhance it is discussed, but the topic of the article. (E.g. en:Talk:Dark energy) And this is beyond automatic detection. --Pjacobi 08:25, 2005 Jan 4 (UTC)

First of all thanks for your comment :-) Well my point was: There are user (e.g. user NL in german wikipedia) who only say on talk pages I like this I like that but if you say to them: "Hey please look yourself into the topic and write in the article." they refuse to do so. Okay this NL is a troll, but there are especially new users who simply don't know it better and make lots of suggestions on talk pages instead of writing them by themselves (I have often written to them personally that they can edit the articles by themselves if they have a suggestion, but this was always afterwards and most time they forgotten where they had written them, so a direct notice helps there much better). This was my point and nothing more. ;-) An of course a discussion which doesn't come to an end (meaning edit in the corresponding article) is always a bad discussion, IMHO. Arnomane 11:32, 4 Jan 2005 (UTC)

I think sometimes everyone of us runs into a heated discussion and a short friendly reminder will help a little bit to return to the articles. ;-) The opposite problem, that someone doesn't want a discussion (for example in edit wars) is also adressed in the next idea about "edit wars" (those both ideas need to be tweaked good enough so that they don't collide). Of course this system can't notice if the discussion is on or off topic but this is also a strong point since none can complain about censorship. Perhapes it would be better that only the last 50 (overall) edits of a user will be taken in account (because if you have a rather long personal edit history and then run into discussions it will take long until you will get this message). Arnomane 13:23, 4 Jan 2005 (UTC)

Question about vote [moved here from article]

Simple question: Why should there be a voting instead of a discussion? I think, we can implement some of the ideas if there are enough reasons for them and others we can keep in mind or take aside if there are enough reasons against them. I will not vote for this complete stuff so I like the ideas for a polite message in the case of stubs and too much meta information but I don´t like the idea of automatically closing the chance to edit an article or a talk page by excluding IP-Users so they may be the best users we´ll have in future and it´s not the best idea to close the door for them. Same I don´t like the way to handle people only working on discussion an metasites so we can exclude some of the best reviewers in the german Wikipedia like de:Benutzer:Cornischong who normally works at the lx-WP and in de-WP he´s only discussing on a very high quality level. In the case of Edit Wars I don´t think that an automatically induced dicussion will work. Greeting from Berlin -- Necrophorus 16:32, 4 Jan 2005 (UTC)

I see your point but (out of personal knowlegde with other things) there are many people out there that find an idea good but don't want to write a comment. So for those that simply want to say yes or no can do so and the others can write to the talk pages or the article itself if they have some suggestions comments or whatever. That way you get as much as possible visible reaction. The problem with people working a lot on meta pages is a problem I also see, so my suggestion is, that namespaces as "wikipedia:" (which is used for such things) don't get counted. Arnomane 16:57, 4 Jan 2005 (UTC)

The general problem with votes is that they often are counted without looking at the discussion. This is a problem which has to be seen at the same or higher problematic level as all of the problems you collected. A Voting normally stops any discussion because all voting people think that there votes will be the part of their talk that really counts or be counted. For that reason I think that a voting like that one on this site is the last thing to be done after a discussion and I don´t see any reason to take part in a talk where a voting will be placed instead of the discussion. Just my 2 cents (and as long as the voting is placed my last) -- Necrophorus 17:11, 4 Jan 2005 (UTC)

Hm I personally didn't participate much in votings, since I (as you) want to express my differential views in detail and of course your comments here are much more valuable than a simple yes or no. I hope my small notice above the vote makes it now clear what it is like. (No formal vote but simply something for lazybones to get more feedback, which we wouldn't get otherwise). I wasn't aware of such drawbacks of voting.
And because of our personal discussion at the conference in Berlin I noticed, that it is absolutely necessary that a community can decide by itself which rules in which sharpness they want and which not. So hence my idea in section implementation that it needs to be plugin like done with individual tweaking possibilities. Greetings, Arnomane 18:04, 4 Jan 2005 (UTC)

Overall, I think it is a really good idea. However one can argue whether individual points should remain; prsonally I don't quite like "Reduction of meta info" or "Too much discussions" - if the latter is to be implemented, I think it should be fairly generous, allowing at least 75% talk edits before the warning applies. Conserning the former, I've seen a number of very informative (of a sort) stubs containing almost nothing but a info table. (But of course, I often use wp to check a few specific data on something, and seldom look for the whole history of the subject:) One more thing: If this is to be implemented wikimediawide, each project (language) should be able to set their own threshholds. \Mike 08:55, 2005 Jan 7 (UTC)

Yes I was also thinking of a relatively high level in the range of above 75% talk edits to all edits before you get the "don't talk that much"-warning. I think practical values need to be investigated by some statsictical analysis and of course after doing that some trial and error. ;-) I think it would also be a godd point in counting only the last 50 overall edits (to the affected namespaces) of this user. First it reacts more directly (if users have a rather long edit list) to a change of edit behavior and second it doesn't consume so much computing time (generating the edit list of a user takes fairly long) which is a strong point on our servers. So this would mean that in worst case after 13 subsequent edits (with 75% threshhold) on articles you don't get the message if you write again to a talk page. Well in respect on reducing stubs: Users that know how to write a good stub will surely save it despite the warning (but hopefully keep in mind because of this message that they should enhance it later by themselves). The biggest point why we have quite a lot of stubs are new users that don't know it better and so with this message you take them by the hand and give them help (I think this is much less frustrating than seeing as a completly new user your new article after some hours on vote for deletion or with a big stub hint on top). Yes adding control over this feature to the configuration possibilities of language community admins would be a good idea (my main concern was only that this is not that easy to implement as instead making only a configuration switch to the config file somewhere in the /etc directory on the server). Arnomane 10:27, 7 Jan 2005 (UTC)

chaining of users

Why not to chain the users to their computers until they write some predefined number of articles? (And, of course, the prohibition of discussions will also help.)
--DIG 07:52, 8 Jan 2005 (UTC)

I'm sorry I don't know exactly what you mean. Is this a positive or negative suggestion? I guess it is a sarcastic one. Please consider that english is not my mother language and that I'm interested in constructive critics. Arnomane 13:18, 8 Jan 2005 (UTC)

A really bad idea

I am so totally opposed to this that if it is adopted, I will probably quit being actively involved in Wikipedia.

1. I find the proposed messages condescending. I don't want an algorithm telling me that my edit is probably no good.
2. More importantly though, every one of these proposals has serious drawbacks (which I've documented in the relevant sections).

I would be entirely in favor of algorithms like this flagging articles (or even users) for possible attention. I am entirely opposed to an algorithmically-based approach admonishing users or, worse yet, blocking user actions.

We strongly limit what bots can do, assuming (correctly) that humans are better at this than bots. This proposed policy threatens to reverse that hierarchy.

I rarely monitor meta, so if someone has a response to this that they wish me to read, please ping me on my English-language talk page so that I know to come read your response here. -- Jmabel 20:05, 7 Jan 2005 (UTC)

Hey, hey calm down. My proposal doesn't make a valuation by content (very important point) and doesn't block a single users edit if the user really want to apply it. So why would you want to leave Wikipedia out a a warning that (I asume) you rarely would get? Where do I suggest blocking of users? Okay there is one proposal, but this could also be changed to a simple warning. I wanted to document the possibilities of this idea. If and how this idea gets applied can be decided afterwards. And of course if a community says no to that entirely or to specfic parts they can do so. This was also a strong concern of mine. So if those rules (or better hints) are going to be implemented there is still no problem. You can decide by vote within you community. And of course I know that there are problems where this idea doesn't work that right. But those cases are hopefully (after some tweaking) very seldom and because of this they are only hints. And of course a bot makes an edit but this does only suggest something to people. They still can decide by themselves. (And I admit sometimes a short friendly reminder would also help me sometimes if I'm within a flame on a talk page with some vandals ;-) ) So this is completely different from a bot. But do you aggree that there are certain problems within our community that get too much attention at the moment? There are some nice angels in wikipedia that teach others and at some point they get upset (simply out of beeing overworked with that) and this was also thought as a help to them. How do you want to solve these problems instead? If you are strongly opposed to something I would like to hear: What are the alternatives? Arnomane 10:40, 8 Jan 2005 (UTC)

Flag yes, talk no

I have no doubt that all these measures are technically possible. In fact, most are rather trivial. The question is not whether we can do all this, but whether we should. And I think the answer is an absolute, categorical no.

Algorithms cannot be held accountable. Algorithms cannot be reasoned with. Algorithms cannot detect exceptions. An algorithm may be correct 9 out of 10 times, and fail so gloriously in the 10th that you'd wish it had never run in the first place. And that's just for regular algorithms — what you're proposing are heuristics, heuristics that have to be tuned by humans. Arguments for time-saving can be easily dispensed with: we have no shortage of people on Wikipedia. If you don't like protecting articles, don't become an admin. If you don't like it that people talk, then edit yourself. If edit wars annoy you, then don't participate in them, or don't look at them. Someone else will do it. Eventually. Impatience is no excuse for cutting out the human element entirely.

I would accept criticism on any edit from any human. I will not accept it from an algorithm that was once set in motion by someone who didn't even have the common courtesy to make themselves explicitly accountable for all the decisions it makes. "You talk too much"? Since when was that a crime, and how on earth would an algorithm know when editing was more appropriate? Would an algorithm have flagged me for the arguments I'm posting here?

And if you take accountability into account (:-) this really doesn't save any time at all. The question becomes whether you want to spend time on these "administrative trivia" yourself, or whether you are tuning and explaining your mindless algorithms to people. I would strongly advise administrators to do the former. It is not acceptable to defer personal responsibility over these matters by giving them to an algorithm, claiming that it is based on "universally fair" or "sensible" criteria somehow. I don't buy that. Formal criteria are not necessarily sensible or just.

It would be acceptable to have algorithms of this kind flag articles. In fact, if the algorithm only flags, you can let it check for whatever you want. Go crazy. Come up with all sorts of criteria for possibly problematic articles. You don't even have to put it up for a vote, as far as I'm concerned. But always leave the final responsibility of a decision to humans, even a decision to issue "friendly advice". You can make that as easy as you like: a simple push of the button to paste a standard message, even. As long as it's signed. Why would we implicitly distrust humans whose only "crime" is that we don't know who they are, but implicitly trust algorithms whose only claim is that we think they will judge correctly?

Then there's the matter of "crying wolf". If the algorithm makes a mistake (read: if the humans writing it don't understand correctly what it will do in all cases) it will make that mistake over and over again given the same circumstances. Result: a lot of potential newcomers antagonized and driven away. Regular users who feel confident in ignoring the warnings, because they're made by a stupid automated system anyway. Will there be such mistakes? Oh, you'd better believe it.

Aside from the moral matters: if you think these measures will make things a lot easier for us, think again. Sneaky trolls and vandals will be encouraged to try a game of "slip under the algorithmic radar". You'll find yourself spend less time on obvious things, but far more on nonobvious things. Wikipedia will become something you can hack. And, of course, the most effective way of annoying people will be to submit things that the algorithms don't like. If you get a warning, there's a good chance people will not like your edit, so go ahead and put it in! It's even better if you can defend it and thereby cast doubt on the whole automated system: crying wolf again.

If you want to implement all of this, go ahead. If you do this, you'll have to implement a "flag only" solution anyway, if only to test. My advice would be to never let it get beyond a "flag only" solution. You could integrate it with "recent changes", for example. I think such a system would be a valuable addition. If that's the case, none of my arguments above apply. But if you really think an algorithm should be talking to users... then please refute all of them if you want my vote. JRM 21:18, 7 Jan 2005 (UTC)

I have never said that this approach is perfect and I would be very happy if it works in 9 of 10 cases (it is my aim to have a realiability in this range). This is a statistical solution. And because of this these are only hints (the one case where it is not could also be changed, see above answer). And most users will very seldom get those hints and if you get a hint where you think it is wrong you still can submit it. And statistical said: If 9 right detections of problems gets solved by that user (more information in stubs for example) and only one false detection (for example a short disambiguation page) this small additional work of a second mouse click is it more than worth. And of course in respect to the point "talking too much". There are sometimes silly flamewars on talk pages and I myself already have participated in those and I think if I had got a nice message that says to me "Hey calm down, do some article work it is more worth." I would have written more articles that time. I don't say to people don't talk but there is an ideal point between work and talk and this is simply an advice nothing more cause i still can submit what I have written. It is only a further mouse click away. So since you simply can ignore those messages I don't think that there is a high pressure on vandals to "hack" this system. They still can do what they want but they get a message which is out af a wide consensus of the community (and because of that it needs to be changeable by community how and if they want to use it). And lets say: If 3 of 10 vandals get discurraged by this message and either change their behavior or leave wikipedia it works better than expected. The second point: if someone deliberately tries to overcome these hints (you say slipping under the detection radar) this is also perfect. In those cases I use this image: Where is the difference between a zombi that looks and acts like a human beeing and a real human beeing? There is no difference between them. So back to our clever vandals: If a vandal changes his behavior regardless why, the solution works. Hm your flag only solution is definitely interesting. So there would be three escalation levels that needed to be taken into account at programming for most flexibility: Flag, direct hint, blocking. If they get used and if only one level or two or all levels get used has absolutely to be entirely upon the decission of a specific community. Arnomane 11:17, 8 Jan 2005 (UTC)

bloat and nagware (answer to comments on vote)

I don't see the point how this will cause more bloat to MediaWiki. See my implementational suggestions. If a community doesn't want it everything is like it is now and so MediaWiki can't be slowed down in that case (if this is your main concern). And of course MediaWiki is a full featured wiki. If you don't like its "bloat" (as e.g. the possibility to write in hieroglyphs or in right to left languages as arabic) I think MediaWiki is not the right software for you. There are other lightweight wikis out there as UseModWiki that are perfect for its specific task. Okay you are an author of Wikipedia and you are afraid that the interface of MediaWiki gets more complicated but because of the individual reactions of this system that don't stay the user in the way if there is no problem it reduces the impact to the users to the absolute minimum. I also don't think that MediaWiki would turned by this into nagware. It is my main concern that this is done very carefully so that a user doesn't get wrong messages. And of course. The large majority of wikipedians will very very seldom get such a message cause they aleready act according to them (better said: I created the rules according to the behavior of the majority of wikipedians). So in most cases only a small minority of users will get them. And of course prevention is better than reparing (or starting a flamewar afterwards because of a users edit). And sometimes I think a small polite hint will help everyone to calm down in a heated flamewar in discussions. ;-) Arnomane 13:18, 8 Jan 2005 (UTC)

It is the very definition of nagware, software that bothers the user rather than just doing what it's supposed to do. If you implement this, a lot of people are going to stop contributing. --Ben Brockert < 19:46, 8 Jan 2005 (UTC)

I really don't see your point. If this is getting implemented the language communities still can decide by themselves wether they want this or not. It is very important to me that it doesn't cause "extra bloat" or something similar as "nagware" if you don't want it. If the english speaking community is so strongly opposed to it they can decide by themselves that they don't want to use it and so nobody will leave Wikipedia because of this possibility of strict binding to the will of the large majority of a specific community. And of course I don't want to be faced with such sayings that people will leave Wikipedia because of my idea as it would be the worst thing. I really don't see how this can be possible if the communities decide. I saw a problem so I tried to find a solution that kind that everyone can be happy with. But I fear regardless how well thought a solution to some certain problems is there will everytime be strong opponents. But do you agree that there are certain problems within our community that need a solution? If you say yes: What are your ideas in solving them? So I would like to hear the alternatives to this approach. Arnomane 20:11, 8 Jan 2005 (UTC)

Disagreement

Flags or something like "recent changes" applied to this idea could be OK. Anything more is not OK.

I think some of these issues that the algorithms are intended to solve are either not problems or don't have a consensus that they are problems.

A prime example is "too much discussion". Sure, it's generally better to edit than JUST talk, but if someone makes suggestions or raises valid questions without ever editing an article, that person has still made valid contributions.

I also believe that voting shouldn't happen before a fleshed-out discussion. Besides the points raised earlier, any votes are for a proposal at a specific point in time. The discussion could change the proposal, making the votes ambiguous at best. 63.19.156.93 16:32, 8 Jan 2005 (UTC) AKA Maurreen on English Wikipedia

Well the ideas are simply everything what came into my mind what could be done. And hence if one rule isn't according to a consensus of a (language) community this community wouldn't use that rule but only those ones that they agree on (and those also tweaked individually). I know this vote isn't ideal but my main concern at the beginning was that I don't get much feedback if people have no simple possibility to say what they think (out of my previous experience whith this idea. When I talk directly to serveral people they said that they find it quite nice but they hardly didn't make any comment about it on the mailing list, when I was proposing it there). Arnomane 18:51, 8 Jan 2005 (UTC)

Mentioned Problems = common sense?

I disagree, that considering some of the mentioned problems as a problem is common sense. At least I am not considering them that way. (I will put my signature here, so you can put your answers in between.) --Jorges 00:48, 9 Jan 2005 (UTC)

Stubs

I don't think stubs are generally not good. I always prefer a stub than no article at all. Of course it has to be a good stub but the quality is not defined be the length.

There are constant flames because of this topic. But you can agree that the same article with more information is better than the same article as stub. And my solution does exactly try to reach this: Encourage the people to write a little bit more information is the focus not prevention of new articles. At the moment there exist two different views: radical deleting and keep everything. This will constantly go on and will of course annoy much more new users than this idea. At the moment many new stubs are getting the stub template after some hours, the user gets some rant on his userpage and the article is in worst case on vote for deletion. So my approach will definitely reduce frustration and thus help to keep new users. I think I have written down these points in my proposal quite directly. Arnomane 12:35, 9 Jan 2005 (UTC)

Meta info

Meta info is an info, too. So I also prefer meta info than no info at all. Some information is even better to put in in tables than in phrases to find it better, like basic facts of a city.

The same as above aplies here IMHO. The focus is not prevetion of ne articles but better articles from the same person from the beginning on. Arnomane 12:35, 9 Jan 2005 (UTC)

Too many discussions

Like the first commentator I think you can't generalize that much discussion on an article or by a Wikipedian is bad. Some controversial article needs much discussion, some Wikipedian is a very good reviewer.

There is an ideal point between discussion and work. It's all a question of the level above which you get the message. If someone makes only talk page edits he certainly could deserve a short friendly advice that he can do this also by himself. (this is a little bit related to your automatic "referrer hint" in German Wikipedia I appreciate very much and where I could not understand the rant of people that did do nothing.) Arnomane 12:35, 9 Jan 2005 (UTC)

Regarding the other points:

• Edit wars are really a problem, but people involved in an edit war fairly notice that their opinion seems to be "controversial". If not there would be no edit war. So that message wouldn't give them any new information.
• Slashdot effect: Many anonymous edits can also be constructive, i.e. at a breaking news much information has to be collected in a short time. So this technical solution could also cause harm.

  But I have watched several times edit wars in (German) Wikipedia. There where some edit wars with new users with lack of experience and others that simple needed a friendly reminder (of some person). This approach will not radical reduce the number of edit wars but I'm sure it would help at least a little bit. It is also very important to detect an edit war early so that the feelings aren't on a very high agressive level. And of course with regard to this hint about edit wars you could also imagine the use of the "flag-only" level (see implementation section), where you get a flag in your watchlist or recent changes that there seems to be an edit war. And this could help also a little bit I think. With regard to the slashdot effect: You are sometimes right. I think it must be investigated deeper how slashdotted articles evolve (but I again think it is all a matter of tweaking until you reach a point where you block only a small percentage of good edits with respect to the bad edits, and again you could make here a softer level as only a hint, so this doesn't touch the key point of my idea). Because of this uncertainity and the necessarity that the communities have to decide by themselves I stressed the point of configurability and the plugin approach quite a lot. Arnomane 12:35, 9 Jan 2005 (UTC)

The quadration of the circle

Well now I know that the word "rule" is a red hering for many people out there and I fear if they read this word many stop thinking and simply say no to everything regardless how well thought it is. :-( I simply didn't foresee this. As Nichtich has mentioned it already in the poll: "do not name it edit rules but edit hints" because they are from the very beginnings on only hints nothing more. I used the word "rule" in a very formal mathematical way not in any way as a social rule how people have to behave like a law (english isn't my mother language).

Well I have foreseen almost all reactions (as you can see in the proposal and my answers on talk page) but three not: The problem with the word vote, the one with the word rule and Jmabels threat that he will leave Wikipedia if this gets realised (what made me really angry especially his writing on the "Village Pump" proposal page in english Wikipedia, cause I think this is just unfair and causes unnecessary bad blood). I tried to overcome these three problems with beeing very polite and friendly (I never lost a single word about my anger until now) and with detailed rationals and clarifications on talk page and in the article itself and I still hope that I can manage to overcome them.

I had put quite some energy into this idea before I was writing it down here because I hoped that I can avoid any missunderstandings and flames if I try to foresee every kind of reactions and try to design a solution that way (that the power how and if they want to use it is still within the communities after the implementation and so forth). It was also from the beginnings on a try to find a nice third solution between the two fractions: The "delete-all-rubbish"-people and the "keep-everything"-people that are constantly flaming against each other and since none of this two groups will ever leave their point this leads to nothing but bad feelings and in the end to an unavoidable fork if this doesn't get solved. It is my main concern from the first beginnings of this idea that all people can feel comfortable with it. It started all with a post of mine at the german wikipedia mailing list some months ago, cause I was fed up with a flame war about stubs (delete or not delete) and wanted to have a solution that everyone can accept (but doesn't see this idea as perfect solution but as best possible one). I'm convinced that any other solution than a tutorial/hint and prevention based one (like this) that doesn't give up the open culture will fail and that my proposal is one of the best possible solutions to that problem within our community (it is important to stress the point best possible instead of perfect because perfect solutions only exist for a tiny fraction of people). In short words: I tried the quadration of the circle. Arnomane 12:35, 9 Jan 2005 (UTC)

Why are his comments on the pump unfair? It is a place for just that sort of discussion. (The discussion in question is here, for those looking.) He points out that it is a contentious proposal. You have probably gotten some views on the proposal that you would not have if he had not posted. --Ben Brockert < 21:44, 9 Jan 2005 (UTC)

Alternatives

First, I have to say that my German is very bad, so I appreciate that you have done this proposal and discussion in English, Arnomane. However, the first ten votes, and the only pro votes on the policy, are all users of the de: wikipedia. Not a single member from any of the other dozens of wikipedias has supported the proposal. To me this implies to me that it is de: policy that is lacking, not the MediaWiki software. Here I will outline some of the processes on en: that are working to solve the problems that you talk about in your proposal, as well as some more issues I see with the proposal.

"Reduction of Stubs"

In Wikipedia it is common sense, that stubs aren't that good, but there is no common sense (but a heated discussion) if those short articles should be radical deleted or simply kept until someone wants to enhance them.

On en: there is currently a very large vote on expanding the candidates for speedy deletion; that's the articles that can be deleted by administrators without first getting consensus on votes for deletion. The vote is accomplishing two things: one, it is setting new policy on what can be deleted; and two, it is proving whether or not it is "common sense" that "stubs aren't that good". Further, there is a very large ongoing effort to categorise all of the stubs, to make it easier for people to find stubs that they would be interested in editing.

If an (newly created) article has less than a certain amount of human readable text (counting only sentences, not meta info as tables), e.g. less than three sentences (or alternatively maybe less than 500 characters in sentences)

You're setting absolute definitions, which is always bad. Community consensus on what is a stub varies both by wikipedia and by time. What is considered a short article on the Esperanto wikipedia might be a long article on the Vulcan wikipedia; what is not a stub today may be thought of as a stub in two months. By binding the definition of what is a stub into the software, you interfere with the evolution of the definition.

"Reduction of meta info"

Recently articles are getting more and more meta info as boxes, tables ore whatever. This problem is also a constantly controversal point, which is especially annoying in stub articles with lots of meta info but no sentences.

If it's a controversial point, you should definitely not be trying to win the argument by having your opinion coded into the software. "Meta info" sometimes makes for very good stubs, such as having a template with full taxonomic information and a photo on an animal article.

There was a joke template, en:Template:Toomanyboxes. It was deleted, but can be seen at en:Wikipedia:The All-New Bad Jokes and Deleted Nonsense Comedy Hour! (Copyright 1972)#Template:Toomanyboxes. Perhaps you could create a category for articles that consist of only "meta info", so that other editors can easily find and fix them. Or generate reports on such articles from an offline version of the database, as happens a lot on en:, see en:User:Topbanana/Reports.

"Slashdot effect (or for Germans: Heise-DDOS)"

At the moment this problem gets "solved" by temporarily protecting this article if the (anonymous) vandalism gets to strong which is not that good, since the "normal" authors can't edit the article any longer.

If an article has a very fast workflow (let's say more than 5 edits per hour) the software protects this article automatically against anonymous edits until the edits per hour go under a certain threshhold.

Your solution is much worse than the current solution. If the edits are positive, the article won't be protected in the current system, whereas your approach would lock the article even if there were no negative edits.

It would also create a feedback loop. The article would be edited 5 times in an hour, and would then be locked. It would have no edits for the next hour, so it would be automatically unlocked. If the page is still up on /. (or wherever) it would then get five more edits in five minutes after being unlocked, and get re-locked. This would continue as long as the article was listed.

It would make Wikipedia look bad. It would give the appearance of unreliability. Some people on the linking forum would be able to edit the article, and others would (seemingly randomly) not be able to. They would post this, and breed general dissatisfaction amongst those who were excluded.

Further, it would create a fourth class of article protection, "protection from anonymous edits". We have enough classes of protection as it is.

"To much discussions"

This can't work at all. There are "meta editors", people who do very little work on articles, but who still have important and valid contributions to Wikipedia. You have no way of telling if the person is ranting and flaming or if they are working on policy matters and helping new people on talk pages. Plus, the database hit for the proposal would be immense.

"Edit wars"

If there is a topic in question and users disagree about certain views and/or what should be written in this article about that topic they often revert the version of the other person and after some hours the version history has reached new horizons where no article has gone before and the authors are full of adrenalin and maybe don't want to discuss with each other to find a solution.

On en: we have a 3 revert rule, aka 3RR, which means that any user who reverts an article 3 times in a 24 hour period can be temporarily blocked from editing. Temporarily protecting the article is also done. Revert wars rarely last for long. Your 5 reverts per hour threshhold is completely irrelevant for en:, and would very rarely be reached. Notifying the user that they're engaged in a revert war wold be pointless. I don't think any editor has ever, in the history of wikipedia, been unaware that they were engaged in a revert war.

Conclusion

I hope you can better understand why you are seeing so much resistance from editors not on de:wikipedia. There are already solutions for these problems, and they work fairly well. When they don't work, people rewrite the policy, not the software.

A question I haven't seen asked is this: are you a developer of the MediaWiki software? Are you willing to make all of these (very large) changes to the software? If you aren't, have you found any developers who are willing to make the changes for you? It will require a great deal of work, and developer time is much more valuable than editor time. I've spent more than an hour writing this rebuttal, that I could have spent improving the encyclopedia, but that is nothing compared to the amount of work needed to implement these changes. --Ben Brockert < 23:13, 9 Jan 2005 (UTC)

Thank you very much for your detailed response. I appreciate it that you took the time to answer that detailed to an idea you aren't convinced of. Well let me say at first some words about the policy in de-Wikipedia:

• There are some very strict policies: A strict one is our image and copyright policy (only free images according to the definitions of freedom within the GFDL), the second important policy is: There is no voting in de-wikipedia but only a so called Meinungsbild ("image of opinions") (and of course saying "yes" or "no" in Latin ;-) ). For me this is a different term for the same thing but not for many others in de-Wikipedia (many people stressed the point that this can't be a real vote since only a small group of interested people will vote because of the problem of communication and so forth).
• More wider policies: Flame articles (aka: no NPOV), stub articles with wrong written titles, substubs (some less bytes but no real text and keyboard tests like "kljdkedlsddk") can be deleted by an admin without the need of a debate, but everyone can afterwards open a debate wether this was right or not. Copyright infringement, stubs with less information, articles of "no relevance" (whatever this means) need at first to be debated on "Löschkandidaten" (vote for deletion).
• Blocking: During an edit war you get at first a warning on the article discussion page and depending on the history it gets protected inmediately or after some time but there is no sharp rule. Vandals and flamers get at first a personal warning and if this doesn'thelp there is a so called "Vermittlungsausschuss" (mediation) of all involved persons and if this still doesn't help a temporary blocking and only after a very long time a debate with "Meinungsbild" and then exclusion of this person. Anonymous IP's can be blocked without much asking (ideally some short info in the IRC-Channel).

I personally think that it is not our policy that is lacking. It is working in my eyes as good as possible. You can't avoid all the rant, senseless debates and hard "cleaning"-work with more policies. (the de-Wikipedia tried to to it). I think the only negative answers of the english community are mostly due to my wording and Jmabels words. The reason why I (almost) only got positive answers from de-Wikipedia is simple: I have proposed this already on our mailing list and there are some strong opponents that simply refuse to say anything here (I tried to convince them personally to speak up here). Then there is another (relatively large, according to comments on IRC) group that has read my idea here but simply is quiet because they think that nonetheless they like it it will never happen (out of inner Wikipedia-politics). Only those who liked and believed in its realisation commented on this page to support it.

So back to the topic:

• One of your points is that I would set hardcoded absolute settings with this idea in MediaWiki but this exactly is not what I want. I don't want to hardcode those ideas. They need to be changed by the specific communities. So the numbers I was given here are really not relevant to my idea. They are only here to give you an impresssion of how it can be but not must be. So my idea won't hardcode any kind of policy to MediaWiki. Every community can decide which detailed idea they want to use and thus every community can decide by internal vote to change their definitions (the setting changes get done by their language community admins). So if Esperanto Wikipedia has another definition of what is to short and what not than English or German Wikipedia they can make the stub settings according to that what they consider as a stub. And since this is a statistical solution (length and importance of an article are statistical linear related but not strict linear related) I stressed the point that it can only be a hint in this case so no stub-edit will be really blocked.
• With regard to the slashdot effect: Well I think beeing able to edit an article by a still relatively lage userbase is much better than the alternative to block all users from editing. The "open-and-closed"-effect may happen (and probably can also be reduced with clever settings) but it is better than blocking all people IMHO (if you make it transparent why it happens).
• With regard to the last two hints. Yes they will definitely cause quite some load on the servers if the software doesn't get dramatically optimised within this area (which is a very hard thing). So I don't expect (from the beginnings on) that these two rules will be used that fast in Wikipedia (but they are maybe interesting for others). But again I wanted to illustrate the thinkable possibilities and maybe some other clever person has an idea for a similar "rule" which doesn't cause heavy database load.

So in conclusion policies have a huge problem: They only work afterwards. My ideas will directly interact with the user and give advice if there is a problem but on the other hand won't block the edit, so the Wikipedia is still very open (and for most people there wouldn't be any difference) if it uses my idea. The other problem especially with regard to new users: An friendly direct stub hint is much more better than creating some stubs and then some hours later seeing them on vote for deletion. So my idea will prevent new users from beeing frustrated and thus will help keeping them. And of course if the same person decides to write a little bit more and improves from the beginning on short articles there is less work for others as categorizing stubs, saying the users that they can also write a little bit more or in worst case deleton of stubs. So prevention of negative side effects and so a more positive climate within wikipedia is also a thing which can be reached by this idea but hardly by a policy (and I personally think that those hints are more wiki-like than a policy). So I hope that people don't say no to this idea because they don't like one of the "rules". Those hints will be highly configurable and no community looses its power. To your last question, no I'm no MediaWiki developer I have only some limited programming experience in Bash, Perl, Pascal and Fortran but I know which way an idea needs to be designed that it can be realized in software and I want to learn more coding. I know that I can't do this idea on my own yet, without help and so I fear the idea will be dead before ist started if I don't find some persons that want to do it with me together (and at the moment it doesn't look that good). Arnomane 15:28, 10 Jan 2005 (UTC)