I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to it. The images are being uploaded by sleeper socks old enough to upload them, and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
--NSLE
We should be locking the meta templates -- the kind that won't be changing anytime soon and if there's vandalism it'd be awful.
On 12/18/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to it. The images are being uploaded by sleeper socks old enough to upload them, and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
--NSLE _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
Yeah, the problem extends beyond the TFA due to the widespread use of these vandalised templates...
On 19/12/06, James Hare messedrocker@gmail.com wrote:
We should be locking the meta templates -- the kind that won't be changing anytime soon and if there's vandalism it'd be awful.
On 12/18/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to it. The images are being uploaded by sleeper socks old enough to upload
them,
and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
--NSLE _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
On 12/18/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
Yeah, the problem extends beyond the TFA due to the widespread use of these vandalised templates...
On 19/12/06, James Hare messedrocker@gmail.com wrote:
We should be locking the meta templates -- the kind that won't be
changing
anytime soon and if there's vandalism it'd be awful.
On 12/18/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been
having
with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution
to
it. The images are being uploaded by sleeper socks old enough to upload
them,
and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA
(and
re-transcluding after), but do the other list readers have any
solution?
--NSLE _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
I think Messed is saying that these templates should be protected anyway. The fact that they're in FAs isn't really relevant, if anything their being vandalized is just drawing our attention to the fact that they should be protected.
The highly used meta templates should just be moved to {{hprotected}}, [[Category:Wikipedia protected edit requests]] never seems to have that much of a backlog if legit updates are needed. (e.g. I just added {{for}} to hprot).
X
----- Original Message ----- From: "James Hare" messedrocker@gmail.com To: "English Wikipedia" wikien-l@wikipedia.org Sent: Monday, December 18, 2006 8:59 PM Subject: Re: [WikiEN-l] Main Page Featured Article
We should be locking the meta templates -- the kind that won't be changing anytime soon and if there's vandalism it'd be awful.
On 12/18/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to it. The images are being uploaded by sleeper socks old enough to upload them, and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
--NSLE _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
For reference: http://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Inciden... the latest discussion - there've been eight (nine?) previous ones.
On 19/12/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to it. The images are being uploaded by sleeper socks old enough to upload them, and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
--NSLE
On 12/18/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to it. The images are being uploaded by sleeper socks old enough to upload them, and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
Wait, is this vandalism happening on templates transcluded into the full article, or just the TFA blurb that's displayed on the main page?
Full article.
On 19/12/06, Kirill Lokshin kirill.lokshin@gmail.com wrote:
On 12/18/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images
into
transcluded-on-transcluded templates). In case some don't, I'm posting
this
to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to
it.
The images are being uploaded by sleeper socks old enough to upload
them,
and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
Wait, is this vandalism happening on templates transcluded into the full article, or just the TFA blurb that's displayed on the main page?
-- Kirill Lokshin _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
NSLE wrote:
...problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates).
[This is armchair speculation by a reader who is not as expert in these matters as he might be; apologies if I'm completely off-base.]
If nothing else, this indicates another reason why nested- transclusion is problematic, and why complexity like this ought perhaps to be avoided. (But of course this observation does nothing to solve the current problem.)
This strikes me as a problem that might be amenable to a technical solution. Perhaps we need some new, more-stringent form of protection which is automatically honored not only by the protected page, but by any other content which it includes, transcludes, or otherwise references. Or, perhaps there should be a "recursive protect" button, which applies (normal) protection to every page included by a given page.
(I don't know enough about how the various inclusion mechanisms are implemented to be able to say how easy or hard either of these solutions might be, but I suspect they wouldn't be impossible.)
What disturbs me about the vandalism on the Main Page articles is the fact that the vandals don't appear to be drive-by vandals, but rather users who know who to use the right tags and summaries to mask their activities and inflict the most damage. Not to be the pessimist here, but we're clearly dealing with a professional vandal who knows how to beat the system. We need to take action against this person in particular, if that is possible, because once we block one avenue, (s)he'll just find another.
-- Tariq Ab- Jo- Tu-
Steve Summit wrote:
NSLE wrote:
...problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates).
[This is armchair speculation by a reader who is not as expert in these matters as he might be; apologies if I'm completely off-base.]
If nothing else, this indicates another reason why nested- transclusion is problematic, and why complexity like this ought perhaps to be avoided. (But of course this observation does nothing to solve the current problem.)
This strikes me as a problem that might be amenable to a technical solution. Perhaps we need some new, more-stringent form of protection which is automatically honored not only by the protected page, but by any other content which it includes, transcludes, or otherwise references. Or, perhaps there should be a "recursive protect" button, which applies (normal) protection to every page included by a given page.
(I don't know enough about how the various inclusion mechanisms are implemented to be able to say how easy or hard either of these solutions might be, but I suspect they wouldn't be impossible.)
WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
On 12/18/06, Tariq Ab- Jo- Tu- tariqabjotu@gmail.com wrote:
What disturbs me about the vandalism on the Main Page articles is the fact that the vandals don't appear to be drive-by vandals, but rather users who know who to use the right tags and summaries to mask their activities and inflict the most damage. Not to be the pessimist here, but we're clearly dealing with a professional vandal who knows how to beat the system. We need to take action against this person in particular, if that is possible, because once we block one avenue, (s)he'll just find another.
Along those lines, we need to remember checkuser -- they can't review and block the source, if we don't let them know which usernames to check. The usual "block and move on" mentality won't quite cut it, in this case; there's an ongoing section at RFCU about all of this, and unfortunately the checkusers can't see everything.
Rangeblocks have been slowing it down, but have not yet stopped it. We need to explore new options, including protection options for templates.
As far as templates on TFA, is there consensus as to whether they should be semi or fully protected? We're obviously dealing with somebody smart enough to start using sleeper accounts, is what I figure, but I'm not sure how much they've done so, yet.
Eh. This one is incredibly frustrating, to me.
-Luna
I think fully protecting templates on Main Page related articles has become the norm. See {{mprotected}} and the category linked from the template page.
-- Tariq Ab- Jo- Tu-
Luna wrote:
On 12/18/06, Tariq Ab- Jo- Tu- tariqabjotu@gmail.com wrote:
What disturbs me about the vandalism on the Main Page articles is the fact that the vandals don't appear to be drive-by vandals, but rather users who know who to use the right tags and summaries to mask their activities and inflict the most damage. Not to be the pessimist here, but we're clearly dealing with a professional vandal who knows how to beat the system. We need to take action against this person in particular, if that is possible, because once we block one avenue, (s)he'll just find another.
Along those lines, we need to remember checkuser -- they can't review and block the source, if we don't let them know which usernames to check. The usual "block and move on" mentality won't quite cut it, in this case; there's an ongoing section at RFCU about all of this, and unfortunately the checkusers can't see everything.
Rangeblocks have been slowing it down, but have not yet stopped it. We need to explore new options, including protection options for templates.
As far as templates on TFA, is there consensus as to whether they should be semi or fully protected? We're obviously dealing with somebody smart enough to start using sleeper accounts, is what I figure, but I'm not sure how much they've done so, yet.
Eh. This one is incredibly frustrating, to me.
-Luna _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
On 12/19/06, Luna lunasantin@gmail.com wrote:
As far as templates on TFA, is there consensus as to whether they should be semi or fully protected? We're obviously dealing with somebody smart enough to start using sleeper accounts, is what I figure, but I'm not sure how much they've done so, yet.
Full protection, obviously. The incident last week where such vandalism was on the main page for fifteen minutes until it was found was by an established account, semi-protection wouldn't have stopped it; indeed the template that was affected *was* semi-protected at the time the vandalism occurred.
Stephen --
The policy dictating the protection of templates and images directly on the Main Page is long-standing. Luna was referring to the templates on Today's Featured Article itself; the protection of images / templates on that article is a relatively new thing.
-- Tariq Ab- Jo- Tu-
Stephen Bain wrote:
On 12/19/06, Luna lunasantin@gmail.com wrote:
As far as templates on TFA, is there consensus as to whether they should be semi or fully protected? We're obviously dealing with somebody smart enough to start using sleeper accounts, is what I figure, but I'm not sure how much they've done so, yet.
Full protection, obviously. The incident last week where such vandalism was on the main page for fifteen minutes until it was found was by an established account, semi-protection wouldn't have stopped it; indeed the template that was affected *was* semi-protected at the time the vandalism occurred.
On 12/19/06, Tariq Ab- Jo- Tu- tariqabjotu@gmail.com wrote:
The policy dictating the protection of templates and images directly on the Main Page is long-standing. Luna was referring to the templates on Today's Featured Article itself; the protection of images / templates on that article is a relatively new thing.
Of course, what I was intending to convey is that the type of vandalism we're seeing lately (using more complicated tricks of wikisyntax), of which that main page template vandalism was the clearest example, isn't something that can be defeated by semi-protection.
On 12/19/06, Steve Summit scs@eskimo.com wrote:
If nothing else, this indicates another reason why nested- transclusion is problematic, and why complexity like this ought perhaps to be avoided. (But of course this observation does nothing to solve the current problem.)
True!
Perhaps a solution would be a sort of reverse whatlinkshere, showing all the pages that are transcluded by a page so that they can all be protected. Time-limited protection would also be useful here, but I doubt this mitigates the disadvantages in other areas.
On 12/19/06, Sam Korn smoddy@gmail.com wrote:
On 12/19/06, Steve Summit scs@eskimo.com wrote:
If nothing else, this indicates another reason why nested- transclusion is problematic, and why complexity like this ought perhaps to be avoided. (But of course this observation does nothing to solve the current problem.)
True!
Perhaps a solution would be a sort of reverse whatlinkshere, showing all the pages that are transcluded by a page so that they can all be protected. Time-limited protection would also be useful here, but I doubt this mitigates the disadvantages in other areas.
The pages transcluded are already shown at the bottom of the edit page.
I think we should have an additional feature (let's call it [[Special:Recentchangestranscluded]]) that shows all changes to templates used on an article (all levels of transclusion). Then we could easily spot the offending change and revert, block and ignore the vandal as quickly as we do for regular FA vandalism. The problem is not that penis vandalism happens on a page linked to from the Main Page (we are used to that, and do not protect the FA of the day), it is that finding out what exactly has happened and reverting it takes too long. We just have to make it easy to figure out how to revert the vandalism.
Kusma
Sam Korn wrote:
Perhaps a solution would be a sort of reverse whatlinkshere, showing all the pages that are transcluded by a page so that they can all be protected. Time-limited protection would also be useful here, but I doubt this mitigates the disadvantages in other areas.
There is one already: just click the "edit" tab and look beneath the edit box. I've been wondering, as I've been reading this thread, why people don't just go through the list and protect all the templates listed there. After all, that seems like the easiest solution by far.
(Then again, the solution of using Special:ExpandTemplates to create a templateless protected copy on a subpage, and linking to that instead of directly to the original article, has its merits too.)
On 19/12/06, Ilmari Karonen nospam@vyznev.net wrote:
There is one already: just click the "edit" tab and look beneath the edit box. I've been wondering, as I've been reading this thread, why people don't just go through the list and protect all the templates listed there. After all, that seems like the easiest solution by far.
It's a hassle, but I've done it. And last time, I picked up two bits of vandalism - clever css include things, too - which hadn't been reverted or protected against.
We should have absolutely no qualms about full-protecting templates used in high-profile pages or across a large number of pages. I would say that at least a third of the vandalism complaints we get can be traced to these.
Sam Korn wrote:
On 12/19/06, Steve Summit scs@eskimo.com wrote:
If nothing else, this indicates another reason why nested- transclusion is problematic, and why complexity like this ought perhaps to be avoided. (But of course this observation does nothing to solve the current problem.)
True!
Perhaps a solution would be a sort of reverse whatlinkshere, showing all the pages that are transcluded by a page so that they can all be protected. Time-limited protection would also be useful here, but I doubt this mitigates the disadvantages in other areas.
http://meta.wikimedia.org/w/index.php?title=Toolserver/TStoc&diff=0&...
I'm offline at the moment, so I can't remember exactly what it's called, but I do recall that it looks through all the templates that are used - or at least it would if the toolserver was working.
On 12/19/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to it. The images are being uploaded by sleeper socks old enough to upload them, and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
Every type of vandalism goes away if we can implement a short delay before the page goes "live". Allow rollbacks/undos to be carried out on non-live versions of the page, and edits should also always be performed on the newest version.
The problem is not vandalism in itself. The problem is that our timeframe for reacting to vandalism is zero. Any act of vandalism is instantly visible to the entire world. Even a short delay of 2 minutes would drastically reduce the incentive for vandals and their impact even if successful.
Steve
On 12/18/06, Steve Bennett stevagewp@gmail.com wrote:
On 12/19/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images
into
transcluded-on-transcluded templates). In case some don't, I'm posting
this
to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to
it.
The images are being uploaded by sleeper socks old enough to upload
them,
and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
Every type of vandalism goes away if we can implement a short delay before the page goes "live". Allow rollbacks/undos to be carried out on non-live versions of the page, and edits should also always be performed on the newest version.
The problem is not vandalism in itself. The problem is that our timeframe for reacting to vandalism is zero. Any act of vandalism is instantly visible to the entire world. Even a short delay of 2 minutes would drastically reduce the incentive for vandals and their impact even if successful.
Steve
That is not an in-wiki fix for the problem. While I agree that it would be useful, major modifications to MediaWiki are outside the immediate tactical scope... Unless you know PHP a lot more fluently than I do and have commit access to the source ;-)
Steve Bennett wrote:
On 12/19/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to it. The images are being uploaded by sleeper socks old enough to upload them, and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
Every type of vandalism goes away if we can implement a short delay before the page goes "live". Allow rollbacks/undos to be carried out on non-live versions of the page, and edits should also always be performed on the newest version.
You're wrong. Subtle vandalism isn't prevented by a time delay.
On 12/19/06, Alphax (Wikipedia email) alphasigmax@gmail.com wrote:
You're wrong. Subtle vandalism isn't prevented by a time delay.
Yeah, I didn't read closely enough. Although, come to think of it, the issue is basically the same:
Page A indirectly transcludes page X. User U can't modify page A, but can modify X. Modifying X instantly modifies the appearance of A: big problem.
If there was a time delay between when the change was made to X and when the change appeared on A, there would be time to react. One way to do that might be to "freeze" all the templates that appear in A, perhaps by cloning them (with subst) to protected copies of themselves. Or perhaps by hacking the page caching code? Maybe give some trusted user the ability to control when the rendered view of the page is updated?
It seems pointless to me to attempt to somehow predict or track down vandals who are obviously pretty cluey and determined. Much better to focus our efforts on reducing the effectiveness of vandalism in general.
Oh, one last thought: if the major is problem is certain bad images, would there be any way of tagging those images so that they simply could not be displayed on the main page (or other designated page)? Regardless of how many layers of transclusion? This might have to be right at the web server level...?
Steve
Steve Bennett wrote: <snip>
Oh, one last thought: if the major is problem is certain bad images, would there be any way of tagging those images so that they simply could not be displayed on the main page (or other designated page)? Regardless of how many layers of transclusion? This might have to be right at the web server level...?
[[MediaWiki:Bad image list]] does this, but in this case they were uploading the images they were using.
On 12/19/06, Alphax (Wikipedia email) alphasigmax@gmail.com wrote:
[[MediaWiki:Bad image list]] does this, but in this case they were uploading the images they were using.
Time delays would work here - no image can be shown (on a highly visible page, or on a page in general) until it's been on the system for X number of minutes.
Steve
On 12/19/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
Recursive protection that applies to local images and templates should do the trick. It would have to connect the protections to each other (e.g. by using a shared protection ID) so that they can all be unprotected together as well. You might want to raise this on wikitech-l, or file a request on BugZilla.
On 12/18/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
Having watched the discussion and thought about it for a few hours, I think that of the options which are technically viable, this one seems to win for ease of near-term implimentation and completeness of proper function.
Assuming that a {{subst:}} works recursively and automatically, which I really don't know... My MediaWiki installation is outside my immediate hands-on test radius unfortunately.
On 12/19/06, George Herbert george.herbert@gmail.com wrote:
Having watched the discussion and thought about it for a few hours, I think that of the options which are technically viable, this one seems to win for ease of near-term implimentation and completeness of proper function.
Assuming that a {{subst:}} works recursively and automatically, which I really don't know... My MediaWiki installation is outside my immediate hands-on test radius unfortunately.
Naively substituting all templates used on a given page isn't viable imho - some templates would subst into a huge, ugly mess of code. What I was attempting to suggest before was taking something like this:
{{infobox foo| aoeuoae| oaueoau| ... }}
and substituting it into a temporary template, then replacing that in the page code:
{{_tfa_infobox foo| aoeuoae| oaueoau| ... }}
It's a bit of work to organise (every template used on the page has to go through this protection mechanism), but has the advantage that the effect on the code in the page itself is minimal: every instance of {{ is replaced by {{_tfa_, and then vice-versa after the page is no longer TFA.
Steve
On 12/18/06, George Herbert george.herbert@gmail.com wrote:
Assuming that a {{subst:}} works recursively and automatically, which I really don't know... My MediaWiki installation is outside my immediate hands-on test radius unfortunately.
Temporary substing is something to explore. But it would have its own problems, I think -- meta templates aren't substed when you subst the main template, from my experience. Substing all the infoboxes and other templates on a page can make it pretty ugly, too... unless we were thinking about copying all the templates to temporary subpages?
An adminbot is starting to sound a bit more tempting, from my end. Any bot would be able to find and protect TFA, and absolutely everything transcluded onto it, pretty easily, I think. Though I don't imagine that'll be an easy sell. Might be easier to see if we can get pgkbot to report all edits to that set of pages in the IRC counter-vandalism channels.
Still just brainstorming, here. -Luna
On 12/18/06, Luna lunasantin@gmail.com wrote:
On 12/18/06, George Herbert george.herbert@gmail.com wrote:
Assuming that a {{subst:}} works recursively and automatically, which I really don't know... My MediaWiki installation is outside my immediate hands-on test radius unfortunately.
Temporary substing is something to explore. But it would have its own problems, I think -- meta templates aren't substed when you subst the main template, from my experience. Substing all the infoboxes and other templates on a page can make it pretty ugly, too... unless we were thinking about copying all the templates to temporary subpages?
An adminbot is starting to sound a bit more tempting, from my end. Any bot would be able to find and protect TFA, and absolutely everything transcluded onto it, pretty easily, I think. Though I don't imagine that'll be an easy sell. Might be easier to see if we can get pgkbot to report all edits to that set of pages in the IRC counter-vandalism channels.
Still just brainstorming, here. -Luna
Responding to you and Steve here...
I would assume that this would be a temporary subst; that we'd essentially freeze the page prior to TFA move, make a completely subst'ed version, protect that, have it up for the day, and then do a revert to the immediately prior version as soon as it's done being TFA.
It doesn't really matter if it's terribly ugly for a while; the freeze is intended to keep it from being malignly modified.
This does make TFA temporarily not-editable, which people have objected to, but I don't know that doing so is necessarily a bad thing given the ongoing highly visible vandalism problem. How many tens of thousands or hundreds of thousands of visitors have gotten penis pictures so far? 8-(
On 19/12/06, George Herbert george.herbert@gmail.com wrote:
This does make TFA temporarily not-editable, which people have objected to, but I don't know that doing so is necessarily a bad thing given the ongoing highly visible vandalism problem. How many tens of thousands or hundreds of thousands of visitors have gotten penis pictures so far? 8-(
The real problem is that the featured article often gets a great deal of improvement while it's featured. This does require people to be watching it pretty much continuously for vandalism. It would be much better for the wiki to arrange patrollers rather than make readers' first experience of Wikipedia be an article they can't in fact edit, and I would say it is a worse thing than seeing a picture of a penis.
The only technical solution to vandals is to lock the wiki. That's a really bad thing. Do we really not have patrollers?
- d.
On 12/18/06, David Gerard dgerard@gmail.com wrote:
On 19/12/06, George Herbert george.herbert@gmail.com wrote:
This does make TFA temporarily not-editable, which people have objected to, but I don't know that doing so is necessarily a bad thing given the ongoing highly visible vandalism problem. How many tens of thousands or hundreds of thousands of visitors have gotten penis pictures so far? 8-(
The real problem is that the featured article often gets a great deal of improvement while it's featured. This does require people to be watching it pretty much continuously for vandalism. It would be much better for the wiki to arrange patrollers rather than make readers' first experience of Wikipedia be an article they can't in fact edit, and I would say it is a worse thing than seeing a picture of a penis.
The only technical solution to vandals is to lock the wiki. That's a really bad thing. Do we really not have patrollers?
I don't like my answer, either. It's certainly not great.
Fundamentally, the problem is that we're having some growth pains resulting in problems which tend to put goals such as "Be a great encyclopedia" in conflict with goals such as "Which everyone can always edit".
I am tending towards the opinion that, as unfortunate as it is, the Featured Article has become an Attractive Nuisance. Legally, in the US, it's normal to assume that the owner of an attractive nuisance bears responsibility to put a fence around it and keep it from hurting people.
I don't like that conclusion, but that's where I'm leaning. I think that it's going to come down to a balance of lesser evils. I am interested in seeing what everyone else thinks about it.
Something that occurred to me a bit ago... We could both freeze and not-freeze the featured article, with a bit of effort. We could create a new name heirarchy (wiki/Featured Article/article-name) and drop a subst'ed version of the page, protected, down into that subpage, with a link to the "live" wiki article there if people want to see how it may have improved over the course of the day. If there's bandwidth available, someone could repeat the process (create an updated frozen subst version from the live wiki page) every hour or two during the TFA run, so it doesn't even have to be fixed as of the beginning of the day.
This doesn't take any new technology, just a few subpages and a bit of procedure...
On 19/12/06, George Herbert george.herbert@gmail.com wrote:
Something that occurred to me a bit ago... We could both freeze and not-freeze the featured article, with a bit of effort. We could create a new name heirarchy (wiki/Featured Article/article-name) and drop a subst'ed version of the page, protected, down into that subpage, with a link to the "live" wiki article there if people want to see how it may have improved over the course of the day. If there's bandwidth available, someone could repeat the process (create an updated frozen subst version from the live wiki page) every hour or two during the TFA run, so it doesn't even have to be fixed as of the beginning of the day. This doesn't take any new technology, just a few subpages and a bit of procedure...
I really like that idea - a locked-down static copy and an editable copy linked at the top. Better if it can be semi-automated.
- d.
On 12/19/06, George Herbert george.herbert@gmail.com wrote:
Something that occurred to me a bit ago... We could both freeze and not-freeze the featured article, with a bit of effort. We could create a new name heirarchy (wiki/Featured Article/article-name) and drop a subst'ed version of the page, protected, down into that subpage, with a link to the "live" wiki article there if people want to see how it may have improved over the course of the day. If there's bandwidth available, someone could repeat the process (create an updated frozen subst version from the live wiki page) every hour or two during the TFA run, so it doesn't even have to be fixed as of the beginning of the day.
This doesn't take any new technology, just a few subpages and a bit of procedure...
I'm fairly sure that you've just described exactly what is to be implemented when Stable Versions go online, which we have been told since Wikimania is Real Soon Now.
Michael Noda wrote:
I'm fairly sure that you've just described exactly what is to be implemented when Stable Versions go online, which we have been told since Wikimania is Real Soon Now. _______________________________________________
I wonder if "stable version" could be implemented on a very limited basis -- just the featured article -- fairly quickly. This could give some valuable live testing to the feature for the devs, and solve a problem for en at the same time. Just wondering...
-Rich
Rich Holton wrote:
Michael Noda wrote:
I'm fairly sure that you've just described exactly what is to be implemented when Stable Versions go online, which we have been told since Wikimania is Real Soon Now. _______________________________________________
I wonder if "stable version" could be implemented on a very limited basis -- just the featured article -- fairly quickly. This could give some valuable live testing to the feature for the devs, and solve a problem for en at the same time. Just wondering...
Not without some fairly significant controversy.
-Jeff
Jeff Raymond wrote:
Rich Holton wrote:
Michael Noda wrote:
I'm fairly sure that you've just described exactly what is to be implemented when Stable Versions go online, which we have been told since Wikimania is Real Soon Now. _______________________________________________
I wonder if "stable version" could be implemented on a very limited basis -- just the featured article -- fairly quickly. This could give some valuable live testing to the feature for the devs, and solve a problem for en at the same time. Just wondering...
Not without some fairly significant controversy.
Over the idea of stable version itself? Or over this particular way of implementing it?
-Rich
Rich Holton wrote:
Jeff Raymond wrote:
Not without some fairly significant controversy.
Over the idea of stable version itself? Or over this particular way of implementing it?
Both, really. We still can't get a protection on the main page without people throwing a fit about it, and a couple attempts at stable trial runs didn't exactly go well (although the person who decided to try it probably wasn't the best choice).
I think we're merely going to have to look into the protection of problem templates used on the main page. That's where we're having the problem, and protecting them doesn't remove the ability to edit what's seen in front of people.
-Jeff
On 12/19/06, Michael Noda michael.noda@gmail.com wrote:
On 12/19/06, George Herbert george.herbert@gmail.com wrote:
Something that occurred to me a bit ago... We could both freeze and not-freeze the featured article, with a bit of effort. We could create a new name heirarchy (wiki/Featured Article/article-name) and drop a subst'ed version of the page, protected, down into that subpage, with a link to the "live" wiki article there if people want to see how it may have improved over the course of the day. If there's bandwidth available, someone could repeat the process (create an updated frozen subst version from the live wiki page) every hour or two during the TFA run, so it doesn't even have to be fixed as of the beginning of the day.
This doesn't take any new technology, just a few subpages and a bit of procedure...
I'm fairly sure that you've just described exactly what is to be implemented when Stable Versions go online, which we have been told since Wikimania is Real Soon Now.
And on that day, someone's manual labors will be simplified.
If we had a known "soon" date on that maybe doing it manually wouldn't be a good idea, but I don't know that we have any sign of where it is...
(copied wikitech-l in case there is an affirmative answer available)
On 12/19/06, Luna lunasantin@gmail.com wrote:
On 12/18/06, George Herbert george.herbert@gmail.com wrote:
Assuming that a {{subst:}} works recursively and automatically, which I really don't know... My MediaWiki installation is outside my immediate hands-on test radius unfortunately.
Temporary substing is something to explore. But it would have its own problems, I think -- meta templates aren't substed when you subst the main template, from my experience. Substing all the infoboxes and other templates on a page can make it pretty ugly, too... unless we were thinking about copying all the templates to temporary subpages?
If you just want to recursively transclude all templates, there is a page for that, [[Special:Expand templates]]. This will transform all template code into static wikicode (including dynamic stuff like {{#if}}s and dates and whatnot). It tends to produce a heck of a lot of wikicode though.
An adminbot is starting to sound a bit more tempting, from my end. Any bot would be able to find and protect TFA, and absolutely everything transcluded onto it, pretty easily, I think. Though I don't imagine that'll be an easy sell. Might be easier to see if we can get pgkbot to report all edits to that set of pages in the IRC counter-vandalism channels.
Still just brainstorming, here. -Luna _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
On 12/19/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
I assume most of the list's readers know what problems we've been having with the TFA each day on the main page (vandals inserting shock images into transcluded-on-transcluded templates). In case some don't, I'm posting this to see if anyone has ideas off how to avoid this. It's been discussed extensively on ANI, and there does not seem to be a workable solution to it. The images are being uploaded by sleeper socks old enough to upload them, and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
--NSLE
Since when is something getting tedious for admins a reason not to do it? If it's a mainpage non-article vandal target, it should be protected - no exceptions.
Mgm
On Tue, 19 Dec 2006 06:49:11 +0100, "MacGyverMagic/Mgm" macgyvermagic@gmail.com wrote:
Since when is something getting tedious for admins a reason not to do it? If it's a mainpage non-article vandal target, it should be protected - no exceptions.
The obvious is never a problem, as my dad always says.
Guy (JzG)
On 12/18/06, Guy Chapman aka JzG guy.chapman@spamcop.net wrote:
On Tue, 19 Dec 2006 06:49:11 +0100, "MacGyverMagic/Mgm" macgyvermagic@gmail.com wrote:
Since when is something getting tedious for admins a reason not to do it? If it's a mainpage non-article vandal target, it should be protected - no exceptions.
The obvious is never a problem, as my dad always says.
Guy (JzG)
I have to agree. I saw a certain penis image when I logged on the other day and it gave me quite a start. I haven't seen that kind of thing in a while. As long as the article itself get protected, we shouldn't beat around the bush as to what to protect or not to protect. If a template has to get subst'd I guess that is fine too. Better we have messy code that people can't see right away than shock images that they can.
--Ryan
There have also been suggestions of communicating with the vandal's ISP. Should that just take place, instead of us trying to figure out how to preempt the vandal?
On 12/19/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
There have also been suggestions of communicating with the vandal's ISP. Should that just take place, instead of us trying to figure out how to preempt the vandal?
If it's one single consistent vandal, by all means call the ISP.
Someone associated with OFFICE should do so, so that it's taken seriously, and not blown off as a random WP person making the call...
George Herbert wrote:
On 12/19/06, NSLE (Wikipedia) nsle.wikipedia@gmail.com wrote:
There have also been suggestions of communicating with the vandal's ISP. Should that just take place, instead of us trying to figure out how to preempt the vandal?
If it's one single consistent vandal, by all means call the ISP.
Someone associated with OFFICE should do so, so that it's taken seriously, and not blown off as a random WP person making the call...
Given that that particular vandal was originating from a totalitarian police state[1], I'd say that reporting them to their ISP would be a Really Good Disincentive against future vandalism.
[1] I don't plan on going there any time soon.
NSLE (Wikipedia) wrote:
... I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
If you want have a rock stable unvandalizeable article page, you could copy/paste the complete wiki-source content of the article into http://en.wikipedia.org/wiki/Special:ExpandTemplates and copy/paste the expanded result back to the article and protect it (don't forget to specify the article title on Special:ExpandTemplates).
The resulting "transclusion free" article then depends on nothing else but the images.
At least this would correctly "subst" every template, also those using parser functions (#if & Co).
Just note though that the resulting version can only serve as temporary throw-away "viewing only" page, as that should be reverted back to the non-expanded version before further development (I mean further editing).
--Ligulem
The main page vandalism problem is becoming a reason why I'm becoming reluctant to submit articles to WP:FAC or strive for that as my goal. And, I'm aware of other featured articles where the author(s) have understandably expressed wishes that the article not be showcased on the main page.
{{subst}}ing the templates is worth doing, though perhaps not enough to address concerns. I'm not sure what the best, technically feasible option is...
NSLE (Wikipedia) wrote:
The images are being uploaded by sleeper socks old enough to upload them, and protecting every single template on TFA (including transcluded-on-transcluded ones) can be tedious for the admins. I've suggested perhaps substituting the templates before they become TFA (and re-transcluding after), but do the other list readers have any solution?
Make the whole of template space editable by admins only, and loosen the grip on adminship. Templates are probably an area which should be kept to trusted users, and admins are our trusted users. Might make the community face up to rewiring RFA.
Steve Block wrote:
Make the whole of template space editable by admins only, and loosen the grip on adminship. Templates are probably an area which should be kept to trusted users, and admins are our trusted users. Might make the community face up to rewiring RFA.
Or resurrect the middle option, like the idea of giving trusted users the rollback function. Even trusted users wouldn't get the admin bit if it were loosened, but would be perfectly trusted to have access to something like that.
-Jeff
Make the whole of template space editable by admins only, and loosen the grip on adminship. Templates are probably an area which should be kept to trusted users, and admins are our trusted users. Might make the community face up to rewiring RFA.
Or resurrect the middle option, like the idea of giving trusted users the rollback function. Even trusted users wouldn't get the admin bit if it were loosened, but would be perfectly trusted to have access to something like that.
A middle option sounds good. I'm not sure how it should be handed out - an automatic system would be good, but would probably be easy to get around. A manual system would be a lot of work... (there are lots of trustworthy wikipedians).
Thomas Dalton wrote:
A middle option sounds good. I'm not sure how it should be handed out
- an automatic system would be good, but would probably be easy to get
around. A manual system would be a lot of work... (there are lots of trustworthy wikipedians).
Yeah, but if it was on a voluntary basis, it wouldn't be that much work after the initial rush. Not every trusted user would want/need access to templates, for instance.
-Jeff
Yeah, but if it was on a voluntary basis, it wouldn't be that much work after the initial rush. Not every trusted user would want/need access to templates, for instance.
A lot of them would want it despite not needing it - everyone wants to be trusted. Maybe a specific "template" group, rather than a more general "trusted" group would be good, it would make it easier to convince people that it's "no big deal".
On Wed, 20 Dec 2006 17:53:32 +0000, "Thomas Dalton" thomas.dalton@gmail.com wrote:
Yeah, but if it was on a voluntary basis, it wouldn't be that much work after the initial rush. Not every trusted user would want/need access to templates, for instance.
A lot of them would want it despite not needing it - everyone wants to be trusted. Maybe a specific "template" group, rather than a more general "trusted" group would be good, it would make it easier to convince people that it's "no big deal".
The real problem here is that trusted users should be given the sysop bit and are not. No big deal? Not these days.
Guy (JzG)
On 12/20/06, Guy Chapman aka JzG guy.chapman@spamcop.net wrote:
On Wed, 20 Dec 2006 17:53:32 +0000, "Thomas Dalton" thomas.dalton@gmail.com wrote:
Yeah, but if it was on a voluntary basis, it wouldn't be that much work after the initial rush. Not every trusted user would want/need access
to
templates, for instance.
A lot of them would want it despite not needing it - everyone wants to be trusted. Maybe a specific "template" group, rather than a more general "trusted" group would be good, it would make it easier to convince people that it's "no big deal".
The real problem here is that trusted users should be given the sysop bit and are not. No big deal? Not these days.
Guy (JzG)
Could be a worse deal.
I think I understand why my RFA was controversial and failed, and to some degree the "please don't be too controversial" RFA criterion makes a lot of sense.
On 12/21/06, Guy Chapman aka JzG guy.chapman@spamcop.net wrote:
The real problem here is that trusted users should be given the sysop bit and are not. No big deal? Not these days.
Yes. Put differently, we lack a middle ground. Admin is too powerful to give to everyone. But there's nothing to give to our trusted users.
Steve
...except admin. Why can't trusted users handle admin? It's not like admin is a big deal, so we should hand it out more liberally.
On 12/20/06, Steve Bennett stevagewp@gmail.com wrote:
On 12/21/06, Guy Chapman aka JzG guy.chapman@spamcop.net wrote:
The real problem here is that trusted users should be given the sysop bit and are not. No big deal? Not these days.
Yes. Put differently, we lack a middle ground. Admin is too powerful to give to everyone. But there's nothing to give to our trusted users.
Steve _______________________________________________ WikiEN-l mailing list WikiEN-l@Wikipedia.org To unsubscribe from this mailing list, visit: http://mail.wikipedia.org/mailman/listinfo/wikien-l
On 12/21/06, Chris Picone ccool2ax@gmail.com wrote:
...except admin. Why can't trusted users handle admin? It's not like admin is a big deal, so we should hand it out more liberally.
Adminship lets you do lots of very different things, including protecting/unprotecting, accessing deleted revisions of pages, deleting pages, blocking users, rollback, modifying protected articles, templates, and stylesheets and more. This range of powers is so diverse that it's hard to even imagine one person actually needing them all. And that can be a problem: we have users who would make great vandal fighters, but would you really want them with write-access to the front page, or read-access to sensitive deleted revisions?
Steve
On 12/21/06, Steve Bennett stevagewp@gmail.com wrote:
On 12/21/06, Chris Picone ccool2ax@gmail.com wrote:
...except admin. Why can't trusted users handle admin? It's not like admin is a big deal, so we should hand it out more liberally.
Adminship lets you do lots of very different things, including protecting/unprotecting, accessing deleted revisions of pages, deleting pages, blocking users, rollback, modifying protected articles, templates, and stylesheets and more. This range of powers is so diverse that it's hard to even imagine one person actually needing them all.
I've done pretty much all of them other than messing with monobook.js and monobook.css
On 12/21/06, geni geniice@gmail.com wrote:
I've done pretty much all of them other than messing with monobook.js and monobook.css
Yep. Know anyone who has used all of them?
Steve
On 12/23/06, Steve Bennett stevagewp@gmail.com wrote:
On 12/21/06, geni geniice@gmail.com wrote:
I've done pretty much all of them other than messing with monobook.js and monobook.css
Yep. Know anyone who has used all of them?
Steve
[[User:R. Koot]] ?
On 12/23/06, Steve Bennett stevagewp@gmail.com wrote:
On 12/21/06, geni geniice@gmail.com wrote:
I've done pretty much all of them other than messing with monobook.js and monobook.css
Yep. Know anyone who has used all of them?
I haven't edited [[MediaWiki:Monobook.css]] or [[MediaWiki:Common.css]], etc, although I have edited other MediaWiki pages in addition to doing everything else in that list. I've also undeleted pages, unblocked users, and used [[Special:Unwatchedpages]]. I can't remember if I've ever moved a move-protected page, although I'm fairly certain I haven't hidden the contributions of any vandals from [[Special:Recentchanges]].
Over the course of time a reasonable active admin will use all of the buttons at some point or another. How big a deal each of them are varies. The original admin work, the janitorial stuff, really is no big deal and never has been.
However as WP has scaled, a greater amount (though not, IMHO, a greater proportion) of work can be a big deal. Certain types of deleted content, blocks in certain circumstances and so forth.
So, it looks like we've had a fresh attack today (around 15:50 UTC December 24). I am aware that there's now a BugZilla request - http://bugzilla.wikimedia.org/show_bug.cgi?id=8322 - and Brion's reply is worth noting...
The obvious way to fix this would break the actual purpose of <includeonly>,
which is to keep special links such as category links meant to belong to target pages from being indicated on the template page.
Steve Bennett wrote:
On 12/21/06, Chris Picone ccool2ax@gmail.com wrote:
...except admin. Why can't trusted users handle admin? It's not like admin is a big deal, so we should hand it out more liberally.
Adminship lets you do lots of very different things, including protecting/unprotecting, accessing deleted revisions of pages, deleting pages, blocking users, rollback, modifying protected articles, templates, and stylesheets and more. This range of powers is so diverse that it's hard to even imagine one person actually needing them all.
Admins can:
* Delete, restore, view deleted revisions * Protect and unprotect on various levels, edit protected * Edit global interface (MediaWiki: namespace) and user interface (User: space .js and .css files other than their own) * Block, unblock users, IPs, IP ranges * Rollback, rollback with bot parameter to remove from RC
This is from a technical point of view; the combination of these things just makes it look like they can do a whole lot more.
On 12/21/06, Chris Picone ccool2ax@gmail.com wrote:
...except admin. Why can't trusted users handle admin? It's not like admin is a big deal, so we should hand it out more liberally.
Adminship is a big deal. You may not want this to be the case but it is.
On 12/21/06, geni geniice@gmail.com wrote:
On 12/21/06, Chris Picone ccool2ax@gmail.com wrote:
...except admin. Why can't trusted users handle admin? It's not like admin is a big deal, so we should hand it out more liberally.
Adminship is a big deal. You may not want this to be the case but it is.
Remember that the issue at hand is main page/featured article template vandalism, and there are ways to deal with that that don't require this can of worms to be opened, let alone answered, first.
On 12/20/06, geni geniice@gmail.com wrote:
On 12/21/06, Chris Picone ccool2ax@gmail.com wrote:
...except admin. Why can't trusted users handle admin? It's not like admin is a big deal, so we should hand it out more liberally.
Adminship is a big deal. You may not want this to be the case but it is.
I think that it isn't a big deal the way most admins use it. It's reasonable to say that for controversial people, it becomes a bigger deal for the community.
The definition of controversial has expanded somewhat, and despite it having bitten me recently, I think I agree with that.
On 12/21/06, George Herbert george.herbert@gmail.com wrote:
I think that it isn't a big deal the way most admins use it. It's reasonable to say that for controversial people, it becomes a bigger deal for the community.
The definition of controversial has expanded somewhat, and despite it having bitten me recently, I think I agree with that.
The potential for it to be a very big deal indeed on the occasion is enough to make it a big deal.
On 12/20/06, Steve Block steve.block@myrealbox.com wrote:
Make the whole of template space editable by admins only, and loosen the grip on adminship. Templates are probably an area which should be kept to trusted users, and admins are our trusted users. Might make the community face up to rewiring RFA.
If the goal is to make adminship "no big deal," I'm not sure if adminprotecting an entire namespace will accomplish that. :E Although the template vandalism has exasperated and frustrated me more than anything else in recent memory, I don't think that's the way to go. Granted, there was a proposal to sprotect them all...
http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28policy%29#Sprotect_al...
Sprotecting every widely used template, I'll support. It might be preferred that we think about making an access level between autoconfirmed and sysop -- people who get access to an intermediate protection level and have the ability to admin rollback. That could be operated by a simple requests page (like AWB, but probably even less stringent), or just after some particular amount of time (two weeks, or a month, maybe?).
Giving admin rollback to a wider number of users would save a lot of time, effort, and bandwidth for RC patrol, at least. An intermediate protection level would let us clamp down on some of these templates, without locking the vast majority of users out.
Just food for thought, I guess. Butcher and propose as you please.
-Luna
On 12/21/06, Steve Block steve.block@myrealbox.com wrote:
Make the whole of template space editable by admins only, and loosen the grip on adminship. Templates are probably an area which should be kept to trusted users, and admins are our trusted users. Might make the community face up to rewiring RFA.
Hell no. There are too many templates which need too much maintenance. There's no reason for navigation boxes to be protected like that, and they do get updated fairly often.
Restrictions on what can go into an unprotected template might be worth pursuing though.
Steve