Wikipedia talk:Editnotice/Archive 1

Initial discussion
Initial discussion is at Village pump (technical)/Archive 46. -- John Broughton (♫♫) 22:54, 9 October 2008 (UTC)

Colours for editnotices
Should editnotices be transparent or have the "table of content colours"?

There are some old "editnotices" generated by the system from MediaWiki messages. Most of them are 100% wide and I think most of them are transparent. The brand new editnotice template for making editnotice message boxes is also transparent.

But almost all other 100% wide system messages use the "table of content colours". For instance MediaWiki:Sharedupload, MediaWiki:Sp-contributions-footer-anon and the box at the bottom of the page that lists the categories a page belongs to. And that is the default colours we use for the "other pages message boxes" ombox.

Here is a transparent box, generated by editnotice:



And here is a box with the table of content colours, generated by fmbox:

(Both examples above were substituted so they won't change in the future.)

I don't think I have a preference, other than that it would be nice if all editnotices used some standardised style so they are easy to recognise. Both styles are nice: It can be nice to have a unique style for the editnotices (transparent), but it can also be nice to have the editnotices use the same colours as the rest of the interface (TOC colours).

So, should editnotices be transparent or have the "table of content" colours?

--David Göthberg (talk) 03:41, 9 September 2008 (UTC)


 * I didn't have an opinion until now, but I studied editnotices and how they are used more today, and I must say I like transparency. Having only a frame around the message and not a different colouration makes it integrate better into the interface, instead of feeling like something pasted on it. I also like the fact that it is different from the other interface messages, because these are generally standard for the pages they are found in, while editnotices (with some namespace-wide exceptions) are unique. The set-up reminds me a little of how the watchlist is laid out now (which I really like): customisable options in a frame at the top, and standard links in a box at the bottom.
 * PS: Why was that shortcut added? WT is a pseudo-namespace now. Waltham, The Duke of 21:04, 12 September 2008 (UTC)


 * Waltham: Thanks for your colour opinion.
 * And regarding your question about the shortcut: I am not sure what you really wonder about the shortcut, since it is normal and tradition to make such shortcuts. But here's some explanation:
 * No, "WT" and "wt" is not a pseudo-namespace, it is still an "abbreviation that is automatically translated by the Wikipedia servers" to "Wikipedia talk:". You can check that by holding your mouse-pointer over the WT:EDITNOTICE link in the shourtcut box above or here in this sentence and see what URL your browser shows for it in its status bar. Although it doesn't matter much if it is a pseudo-namespace or an abbreviation. But perhaps you by "pseudo namespace" did mean "abbreviation"? (And yeah, the word "pseudo namespace" could just as well mean that. Naming is tricky...)
 * And the reason I added the shortcut was the usual one: Some days ago the signpost announced that the editnotice functionality now was available. But people had problems to find out how the editnotices work, as could be seen by the questions at the Village Pump. So when I had learnt more I made the Editnotice page and the shortcuts to go with that.
 * Oh, perhaps you are thinking of that most of the search functions and Wikipedia search plug-ins for web browsers now can handle both lower and upper-case? So the WP/WT:EDITNOTICE shortcuts are not that necessary when there already is a lower-case Editnotice page. Well, I actually was thinking of the shortcut before the page. And besides, there are some situations when the upper-case name is not automatically translated. And having the shortcut displayed here shows that this is the starting point to read up about editnotices, and prevents people from thinking the shortcut name is unused and point it somewhere else.
 * --David Göthberg (talk) 11:03, 13 September 2008 (UTC)


 * I know it is standard practice to add such shortcuts, but this one struck me as a little redundant, considering that it's new; I've seen similar shortcuts before, but they were older leftovers. In any case, you're right to have added it. After all, even if it's as long as the proper name, it has that shortcut-y feel that people are so much accustomed to and like using.
 * Thanks for the clarification on the terminology; there's so much to remember around here, and I don't deal much with the mechanics of namespaces. "Abbreviations" was indeed what I meant. And I'd much like to see the pseudo-namespace CAT converted into such an abbreviation, too.
 * And no, it didn't cross my mind that the shortcut would be translated. I do know a few translation tricks (if all of a title's words start with a capital letter one can find it by typing it all-lowercase etc.), but I'm not that good.
 * Anyway, thanks for the lesson. :-) Waltham, The Duke of 09:42, 14 September 2008 (UTC)

Slash style editnotices
I have done some thinking and experimenting regarding editnotices. I have figured out how we can make a much more user-friendly system. It will be easier to use for both admins and users, and it can supply several new functions that the current system doesn't have.

To explain the new system I have coded up a demo template at. Below is what it produces on this page. Try it on any other page to see the editnotice names for that page. (You can try it in the edit preview without saving, so you can try it on any kind of page.)

{{fmbox
 * type = editnotice
 * image = none
 * text =

Improved editnotice system
MediaWiki uses numbers and hyphens "-" in the editnotice names. This causes problems since in template programming we can not convert back to a slashed "/" page name from such a hyphenated name. These names are also hard for humans to handle.

But we can put code in the main "hyphen-style" editnotice for each namespace that in turn loads "slash-style" editnotices for a page. This gives us several nice possibilities:

1: We can load "user editnotices" from user space that the users can edit themselves. (We already do this, but we can improve it.)

2: We can make two different types of editnotices: One type that is only shown on the one page it was made for, and a page group type that is shown on its own page and all its subpages. The current hyphen-style editnotices are only of the page group type, they are always shown on the subpages too, which can be confusing.

3: We can automatically (at load time) add view links on top of the editnotices so it is easy to find them and edit them.

4: A slash-style editnotice can link back to its subject page since we can convert back and forth between a page name and its editnotice name using only template code. In fact, the loader can automatically show that link as an editnotice when editing the editnotice, thus it doesn't have to be in the editnotice's code.

All this might sound a bit tricky, but we can make it very user-friendly.

The sections below show what addresses the old and new type of editnotices have for this page and some related pages.

Hyphen style
This is the old system.

This namespace: MediaWiki:Editnotice- (talk)

This page: MediaWiki:Editnotice-- (talk)

Slash style, for admins
For most namespaces we probably should use editnotices that only can be edited by admins.

This namespace: MediaWiki:Editnotice/ (talk)

This page: MediaWiki:Editnotice// (talk)

For its page: MediaWiki:Editnotice// (talk)

Page group: MediaWiki:Editnotice-group// (talk)

Talk page group: MediaWiki:Editnotice-group// (talk)

Slash style, for users
For user space and perhaps template space we probably should use editnotices that can be edited by any user. Here the talkpage of an editnotice is the editnotice for the corresponding user talk page.

This page: /Editnotice

For its page: /Editnotice

Page group: /Editnotice-group

Talk page group: /Editnotice-group

More examples?
The text and links this box shows was produced by the template. You can put this template on any page to see the links to the different possible editnotices for that page. You can use edit preview so you don't need to save this template on the page. }}

(The example above was substituted so it won't change in the future.)

Basically the "loader" will load at most three editnotices for each page (if those editnotices exist): The editnotice for the whole namespace, the editnotice for the current page group, and the editnotice for the current page.

Note that this is backwards compatible with the current user editable editnotices. So the users will not have to change their existing editnotices.

I know how to code up all this, it only takes some template code and no javascript. And since the code will only run in the edit windows it is not a performance problem at all.

So, what do you guys think? (I only need your comments, I will do all the coding.)

--David Göthberg (talk) 23:58, 4 October 2008 (UTC)


 * I now have a working editnotice loader in my user space, which can handle all the cases mentioned above. Except that it doesn't yet show a backlink to the page from an editnotice's editnotice.
 * While I coded the loader I added another feature: It now puts div tags with specific class names around the editnotices. Thus we can skin the editnotice area and the different types of editnotices using CSS. For instance a user can choose to not see some type of editnotice by placing one line of CSS in the user's /monobook.css. This is yet another feature that the current editnotice system doesn't have.
 * --David Göthberg (talk) 06:32, 5 October 2008 (UTC)


 * Very nice; this system looks extremely convenient. I like the overall compatibility, and the new features will probably prove quite helpful. If the code uses hyphens but we only see slashes, I guess nobody will have any complaints to make.
 * Just one question on a relevant point... I am informed that the new system used for disambiguation pages is distinct from the editnotice system and utilises different means (although it produces a similar output). Is there a danger of clashes? Waltham, The Duke of 14:55, 5 October 2008 (UTC)


 * Waltham: Oh, thanks for reminding me about the disambig editintro system. I have been following their work but had not realised I should compatibility test it versus this system. So I ran some tests and the two systems coexist nicely. The same page can have both a disambig editintro and editnotices (either old hyphen ones or new slash style ones added by my loader). And as usual I tested it in all three of my browsers: Firefox 2, Opera 9.02 and my very old Internet Explorer 5.5. I also studied the code for the two systems and checked the rendered XHTML pages and there should be no problem in any browsers.
 * Thanks for the reminder of possible clashes. I have now further hardened my loader by adding  to the DIV tag that it puts around what it produces. That protects against if anyone screws up the code of an editintro like for instance the disambig editintro.
 * And yes, their system is pretty different from this system since their system uses javascript to detect when there is a disambig template on a page, and then it shows the disambig editintro when editing the disambig page.
 * --David Göthberg (talk) 17:09, 5 October 2008 (UTC)


 * I have finished coding the loader. It now has backlinks and works in all namespaces. I have moved it to the template editnotice loader and also installed it there so that the system can be tested. That is, you can use user-friendly slash style editnotices on that template page and all its subpages, including its talk page.
 * --David Göthberg (talk) 00:43, 6 October 2008 (UTC)

Editnotice security

 * I would be concerned about edit notices being editable by any user: look at the issues we already have with template vandals. It would be unpleasant if every time User:Newbie tried to edit their userspace their screen was obscured with garbage and insults.
 * For userspace edit notices, you could hopefully abuse a .js or .css page in the user's userspace so only that user (and admins) can edit the page, although unfortunately it wouldn't render correctly when editing that js/css page. For any other namespace, requiring an editprotected isn't that high a barrier. Anomie⚔ 02:49, 6 October 2008 (UTC)


 * Anomie: Ouch, you got a point there. I assume you are aware of that currently anyone can edit the two editnotices for a user's main page and main talk page? But we can turn that off.
 * I am myself not sure if we should open up editing the notices for template space. I would prefer that they at least were semi-protected. (In fact, I think that the entire template space should be semi-protected. Beginners don't code templates anyway.)
 * For user space I might find it acceptable to place the editnotices on /Editnotice.css pages. Since I think that the users should be able to edit their own editnotices, but that other users perhaps should not be able to edit them. (I would prefer using .css pages over .js pages since the .js pages screw up the preview much more.) And it is easy to make this loader load the notices from such page names. And I just checked, when editing a .css page the loader still gets to show editnotices on top thus it can still show the backlink to the page that uses the editnotice. But it makes it hard for the user to code his editnotice since he can not preview it. So it is a pretty ugly hack.
 * But I think I just got a better idea. I can make it so that by default all editnotices for all namespaces can only be edited by admins (by storing them in MediaWiki space) but they will of course still use the new user-friendly slash-style naming with view links and backlinks as I demonstrate here. But then I can add a function that makes it a quick and easy operation for an admin to turn on and off user editable notices for a page group. (A group being a page and all its subpages.) Although that of course does add some complexity to the system.
 * I can also do so that a user himself can turn on and off publicly editable editnotices for his own user space. (If he turns it off then no editnotices will be loaded from his user space and then even he himself can't edit his editnotices.) This only involves a very minor .css hack. The editnotices themselves would have the same naming as I currently demonstrate here and would not be stored on .css pages.
 * I just ran some tests and it works fine. The only thing the user has to do is to create the page /Editnotice.css and put a single word "on" in it. If the page doesn't exist or contains for instance "off" then the user's editnotices will be loaded from the protected MediaWiki space instead. So now we only have to decide what the default should be for user space: On or off?
 * --David Göthberg (talk) 05:43, 6 October 2008 (UTC)


 * They can? Ouch, hopefully that gets fixed before vandals find out.
 * Yes, either css or js is an ugly hack. Anyone could always develop their notice in a sandbox and copy the finished wikitext over. Or someone could petition the devs to add a third magic extension that would be displayed as wikitext. Maybe I'll do that later on today, but don't count on it.
 * I don't know if an on/off switch is that much of an improvement. It will prevent vandals from attacking any random user if the default is "off" (which IMO it should be), but it wouldn't stop vandals from interfering with anyone who has the switch set to "on" and who isn't an admin. It might even be possible to easily search for victims (upon which I would prefer not to elaborate). Anomie⚔ 13:08, 6 October 2008 (UTC)


 * But that would mean that a user that comes under attack can just turn off editnotices for his user space. And now that you mention it I realise that the loader should not show any user editnotices for the /Editnotice.css file. So that page will always be accessible without being disturbed by any full screen vandal notices. The loader could instead show a short instruction notice about what to put in the /Editnotice.css. Now that is user-friendly! :))
 * But really, is this such a big problem? The vandals can already do almost the same thing by just putting the code on the user page directly, instead of in the editnotices. (But with the difference that if editing a page without edit preview then one isn't disturbed by the full screen junk.)
 * --David Göthberg (talk) 18:05, 6 October 2008 (UTC)


 * More important difference is that a separate "editnotice" page would not be watched by the same number of people (as a root user page), so vandalism is not reverted as quickly, and such vandalism might be very confusing to users not aware of editnotices. But I agree this is not a big problem, especially if editnotice system provides a backlink for editing the personal editnotice page. —AlexSm 18:35, 6 October 2008 (UTC)


 * AlexSm: Ah, good point about who watches what.
 * And right, the loader already provides a link to each editnotice so it can be easily edited. That is, the "view" link on top of each editnotice. (And that is one of the reasons why this new loader is much more user-friendly than the old system.) But that doesn't help if the vandal notice covers the entire screen. But it sure will make it easy to remove the usual non-full screen rude notices.
 * --David Göthberg (talk) 19:37, 6 October 2008 (UTC)


 * This may not be feasible, but is there any way the watchlist settings could be changed to auto-watch the editnotice that goes with the article? Then you wouldn't have to worry about vandalism of the editnotice any more than you do the article. --Philosopher Let us reason together. 07:45, 24 October 2008 (UTC)


 * Philosopher: Right, unfortunately there is no way to do that currently. But I think that it wouldn't be that hard for the devs to add that to the usual page watch functionality. For the editnotices that only admins can edit this is not that important, although it would be logical since one of course wants to watch the "whole" page. But for the user editable editnotices this would be more necessary.
 * That made me realise a thing: Perhaps the current MediaWiki watch functionality should automatically watch all subpages of a page (both current and future subpages) when one chooses to watch a page? Then the user editnotices would automatically be watched. And also for instance subpages that are transcluded into a main page (like template subpages that are used in a main template) would then be watched.
 * --David Göthberg (talk) 09:50, 24 October 2008 (UTC)


 * Yeah, that could be quite useful. But an exception would have to be made for the Wikipedia: namespace, where it is often useful to watch the "main" page but not the subpages (e.g. watching the main RfA page without watching all of the active nominations).  --Philosopher Let us reason together. 06:12, 25 October 2008 (UTC)


 * I just came up with an extra feature for the editnotice loader: When one is editing a user editnotice the loader currently (if installed) shows a notice that says:
 * This page is the editnotice for User:Example.
 * I can extend that text to say something like this:
 * This page is the editnotice for User:Example. Editnotices for this user are currently enabled.
 * And as I stated above, when editing the User:Example/Editnotice.css we can have a notice with instructions what to put in that page. (The words "on" or "off".)
 * --David Göthberg (talk) 21:11, 4 November 2008 (UTC)

List of uses of editnotices
Is there a way to get a list of editnotices currently in use? Or a way to find out whether a page has an editnotice without actually clicking on "edit this page"? Carcharoth (talk) 04:14, 23 October 2008 (UTC)


 * Carnildo pointed out this method. Carcharoth (talk) 04:26, 23 October 2008 (UTC)


 * The way Carnildo suggested is clumsy. Here's how I do it:
 * For a list of all the editnotices that only admins can edit use this search: Special:PrefixIndex/MediaWiki:Editnotice.
 * For the user editable /editnotice subpages for user pages we can not automatically get the full list like that. But we can search for one user at a time, and you have to search the "User:" and "User talk:" pages of that user separately. Since the Wikipedia search field now shows suggestion you can simply start to type " " in the search field and if there exists a " " then that will come up as a suggestion. And the same for the talk page editnotice. Just start to type in " " in the search field. Provided you have javascript enabled in your browser.
 * If you do not have javascript enabled in your browser you can search like this: Special:PrefixIndex/User:Example/E and Special:PrefixIndex/User talk:Example/E. But then you can just as well try to load the pages User:Example/Editnotice and User talk:Example/Editnotice to see if they exist.
 * If we extend the user editnotice loader (see discussion above) then you might want to search for and manually check all the subpages of the user, like this: Special:PrefixIndex/User:Example and Special:PrefixIndex/User talk:Example.
 * --David Göthberg (talk) 17:33, 23 October 2008 (UTC)


 * Wonderful! Thanks. Now let's document that somewhere more permanent and visible than a talk page. :-) Carcharoth (talk) 05:49, 24 October 2008 (UTC)


 * I took the liberty of slightly extending/correcting my comment above.
 * Carcharoth: Yes, we should perhaps add a section to this how-to page Editnotice explaining how to find the existing editnotices. Since it can be nice for users to look at how other users have coded their editnotices.
 * --David Göthberg (talk) 16:37, 24 October 2008 (UTC)

Guidelines for editnotices
I think we need guidelines on editnotices, what we can do and what we can't do with it, and eventually trying to find consensus to turn this page or a dedicated one into a guideline. Here are some points we can start discussing on:

1: Vandalism, I think that except in exceptional circumstances, we shouldn't use it to try to dissuade vandals, it's likely to be counter productive in fact, and it could be used on too many pages for little if none benefit and disturb other editors.

2: Userspace, I think we shouldn't allow editnotices in userspace indefinitely, we can use subpages for the userpage and usertalkpage. For subpages, that would be an inequality with non-admins who can't do that, I think it would be unnecessary and mediawiki space should only be used for 'serious business'.

3: Note on talk pages, I think we should create a template to be put on the article (or page)'s talk page signaling that a page has an editnotice, linking to it, indicating how we can ask an admin to modify it, with editprotected, etc. This is, I think, needed also in order to avoid admins from deciding unilaterally to use editnotices without mentioning it on the talk page and incite discussion.

4: Deletion, when an editnotice has no utility any more, should we delete it or just leave it blank (in order to preserve history, and for possible future uses) ? I think that in certain cases, the latter option is preferable (e.g. Sarah Palin).

Cenarium Talk  22:20, 14 November 2008 (UTC)


 * I took the liberty of changing your dotted list above to a numbered list so it is easier to respond to each item, I hope you don't mind?
 * 0: Right, eventually we will need a guideline. But for starters I think we should simply discuss and reach consensus here on this talk page. That is, don't regulate things too early, since it is a good thing if people can experiment freely in the beginning.
 * 1: I agree. Trying to talk to vandals through editnotices seems like a waste of effort, and will only add to the "noise level" for the other editors. Thus would be a bad thing.
 * 2: I disagree. I think user's should be allowed to have editnotices on their user and user talk pages indefinitely. However, I agree that for several reasons such editnotices should not be in MediaWiki space, but on "/Editnotice" subpages in the user's own user space. And we can easily make it so non-admin user's can make editnotices for their other user subpages. (Currently they can only do an editnotice for their main "User:" And "User talk:" page.) In fact, I have already coded that up, see discussion in section Slash style editnotices above and the fully working editnotice loader. All I need is a consensus to deploy that function. Well, I coded the editnotice loader some time ago, and since then people have suggested some improvements and I have learnt more, so it needs some brushing-up before I want to deploy it.
 * 3: I partly agree, but I already have a much better technical solution to that! The editnotice loader already have much of that functionality, but in a slightly different way. It automates it. That a page has an editnotice becomes visible when you edit a page, so I don't think that needs to be told when just reading a page. What the editnotice loader adds is a link on each editnotice to "view" it, so you can view its code, and edit it if you are an admin or if it is a user space editnotice. You are suggesting that we also need some kind of link to instructions for users how to ask for a protected editnotice to be edited, and that is a good idea. I can make it so the editnotice loader automatically adds such a link in some appropriate place. I have to think a little about how to best do that.
 * 3 b: Well, I think admins, and users in their own user space, should be allowed to be bold and add an editnotice, provided the editor thinks it is uncontroversial. I don't think it needs to be announced first, since on the next edit people will notice it anyway. Of course, the very nature of editnotices often makes them controversial. And it would be nice if the addition of an editnotice turned up in the watchlist of those that watch the page itself, but currently we don't have that function. And requesting that people manually add a template to the (talk) page to tell that an editnotice has been added would be too much bureaucracy, so I think for now we simply have to live with that we don't see in our watchlists when an editnotice have been added.
 * 3 c: I think the proper place to discuss an editnotice normally should be on the talk page of the page that has the editnotice, since that is the more visible place. That is, don't discuss the editnotice on the talk page of the editnotice itself. Except perhaps for high traffic talk pages that get archived, then it can be better to discuss on the talk page of the editnotice and just announce the discussion on the talk page of the page itself. And if consensus is that the editnotice should be changed or removed then the admins as usual should respect that consensus. (I know, many admins don't respect consensus, but that is a separate problem.)
 * 4: Right, deletion of editnotices is tricky. I see your point that it might be nice to just blank them, instead of actually deleting them. That is actually what we normally do with several system notices such as the sitenotice and similar "top of all pages notices". Although if we decide to deploy the user friendly editnotice loader, then blank editnotices will somewhat interfere with the loader, since it will think the editnotice exists and still add the "view" link, and the link to instructions how to ask an admin to change it. Of course, having those links on empty editnotices perhaps isn't such a bad thing, but it will look somewhat weird.
 * --David Göthberg (talk) 01:53, 15 November 2008 (UTC)
 * I don't mind. It's good to experiment a bit freely indeed, but there are already some things I'm not too happy with.
 * 1: For example, I disagree with using Template:Romeo notice.
 * 2: I don't disagree with using editnotices in userspace if there are ways not to use the Mediawiki space for that, and instead subpages. My point is that Mediawiki space shouldn't be used for personal convenience.
 * 3: I was essentially referring to articles there, to clarify, I think we should create a template for article's talk pages. For example on Talk:Barack Obama which reads, roughly, "This article has an editnotice, it is located at Mediawiki:Editnotice-0-Barack Obama. You may discuss changes to the editnotice on this talk page.", and of course ask admins to add this template when creating an editnotice, and also a new section for justification and inciting discussion. It shouldn't be viewed as a trivial thing, since it affects editing. I also think it should be done for non-project namespaces: templates, categories, portals and images. For other namespaces (Wikipedia especially), the template doesn't seem to be so needed, but I think it's generally best to create a new section for discussion, except for one's own userspace. Cenarium  Talk  16:18, 15 November 2008 (UTC)
 * I have created Template:Editnotice notice for the purpose of 3) (it needs improvement). I have also nominated Template:Romeo notice for deletion, see here. Cenarium  Talk  00:33, 17 November 2008 (UTC)


 * I'd oppose setting any guidelines. Use common sense.  It has been working thus far - and if somebody created an edit notice that is somehow inappropriate, they have been dealt with.  I see no reason to make more rules for the sake of making more rules. - Rjd0060 (talk) 16:46, 15 November 2008 (UTC)


 * Rjd0060: I think eventually we will probably need a guideline, or at least a page with some recommendations and advice. But I think it is too early to add such advice. So right, we should not create more rules for the sake of making more rules. But in time we will probably see that some things are done "wrong" repeatedly, or some things are discussed often, and then we might need to add rules or recommendations for those things.
 * Cenarium:
 * 1: Haha, that Template:Romeo notice is funny. But yeah, it should probably be deleted.
 * 2: For me it doesn't matter that much from a "rules point of view" if we put user editnotices in MediaWiki space or user space. Although since it is user data it does fit better in user space. But from a technical point of view I strongly agree that user editnotices should be placed in user space only. Among other things it makes it easier to use Special:PrefixIndex/User:Example and Special:PrefixIndex/User talk:Example to find all the pages of a user. And for non-admin users it makes it so they can edit their own editnotices. So, I would like to know if you guys agree with that I upgrade the current user space editnotice loader to also load editnotices for user subpages? (That is, load such editnotices from /Editnotice subpages in user space.) Thus admins don't need to use MediaWiki space anymore when they want to put editnotices on their subpages, and non-admin users can then edit their own editnotices for subpages too.
 * 3: The talk page message box you are suggesting sounds okay. But I strongly disagree with making it compulsory to use. And I don't think that one should have to create a section on the talk page immediately. Why create a section before there are any discussion? Of course, in many cases the editnotice should first be shown and suggested at the talk page so it can be discussed, before it is added as the actual working editnotice. Since in many cases the editnotice will be somewhat or even very controversial. Since editnotices tend to contain edit rules, and I think rules should first be discussed before they are added.
 * And a technical note about your suggested talk page message box: Both the talk page and the subject page can have an editnotice, and some might only have one of them. I can make it so the template automatically detects what editnotices the page and talk page has and only links to the existing ones, so we only get blue links in it.
 * --David Göthberg (talk) 02:17, 17 November 2008 (UTC)


 * I was not suggesting to create a strict "guideline", at least not at this point, but only some guidance and trying to harmonize editnotices. Cenarium  (Talk)  23:21, 25 December 2008 (UTC)


 * 1) If we're talking about actual vandalism, I agree per WP:BEANS. However, there are cases where users tend to make certain types of disruptve edits in good faith - it makes sense to use an editnotice to deter them.
 * 2) I see no reason not to allow edit notices on any page in the userspace. A non-admin can easily request it on the editnotice's talk page, so the inequality doesn't matter that much.
 * 3) I agree completely.
 * 4) I think leaving it blank is better here, although I think a userspace editnotice can be deleted by request of the user in question under CSD U1.
 * עוד מישהו Od Mishehu 13:01, 27 November 2008 (UTC)

I think a good tracking system for editnotices would be a template. For the sake of example, something like, to be used on non-user pages with editnotices, with no apparent output, but only categorizing in Category:Articles with editnotices for articles, and Category:Pages with editnotices for non-articles. This should be removed when the editnotice is blanked, so that it doesn't contain blanked editnotices like prefixindex. On another note, it makes me think about creating a Category:Tracking templates, there are a few like, various r from/for, etc. Cenarium  (Talk)  23:36, 25 December 2008 (UTC)

Note that I also created Category:Wikipedia editnotices for pages pertaining to editnotices. Cenarium (Talk)  15:05, 26 December 2008 (UTC)

I've added the template to a couple of articles. A possibility to handle blank editnotices would be to add an option (after rename of the template) 'blank=yes', and categorize in Category:Pages with blank editnotices. Cenarium (Talk)  03:59, 27 December 2008 (UTC)