text:
ArchWiki talk:Administrators
- 1 Meaning of Administrator
- 2 Admin guidance
- 3 Cite extension
- 4
Should we remove or archive obsolete articles?
- 5 How to archive templates
- 6 Is moving pages to user space a good idea?
- 7 Policy on abuse/blocking users
- 8 Deprecated templates
- 9 Package page style guide/template
Meaning of Administrator
[Split from #Automatic sorting. -- Kynikos (talk) 12:36, 4 May 2014 (UTC)]
One more thing, it might be useful to describe the difference between this list and [1]. I assume those not listed here are the (former) devs? -- Lahwaacz (talk) 06:12, 4 May 2014 (UTC)
- The users with administrative rights not listed here are Developers, Trusted Users, Arch Fellows, Forum Admins etc.
- I agree that it can be confusing for users approaching the ArchWiki from experiences on other wikis to see from that page that there are dozens of users with administrator rights but in fact only a handful actually act as wiki admins as they are commonly perceived on e.g. Wikipedia.
- However I think the proper way to clarify this is the natural MediaWiki's way: creating more specific user groups (which should still inherit the rights from the administrators group), like it happens on Wikipedia and in analogy with what happens on our Forums. Unfortunately this would require the good old FS#35545 to be solved first.
- -- Kynikos (talk) 12:38, 4 May 2014 (UTC)
- wikipedia:Wikipedia:User access levels is really great. With the current scheme, creating an equivalent for ArchWiki does not make much sense, but it should be considered in case more groups are created. -- Lahwaacz (talk) 19:05, 5 May 2014 (UTC)
Admin guidance
Show we add some guidence that an admin should follow, the responsibilty they should take?
- Encourage contribution from Arch users.
- Guide new contributor to follow Arch Wiki Style.
--Fengchao (talk) 13:23, 11 July 2014 (UTC)
- Well, if somebody becomes an admin, (s)he's probably been judged to be already fully aware of all his/her responsibilities, since becoming an admin requires quite a bit of experience as an editor (most likely as a maintainer first). Yes, some users are given administration rights because of other roles in the community, e.g. Devs, TUs, forum admins etc., but they usually don't act as "real" wiki administrators. Nonetheless, some guidelines may help users understand what is the role of an admin, and the same goes for maintainers, and we could create a proper page for that, as was conceived in #Meaning of Administrator. -- Kynikos (talk) 06:06, 12 July 2014 (UTC)
Cite extension
[Moved from User talk:Kynikos#Cite extension. — Kynikos (talk) 10:04, 15 January 2015 (UTC)]
I'm feeling bad about not having a way to cite my sources properly in my article. As I do for the LibreOffice Newsletter I'm in charge of I'll do as it for my Arch Linux articles:
Some text<ref name=myRefName /> == References == <ref name=myRefName>[http://someURL The link]</ref>
I don't know if this system suits you. Let me know. -- wget (talk) 01:07, 10 December 2014 (UTC)
- Unfortunately you cannot use the ref tag in this wiki, since it requires the Cite extension, which we don't have installed. Generally we don't require to support every statement with citations, unlike for example on Wikipedia, but it will be very useful if you will add references to external sources simply using links on keywords, like this, or this[2] (see the source text for the implementation; we don't have style rules about this for the moment). If you want to mention the generic sources that you use for writing the article, you should just add them to Dynamic Kernel Module Support#See also. -- Kynikos (talk) 05:49, 10 December 2014 (UTC)
- I don't like this idea very much. The See also section sounds like we invite the user to read these documents to provide more detailed information to the reader, implying the Arch Linux documentation is not complete enough. This isn't actually what we want to do in this case: we just adapted an existing article to build a section of the Arch Linux documentation page. And yes, I would really like to have citations like in Wikipedia, but without the need to cite every assumptions we make obviously. Would you mind installing the Cite extension? -- wget (talk) 12:00, 11 December 2014 (UTC)
- Unfortunately installing extensions requires write access to the repository, which is restricted to Developers, and a feature request should be opened in the bug tracker. I don't see other alternatives to the methods I proposed above.
- That said, ArchWiki articles are not intended to be "complete" as in "it shouldn't be necessary to read anything else in order to understand every detail of the topic"; if the topic has good upstream/official documentation, there's no point in duplicating it, see also Help:Style#Hypertext metaphor.
- -- Kynikos (talk) 14:12, 12 December 2014 (UTC)
- Hi Kynikos. Happy New Year! Any news about the citation extension? Yet again today, I wanted to write on the wiki that yaourt does support bash and zsh completion, and to link these assumptions to the source code. The cite extension is indeed very useful, especially in the case (like this one) when upstream has not good documentation. If you haven't already reported the feature request on the bug tracker, are you willing to support the one I'm gonna write? Otherwise, I don't see the interest in writing that request: devs will unlikely accept it without your support. Thanks in advance. -- wget (talk) 23:50, 6 January 2015 (UTC)
- Happy New Year mate :) Honestly I don't see the need for the cite extension here: can't you just use simple inline links as I proposed above? (And as it's done in every article?) Sorry, but unless you prove that you really have no way to add that link without the extension, I can't support your request... Just try to amend the article with inline links and let's see how it looks, ok? I'll try to help you fix the style, if needed ;) -- Kynikos (talk) 05:34, 7 January 2015 (UTC)
- Yesterday again, I was cleaning/updating the Browser plugins and wanted to put a link to the official where I took that information from. That link concerned two locations in that article: Disable the "Press ESC to exit full screen mode" message and Multiple monitor full-screen fix, the solution using inline links was to duplicate that URL which I didn't. Regarding the your message, the problem seems to be a lack of workforce then. A possible solution would be merging wikis and forums of the native languages communities into Arch Linux infrastructure, bringing along all these admins/maintainers to the Arch infra. But for that a bunch of work needs to be done first: easy multilanguage support (especially regarding links) on the Wiki (maybe native language staff can help for that). -- wget (talk) 14:59, 8 January 2015 (UTC)
- I see, actually if you want to use the same link in two different sections, there's nothing against it; even if there was the Cite extension installed, you'd have to duplicate the <ref> tag, right? There are already many articles with multiple instances of the same internal or external links, I don't see any harm with that, as long as the duplicated links are found in indipendent parts of an article.
- -- Kynikos (talk) 15:18, 9 January 2015 (UTC)
- Yes, just the <ref> tag will need to be duplicated, but the URL, authors, description, etc. will not. That ref will just act as a very short reference to the long <ref> tag written at the end of the article. See this example, this is the way we are working at TheDocumentFoundation. -- wget (talk) 21:20, 13 January 2015 (UTC)
- In general, also expanding on what I wrote in my arch-general post that you linked, my position is that it's too late to install the Cite extension now, because that would only introduce a new style standard for external links that would make all the existing articles style-obsolete, in practice starting a very long — if not infinite — transition period over which articles would have both inline and referenced links, which I wouldn't see as an improvement at all.
- -- Kynikos (talk) 15:18, 9 January 2015 (UTC)
- Eheh I understand, I guess I'm a bit like that myself :P Well, considering that we've got this far, I'm going to move this branch of the discussion to ArchWiki talk:Administrators and see what are the opinions of the rest of the team. — Kynikos (talk) 09:51, 15 January 2015 (UTC)
- Maybe I'm missing something obvious, but I dislike the Wikipedia citation style simply because it needs 3 clicks instead of one: one to see the link, a second to open it, and a third to return to the article. That said I'm a proponent of requiring citations for statements made on this wiki: Help_talk:Style#Citations and reasoning (one of these days I'll get to making a draft). -- Alad (talk) 18:31, 29 October 2015 (UTC)
- What I was saying is that if Wikipedia-style citations had been used from the beginning of this wiki, I think we'd probably be used to them by now; it's true that they require more effort to follow a link if you don't use the mouseover tooltip (e.g. when using pentadactyl, vimfx etc.; tooltips can also be set to appear on click though); on the other hand, though, they encourage the maintenance of a comprehensive list of external reference links at the bottom of each article. Anyway, as I've repeated multiple times, now I'm against introducing Wikipedia-style citations.
- Regarding requiring citations, I'll wait for your draft, but I think making them a requirement could be too much: what do we do with unreferenced statements? Delete them? Or fill articles with "Citation needed" templates? Wikipedia needs citations more than us because it deals with topics that can be easily discussed from biased standpoints; also, it doesn't allow original research, see also Wikipedia:Wikipedia:Verifiability. In this wiki, I'd talk more of a recommendation, and well specify what kind of statements should better be referenced.
- — Kynikos (talk) 15:27, 30 October 2015 (UTC)
- Please see it like this: using inline or referenced links are just two different style conventions: the ArchWiki happens to use the first one, let's just stick to it and concentrate on the rest, ok? :)
- There is indeed a lack of workforce on the back-end, although I have to acknowledge the fact that Pierre has recently finally pushed MediaWiki 1.24 in the repo, which means it will reach the server very soon; anyway, his policy regarding internationalization has always been the opposite of your proposal, i.e. encourage localized versions to host their own wiki, so your idea would find some opposition there; but even if it didn't, I think you're greatly overrating the state of the external Arch wikis: of them, only the German and French wikis are actually alive, and the German wiki is already maintained by Pierre himself :)
- -- Kynikos (talk) 15:18, 9 January 2015 (UTC)
- Didn't know much about the wiki infrastructure and native language frequentations, but what I've seen on the #archlinux-fr freenode IRC channel, there are some people involved with the French wiki who could be returned to the official wiki, recovering a bit more workforce. Its a great subject for discussion between officials (Pierre) and third parties IMHO. Yes, I'm in complete favour of federating around a same well defined goal: "Unity makes strength", "United we stand, divided we fall" is my country motto. -- wget (talk) 21:20, 13 January 2015 (UTC)
- Well, my personal opinion, which is not an official position because we've never discussed this among the admins, is that I'd be in favour of returning all the translations in the same wiki, but only after implementing Help talk:I18n#Language namespace(s) in place of suffixes? and proving that it works efficiently with the languages that are already hosted here; we should also prove that we can merge the databases of the external wikis safely and effectively. Only after that we could discuss the return of the external languages, stressing the fact that the admins coming from the other wikis should be willing to adapt to the English wiki customs, which I wouldn't take for granted.
- For the first step I'll need to complete some adaptations to my bot, but that's not on high priority at the moment: I have a todo list that I follow more or less strictly, and I promise I'll get there :)
- — Kynikos (talk) 09:51, 15 January 2015 (UTC)
- Another advantage of being able to use <ref> is that one could also add meta information to the URL that's being linked to in order to prevent link rot. Not all URLs are descriptive enough to figure out where they might have gone when they're not reachabe anymore and the Wayback Machine wasn't able to crawl the site. -- Ckujau (talk) 17:07, 16 July 2017 (UTC)
Should we remove or archive obsolete articles?
Ubuntu One is one I stumbled upon. I think it can be safely deleted. -- Karol (talk) 19:22, 30 July 2014 (UTC)
- Could you explain in more details what you mean by archiving and deleting? I am all against completely removing information from public viewing however.
- axper (talk) 15:44, 31 July 2014 (UTC)
- Deleting means we remove the article and archiving means we e.g. lock the page or just add a note / warning at the top, saying that it's obsolete, not used anymore. Initscripts/rc.conf would be another such page. -- Karol (talk) 21:45, 31 July 2014 (UTC)
- Well, Ubuntu One is discontinued and the related AUR packages are deleted, I would really delete it, @axper do you have any particular objections?
- About Initscripts/rc.conf, there has been some work done in init, and its content may be re-used for the initscripts fork?
- -- Kynikos (talk) 06:41, 2 August 2014 (UTC)
- About deleting articles from wiki in general: Any article is documentation and deleting it wrong in my opinion. For example someone might want to design a similar program in the future find the information useful. Or some historian/statistican interested for example why the particular program failed to gain traction. Or Wikipedia or a similar resource might might use our articles for citations. Or the program might still be used by stable/old distros. Or finally, the project might be revived in the future!
- I vote for archiving:
- Add a corresponding notice at the top of the article
- Remove the article from category pages
- Remove all links to that article from this wiki
- Or if Mediawiki has any support for archiving - move such articles to separate namespace/whatever (needs more research).
- axper (talk) 16:32, 2 August 2014 (UTC)
- With MediaWiki, nothing is ever really deleted; deleted pages are just hidden from regular users. IMHO, deleting instead of archiving results in much cleaner wiki in general (mostly categories and search results). Also, unlike deletion, there is no "Archive" button, so every archival solution is very laborious. -- Lahwaacz (talk) 16:55, 2 August 2014 (UTC)
- hidden from regular users has mostly same effects as deleted, because it's accessible only by half a dozen chosen individuals. See the reasoning in my post above.
- About cleaner wiki:
- Categories: Just remove the page from category
- Search results:
- Mediawiki search results: By default only (Main) namespace is searched. So a separate namespace would solve this.
- Google/other search engines: Nothing can really be done (or should be done). If someone searches for "ubuntu one" and finds our archvied page, it's very normal behaviour!
- I don't think moving to separate namsepace is a lot more laborious than pressing "delete" button.
- Solutions other than separate namespace should be considered as well I think.
- axper (talk) 17:52, 2 August 2014 (UTC)
- Any archive would have to be organized in order to be useful. I don't think we have the manpower to do this even if archiving required just clicking a button. Also, I don't think that ArchWiki is intended to be a (partial) archive of any kind.
- Regardless, dead projects are quickly forked if they were really useful and died just because of the maintainer's lack of time, or they are lost forever regardless of the archived documentation. I don't see why we should keep a page about projects dead for ~5 years, the more when upstream has its own documentation archived.
- -- Lahwaacz (talk) 18:12, 2 August 2014 (UTC)
- I counted only 25 (twenty-five) English articles in (Main) namespace marked for deletion as a whole [3]. I don't see how keeping them together unorganized would make them less useful. Anyone interested in them would specifically search for the name in a search engine.
- Why keep pages about dead projects - see my first post above. Besides, this wiki often contains higher quality and quantity documentation than upstream's.
- Now, pages which do not contain any meaningful text whatsoever (like Beginners_Guide_to_C++), it's a different matter.
- axper (talk) 05:13, 3 August 2014 (UTC)
- From Special:Log/delete, we deleted about 300 pages in past 4 months.
- Dig through the out of date pages for usefully information is usually harder than starting from scratch because you need to know what is out of dated and what is not.
- So in theory, you can re-use these pages. In practic they just pollute "What links here" system. I say this with my KDE wiki contributor hat on which does use Archive namespace for out of date pages.
- --Fengchao (talk) 13:29, 9 August 2014 (UTC)
- As I explained below, simple archiving is an inconsistent solution, because when part of an article is removed for some reason (out of date, inaccurate...) it's not archived (though it remains accessible in the history of the article), so there's no reason entire articles should be treated differently. The only solutions that can be considered are those that allow everybody visit the history of "deleted" articles. -- Kynikos (talk) 08:26, 10 August 2014 (UTC)
- Ok, I admit I don't have (and probably there can't logically be) any counterarguments against the generic "it might be useful again in the future" argument, and I guess the whole point here is that the deleted content is no longer accessible to regular users, not even in the history of a page, because it seems noone has anything against e.g. removing outdated portions of articles, or removing closed discussions. This means that both deleting and archiving don't comply with the requirements, do we agree on this?
- The only solution consistent with all this seems the redirection idea proposed below, but in that case the content of those articles wouldn't appear anymore in any kind of search results, so a user interested in retrieving their content should be aware of the existence of both Deprecated pages and of the old page that redirects there. This would however still sort of answer the problem of possibly breaking external links, as following one would lead to Deprecated pages, which in turn could inform the user on what happened to the article (s)he was looking for.
- Considering all this, maybe, and I say maybe, a new policy to address deletions could be to:
- Assess if it's possible to redirect the article to another one, as we're already doing.
- If not, assess if the history of the page is meaningful enough to justify redirecting the article to Deprecated pages instead.
- If not, really delete the article.
- The only new step would be 2., which is not so different from 1., so it could even start making sense. This is a very intricate issue, let's see what the comments to this post will be.
- -- Kynikos (talk) 11:02, 4 August 2014 (UTC)
- What are the security implications of making Special:Undelete available to everyone? See also mw:Help:Undelete. -- Lahwaacz (talk) 11:20, 4 August 2014 (UTC)
- That would indeed be a kiss way of solving the problem. I haven't found any discussions about that, and the only bad implication I can think of is if somebody creates a defamatory article and we delete it, we wouldn't be able to prevent anyone from linking to the deleted revision(s) anyway, thus exposing the wiki to possible legal consequences. However, the same attack could be carried out on an already existing useful article, and the same fix could be used in both cases, i.e. using the "change visibility" feature.
- Maybe we could ask upstream about other possible consequences.
- -- Kynikos (talk) 16:45, 5 August 2014 (UTC)
- Adding Template:Deletion at the top of a page is a reasonable note/warning in these cases, then the admins can go through Special:WhatLinksHere/Template:Deletion and consider each page. Or is this a general discussion about deletion and archival on this wiki, possibly intended to devise a proper archival solution (e.g. separate namespace)? -- Lahwaacz (talk) 14:59, 2 August 2014 (UTC)
- How about making a separate page, Deprecated pages? Any deprecated articles would be blanked, references to them removed, and then redirected to that page. They're "deleted", yet easily accessible via "What links here" should the need arise. -- Alad (talk) 19:28, 2 August 2014 (UTC)
- Seems reasonable to me. axper (talk) 05:19, 3 August 2014 (UTC)
- Why not just visit Special:Log/delete. Any difference here?--Fengchao (talk) 13:32, 9 August 2014 (UTC)
- Seems reasonable to me. axper (talk) 05:19, 3 August 2014 (UTC)
- Well, Special:Log/delete contains (references to) all deleted pages. As Kynikos mentioned, a page like Deprecated pages would only contain articles with notable content in the past, but that is now no longer relevant. -- Alad (talk) 09:07, 10 August 2014 (UTC)
- Exactly. The logs are overdose for the intention. I do like the consideration of having a Deprecated pages for singular cases when the admins evaluate a deletion template as well, if that keeps search history neat & up-to-date. I have a limited view on the topic, but it sounds to me that a separate archiving-namespace would be overkill for this.
- Imho Karol started this discussion with the best examples for both cases: Ubuntu One wiki information will surely float around the web for very long, there is nothing an Arch wiki article about using it with this distro can add after it was shut down. The Initscripts/rc.conf, however, is Arch's own history. Another one like that: I tried to update the non-resolving package links for Pacbuild to no avail. Probably the fellow who created it (and the article) back in 2006 would not mind it being deleted now. Yet, the wiki might want to care about the Arch legacy to that extend anyhow. A buffer like the idea of Deprecated pages could help out there. It could have simple sections (e.g. separating Arch-specific content and other content considered notable in different categories, etc.). I also could imagine cases where it makes the decision easier for the admins - some content could be deprecated first and deleted after a safeguarding time. --Indigo (talk) 20:20, 11 August 2014 (UTC)
- Well, the new "article" would only be used as a redirect target in place of deletions with something like
#REDIRECT [[ArchWiki:Deleted]]. Then in it we would instruct users to look at the WhatLinksHere page to see which articles are linked and browse their history. We can't implement anything more complicated than that, i.e. there would be no content to be separated into sections. -- Kynikos (talk) 14:12, 12 August 2014 (UTC)
- Well, the new "article" would only be used as a redirect target in place of deletions with something like
- Ah, thanks for clarifying. Picking up another thought from above not clear to me: Given we cannot distinguish the
#REDIRECT [[ArchWiki:Deleted]]from the extensively employed regular redirects to guide to most relevant current content. Might it happen that, e.g. after pursuing that route for a year or two, those redirects start to spoil/pollute search results for the regular user seeking only current content? Or is that not a problem (e.g. due to amount of pages we anticipate to deprecate like that or maybe we can control somewhere that they are only listed at the bottom of search results)? Or is the extra effort small enough to justify testing it out and change route in case it does become a problem (and we might profit from the deprecate-delete decisions already been taken)? --Indigo (talk) 21:39, 12 August 2014 (UTC)
- Ah, thanks for clarifying. Picking up another thought from above not clear to me: Given we cannot distinguish the
- This discussion may be related ... -- Alad (talk) 21:44, 12 August 2014 (UTC)
- Well, the content of those "semi-deleted" articles wouldn't be parsed by the search engine, so only their titles could constitute a problem in search results. Now, it's unlikely that titles like "Ubuntu One" could pollute the search results for other still-alive terms, and in case some of them did, that would probably mean that instead of "semi-deleting" them, we should have redirected them to some other related article (see step 1. in the checklist in one of my posts above).
- Anyway if this became a problem in the future, all the semi-deleted articles could be quickly and easily finished off with a bot.
- -- Kynikos (talk) 01:58, 13 August 2014 (UTC)
- This discussion may be related ... -- Alad (talk) 21:44, 12 August 2014 (UTC)
- @Alad: Yes, it is - ensuring quality of the regular redirects is not spoiled longterm.
- @Kynikos: Ok, I take from that the extra redirect can be a worthwhile exercise to try and see. Something that cannot be done with the fourth option without more certainty about consequences.
- Re "finished off with a bot": and the tagging as "semi-deleted" could also be useful to recycle the bunch another way (e.g. if route is changed to something else than "delete" for whatever reason).
- Now for the fourth identified option to publicize Special:Undelete I wonder about search accuracy as well: would turning it on spoil internal search results? (no) How about external search engines? Any chance those get confused and suddenly index deleted content that they don't crawl now? --Indigo (talk) 20:29, 13 August 2014 (UTC)
- You've answered the first question: no.
- Second question: to view the content of a deleted revision, a POST request is needed, and that's something that search bots don't do, at least the normal ones. But even if that wasn't the case, history pages, old (not top-level) revisions and deleted revisions (and many other kinds of pages) all have
<meta name="robots" content="noindex,nofollow" />in the head, which allows me to confidently answer "no" as well.
- -- Kynikos (talk) 04:31, 14 August 2014 (UTC)
- When redirecting the page to Deprecated pages, the operation would be (btw. see the table below for comparison with other solutions):
- Update/remove all backlinks (as is done today when deleting a page)
- Redirect the page
- Protect the archived page to prevent updates
- I'm assuming here that the solution should be similar to the current way in that archived pages should not be updated and that archived pages should not be linked. And this is the problem, we can't technically prevent linking to archived pages if we choose this solution.
- -- Lahwaacz (talk) 23:16, 13 August 2014 (UTC)
- When redirecting the page to Deprecated pages, the operation would be (btw. see the table below for comparison with other solutions):
- I'm not sure if protection is needed, after all deleted articles can be freely recreated, so semi-deleted articles shouldn't have a higher level of protection.
- About links, the fact that the semi-deleted articles are redirects that point to ArchWiki:Deleted should already discourage linking to them. The same goes for any kind of links, we can't technically prevent any kind of nonsensical links, I think that's an unrelated problem. Yes, it's possible that somebody links to an old revision of the semi-deleted article with an external link, but that's already true for the old revisions of the existing articles.
- -- Kynikos (talk) 04:31, 14 August 2014 (UTC)
- Right, when we provide an archive, it should be possible to link to the archived revisions. Anyway, there could be a difference between redirecting and deleting as it seems that I can't link to specific revision of a deleted article - the preview button from [4] just gives this url:
- -- Lahwaacz (talk) 11:15, 14 August 2014 (UTC)
- Right, when we provide an archive, it should be possible to link to the archived revisions. Anyway, there could be a difference between redirecting and deleting as it seems that I can't link to specific revision of a deleted article - the preview button from [4] just gives this url:
- There is a difference, you can't link to a fully-deleted revision because only its plain source text can be queried normally (mw:API:Deletedrevs and mw:API:Undelete#Token), so the rendered page can only be previewed (I guess with the same algorithm that previews normal pages being edited), which requires a POST request (i.e. no parameters visible in the url => unlinkable). This is another parameter for the table below; I'm not sure if the ideal solution should allow linking or not. -- Kynikos (talk) 14:52, 15 August 2014 (UTC)
- About protection, is the ideal solution controlled (i.e. admins (+maintainers?) control which pages will be archived/restored) or open (where anybody can archive/restore a page)? I don't see a problem with controlled as users could ask for the operation to be performed. On the other hand, open archival could bring problems. I think that ideally archival would be controlled and restoration open.
- -- Lahwaacz (talk) 11:15, 14 August 2014 (UTC)
- IMO we should use MediaWiki's default behavior: if we go for the visible deleted revisions, then the archiving operation is a deletion which by default is controlled; if we go the ArchWiki:Deleted way, then the archiving operation is a redirection which would be patrolled just like any other redirection for any other purpose, so it could stay uncontrolled. The same could go for restoration, although if we allow everybody see the source of deleted revisions, it's not necessary to have undelete rights to restore the article, it would be enough to just re-create the article by pasting the source there (I know, it wouldn't be the proper way because all the history would be lost). -- Kynikos (talk) 14:35, 15 August 2014 (UTC)
Why exactly was the "separate namespace" way discarded? Was it FS#35545? -- Lahwaacz (talk) 23:20, 13 August 2014 (UTC)
- Apart from 35545, if I understand correctly the "separate namespace" solution would consist in moving the candidate articles into a special namespace without hiding their content with a redirect; yes, all their backlinks would have been cleared, but they would still keep linking to other articles, thus polluting those articles' backlinks, and also some special pages, and that's something that I'd like to avoid. -- Kynikos (talk) 04:31, 14 August 2014 (UTC)
I have modified the row "Permission to perform archiving" for the "ArchWiki:Deleted" way to be simply "editors", which is the least privileged group which could perform archiving under ideal circumstances. There are some cases when editors wouldn't be able to perform the operation by themselves: for example if the archived page had some redirects pointing to it, they should be deleted, because archiving would create a double redirect and "normal" fix would cause the redirects to be archived too, which is useless since there is usually no history.
Also note that archiving would most likely involve more people from different groups: for example everybody could propose a page to be archived, then after reaching a consensus, admins/editors would archive the page, then editors/patrols would check the operation etc. This is not a good material for the table below since it applies to all methods, however it should be discussed because we will have to write guidelines for the archiving anyway.
-- Lahwaacz (talk) 19:53, 16 August 2014 (UTC)
- I agree with redirects, they should be deleted when archiving their target, unless for some reason they can be diverted to some other article.
- And yes, we should really start writing guidelines not only for archiving, but also for the other common operations (creating/moving/deleting a page, moving a section in the same article or another article, generic redirection...), something like already exists in ArchWiki Translation Team#Create a new page and its translation.
- -- Kynikos (talk) 03:36, 17 August 2014 (UTC)
- Absolutely, we need to cover that. @Lahwaacz: Also all good with just "editors", but one step we want in the process is the decision about "notable content" in that column, no?. E.g. (1) Karol identifies Ubuntu One as deprecated, (2) ideally proposes a method (redirect or delete) due to content in the template, (3) the delete gets no objections. Now at the latest that "archiving" (deletion in this case) proposal should get to the admins to review/perform. (Just wondering if the simplest would be to use two redirect templates at that point, i.e. "Archwiki:Deleted" and "Archwiki:Obsoleted" or something, but might be totally unnecessary). I must say I am curious what the others think about the current table!? any objections we concentrate on column 3/4? --Indigo (talk) 10:58, 17 August 2014 (UTC)
- Yes, the decision step about notability should be in the guidelines.
- I'm not sure what you mean about the "Archwiki:Deleted" and "Archwiki:Obsoleted" pages: in case we go for the redirect solution, obsolete pages will be redirected to the dedicated "ArchWiki:..." page if they have a notable history, otherwise they will be normally deleted like we're doing now.
- Are 3/4 0-based indices? Just to make it clear, I'd concentrate on the last 2 columns.
- -- Kynikos (talk) 01:46, 20 August 2014 (UTC)
- When I added above rough idea quoting "Archwiki:Deleted" and "Archwiki:Obsoleted" I was thinking again about the easiest workflow to distinguish the decision to either archive or delete. Sticking to "Ubuntu One": how do you get to know that (1) the deletion proposal had no objections and (2) it's time to delete it.
- To my understanding the admins currently either consider a deletion template set by others by running across it, or by getting notified individually. The idea was that using two new redirect templates (deleted/obsoleted) instead of one, the two buckets could be filled - each to be reviewed at its own pace. Clearer? --Indigo (talk) 07:40, 20 August 2014 (UTC)
- Then you have used the wrong prefix, you meant "Template:Deleted" and "Template:Obsoleted". There is already Template:Deletion, so I would use "Template:Archival" for the new template. Maybe it would be clearer to use just the verb: "Template:Delete", "Template:Archive", "Template:Move", Template:Merge... -- Lahwaacz (talk) 10:46, 20 August 2014 (UTC)
- Uhm, with "two buckets" I actually meant two new redirect targets: one for semi-delete/archive (column 3), one for delete. If the delete-redirect would be set by an editor, the admins only have to check that bucket for new redirects and review/delete those articles. Likewise for the semi-delete/archive (column 3) redirect the notable content decision would be checked.
- Using two templates for the distinction instead, you in your admin role still have to track status of the deletion template(s) across the wiki somehow, your fellow admin maybe does it as well, etc. Maybe it is clearer, if you see the two redirect-targets as patrol-points.
- Does that make sense/sound practical? (I may well be over-engineering our case:) --Indigo (talk) 14:16, 20 August 2014 (UTC)
- I think that you over-complicate things here... Unlike archival, deletion is a core feature of MediaWiki, there is no need to use the redirect-to-some-dummy-page workaround. Using the MediaWiki's feature, deleted pages are just "gone" for the regular users (at least until the fourth/last column is implemented). Obviously the solutions in columns 3 and 4 (redirection and deletion) can't be combined, redirecting a deleted page would make it undeleted.
- We are trying to devise a solution for archiving pages, which is not implemented directly in MediaWiki, so let's focus the discussion on this topic. Also, for now I would like to focus on choosing the archiving technique (the technological solution), the guidelines (user interaction, used templates etc.) can be discussed later as this will inevitably depend on the chosen technique.
- -- Lahwaacz (talk) 21:28, 20 August 2014 (UTC)
- After reading your post again, another idea occurred to me: perhaps you meant the problem of differentiation between deleted and archived pages? This is a problem exclusively for the last method, i.e. archiving by deleting. If we wanted to somehow distinguish archived pages from "normal" deleted pages, it would be likely done by the "Reason for deletion" (see mw:Help:Sysop_deleting_and_undeleting), which would store the information in the Deletion log. We could probably mark the pages with appropriate template before actually deleting it, but using the "Reason for deletion" seems more natural and useful. -- Lahwaacz (talk) 21:49, 20 August 2014 (UTC)
- Thanks for taking the time for above too Lahwaacz. Sure, this can wait. To your question: yes, that's what I meant. I'm going to stop about it, but just a tiny example: User:Indigo/Test1. Now for the example the admins would only have to check the backlinks of that redirect, review & delete (with "Reason for deletion" as usual). We could also use such for the last method as well I believe, if at all useful. --Indigo (talk) 19:50, 21 August 2014 (UTC)
- We can re-use the advice to fix the link that led the user there in the redirect for simply-archived pages, although it will make sense only for external/full links, as a good admin will have fixed all the internal backlinks before archiving or deleting an article. About your idea in general, we can already check Special:WhatLinksHere/Template:Deletion, there's no need for a "temporary redirect" after the page has been marked for deletion. -- Kynikos (talk) 13:59, 22 August 2014 (UTC)
- I think we should delete Ubuntu One article, because it is no need anymore. Also, please delete Ubuntu One (Русский) article too. Agent0 (talk) 08:19, 3 October 2014 (UTC)
- Help talk:Procedures#Deal with talk pages after redirecting a page to another is related. — Kynikos (talk) 01:37, 2 January 2016 (UTC)
List of suggested solutions
A table of additional properties to follow the discussion more easily:
(current method, not a solution)
|Redirect to a page like
|Publicize Special:Undelete
|Type of archive operation
(i.e. modify content, then protectquestioned)
|Permission to perform archiving
|depends on config
|Permission to undo archiving
|depends on config (?)
(can be forced w/ copy/paste)
(can be forced w/ copy/paste)
|Page titles show in wiki search results
(if redirects are included)
|Page content shows in wiki search results
|Page titles/content show in external search results
(unless disabled
with 1 or 2)
|Secure (see discussion)
(ask upstream)
|Pollutes other pages' backlinks and special pages
|Can link to archived revisions
In light of recent issues, I'd say it's time to finalize this discussion: anyone against enforcing the ArchWiki:Deleted redirect way? The new "deletion" procedure would be:
New but inappropriate articles:
- If inappropriate because of spam or other clearly malicious content (evaluation is made by an admin), it's deleted right away.
- In most of the other cases the article should be moved as a subpage of its author's User page.
Old articles gone deprecated:
- Mark for deletion;
- Wait at least 7 days: in absence of discussions/objections, redirect to ArchWiki:Deleted.
Double redirects might be created after redirecting to ArchWiki:Deleted: these will have to be deleted, unless for some reason they contain part of the history of their targets; in this case a merge should be considered, or the redirect should be moved to a "Target page (redirect[0-9]+)" title and redirected to ArchWiki:Deleted too, thus making it clear where to look for the more recent history.
In both cases, all the backlinks to the deleted or semi-deleted page will have to be removed.
I've left out the "notability" assessment (redirect if notable, fully delete if not) as there can't be objective guidelines for the choice and it might unnecessarily expose the responsible admin to complaints.
The ArchWiki:Deleted page (better title proposals will be considered) must be initialized with an evident link to its WhatLinksHere page.
I think it would make sense to start a campaign to restore articles that are currently in a deleted state; requesting restorations should be explicitly made possible in ArchWiki talk:Deleted.
Do we want to rename Template:Deletion to Template:Archive or similar?
We'll also need a news entry to make this official,
I'll probably get there by the upcoming weekend in absence of substantial objections. Please help improve the procedure in case I missed something: it will have to be moved to Help:Procedures once enforced.
— Kynikos (talk) 06:09, 6 May 2015 (UTC) (Last edit: 03:02, 21 May 2015 (UTC))
PS: We must also address the problem of what to do with the talk pages of deleted articles, since I've seen discordant actions recently. — Kynikos (talk) 06:18, 6 May 2015 (UTC)
PPS: I'd also like to better define "inappropriate", and at the same time give a more liberal and inclusive definition of "Stub", possibly shifting a bit our traditional perception of short-and-ugly articles, giving them more chances of being expanded/improved by other users than the original authors. Please share your ideas. — Kynikos (talk) 06:33, 6 May 2015 (UTC)
- Well well, the recent, unfortunate loss of all the deleted revisions pushed me to finally enforce this new policy, since we cannot consider the deletion of an article like moving it to the "trash bin" anymore.
- This is the list of the new articles:
- This is the list of related changes:
- I don't think we need a News entry as I suggested above.
- Please comment here, or in an existing or new subsection, since I'd be surprised if I didn't forget anything in such a big change.
- — Kynikos (talk) 10:07, 7 February 2016 (UTC)
- Regarding the icons, perhaps we should upload a new one for Template:Archive and leave the old one for Template:Deletion/Template:Remove. We could use Wikipedia's archive icon, or if it has to be from the Tango set, there is [5]. File:Tango-edit-clear.png would be suitable for Template:Style, the current File:Tango-mail-mark-junk.png has very low contrast on the background.
- -- Lahwaacz (talk) 10:34, 7 February 2016 (UTC)
- For Template:Deletion I was looking for an icon that remarked the fact that deleting is not like throwing into a bin. Besides, if we go down the path I've proposed in #Rename Template:Deletion, the template wouldn't practically be seen around anymore, therefore the choice for its icon would be practically irrelevant. That said, we can always start a poll about it, I wouldn't mind keeping the old icon. For the records, there's also File:Edit-delete as a possible candidate.
- Another interesting possibility could be to swap the icons between Template:Style (which would then use edit-clear, as you said), and Template:Deletion (which would then use mail-mark-junk).
- About Template:Archive, if we want to use a file manager icon, I'm ok with it, but still prefer the bin icon, it's just more meaningful to me ^^ (do we start a poll?)
- — Kynikos (talk) 14:13, 7 February 2016 (UTC)
- I'd really use a different/new icon for Template:Archive - at least for me the trash icon is connected with deletion as the action/method and not with archiving stuff. Using new icons also for Template:Deletion and Template:Remove is another matter, it might be good to (temporarily) decommission the trash icon altogether. -- Lahwaacz (talk) 14:35, 7 February 2016 (UTC)
- Instead of the cabinet/file manager icon, we could also use File:Tango-format-text-bold.png for Template:Archive ;) -- Lahwaacz (talk) 14:59, 7 February 2016 (UTC)
- +1 on using the "broom" icon for Template:Style. It both looks better, and adds to the positive reinforcement already given by the template text (hints at cleaning up, rather than throwing away).
- I personally like the "scissors" icon for Template:Remove. Removing an article section can be seen as 1. cutting out a paper section, and 2. moving it to a folder (the article history).
- I'm neutral on what icon to use for Template:Deletion, if we decide to keep that template at all.
- About Template:Archive, maybe we can go with a mix between both suggested icons, e.g [6] or [7] or [8]
- -- Alad (talk) 15:26, 7 February 2016 (UTC)
- So, I've followed your suggestions and updated the icons of Template:Style, Template:Laptop style, Template:Archive and Template:Deletion. About Template:Archive I've chosen the box icon instead of the cabinet because it has better colors IMO :)
- I agree with "decommissioning" the trash icon, at least until we get used to the new deletion policy.
- Then, while we're at it (probably controversial...), I was thinking about also updating the icons for Template:Out of date with File:Tango-out-of-date-clock.png, and for Template:Accuracy with File:Tango-inaccurate.png (currently both are using generic exclamation marks that don't represent the meaning of the templates to great extent, although of course we learned to associate the meaning automatically through time).
- — Kynikos (talk) 11:14, 8 February 2016 (UTC)
- The new icon for Template:Accuracy looks similar to the orange exclamation we have now, yet accurately represents the meaning ("needs more investigation"). As I doubt there's much to argue against it, I've went ahead and changed the template.
- I'm not sure on the appearance of the clock icon. As an alternative, [9] has the same "out of date" triangle, but with otherwise bland colors.
- -- Alad (talk) 20:45, 9 February 2016 (UTC)
- Accuracy does look better now! About Out of date, I've found File:red-clock.png and couldn't resist to try it immediately, it has the same colors as the old triangle icon, but with a clock, I think it's perfect :) As an alternative, I can easily add the old triangle icon in a corner of any clock svg icon with Inkscape. SANE#Permission_problem shows the two updated templates in action together. — Kynikos (talk) 07:36, 10 February 2016 (UTC)
- I was liking the old File:Tango-dialog-warning.png very much for its simplicity. File:red-clock.png also looks quite simple, I wouldn't combine it with any other emblem. But I don't quite get the connection between outdated articles and clocks - they are often enough outdated for years and not hours or minutes. Maybe we need a red calendar emblem? -- Lahwaacz (talk) 07:51, 10 February 2016 (UTC)
- Eheh ok, maybe I could have spared the hourglass suggestion, every status template evokes waiting until somebody updates the section ^^
- If you prefer a calendar, I won't have problems at modifying an icon like [10] o [11] by reshaping it, changing the colors, or even adding emblems if we want. How would you give it a clear "out of date" meaning in analogy with the current clock icon?
- — Kynikos (talk) 03:47, 11 February 2016 (UTC)
- Update: I've made a red version of Tango's refresh icon, uploaded it at commons:File:View-refresh-red.svg, and installed it in Template:Out of date. — Kynikos (talk) 08:34, 13 February 2016 (UTC)
- And to avoid confusion between ArchWiki:Archive, Category:Archive and Template:Archive, perhaps we should use "Archived" or "Archived pages" for the first two?
- -- Lahwaacz (talk) 10:34, 7 February 2016 (UTC)
- I don't have a very strong opinion about this, I don't find the current titles confusing (maybe because I've created them eheh), this could call for another poll, as I don't see how useful it would be to wait for people to struggle to find new arguments in favor or against and hope to win the debate ;) — Kynikos (talk) 14:13, 7 February 2016 (UTC)
Restoring revisions and redirection
About restoring revisions deleted in the past, we can use mw:API:Deletedrevs to list and filter them. — Kynikos (talk) 03:05, 9 May 2015 (UTC)
- It's good you changed your mind. It would be a pretty major change and we sure need not only to discuss the details, but also play with it. I'd even say before such a change is done, the admins should use it first only in order (1) to ensure it is straight-forward/KISS enough to perform and (2) to extrapolate how it may turn out. Still, I would find it beneficial and reasonable, if the status quo (detailed in/above the table) could be fixed in the meantime. Not to disturb with this request, I have opened Template talk:Deletion#Expansion on deletion process for that.
- To your above proposal: I like it, except for seven days seem too quick for the wiki. I'll return too if I have input/ideas. --Indigo (talk) 05:34, 9 May 2015 (UTC)
- Well, redirecting to the new "dustbin" is not something that we can prevent normal users from doing; perhaps we should run an "experimentation" session after approving the procedure, but before adopting it publicly. If we change our mind, it shouldn't be hard to fully delete the redirects.
- About the waiting period, since the articles could be restored by anyone (and their history browsed as easily), I thought that 7 days would be enough, but we can open a poll for that.
- — Kynikos (talk) 04:42, 10 May 2015 (UTC)
- So, I've put 7 days in Help:Procedures#Remove an entire page for the moment, are there different ideas? — Kynikos (talk) 14:13, 7 February 2016 (UTC)
> anyone against enforcing the ArchWiki:Deleted redirect way?
Since it is the only method that does not involve waiting for
Godot Pierre, it seems logical to at least try it. After all, returning to the current method in case of dissatisfaction would involve only deleting the restored pages.
Since we want MediaWiki to do something it is not built for, there are many issues. The most outstanding is the limited control over the archive. We've had disagreements in the maintenance team, imagine what might happen when everybody is technically, not per policy able to archive pages.
-- Lahwaacz (talk) 21:43, 9 May 2015 (UTC)
- Well, technically everybody is already able to redirect whatever page wherever they want: I don't think that enforcing this new deletion policy would encourage that, and the current patrolling that we're already doing should be enough to catch violations. In case of unresolved disagreement, an admin's opinion should always prevail, otherwise it's a jungle, but that's true for every kind of edit. — Kynikos (talk) 04:49, 10 May 2015 (UTC)
- Sorry for humbly insisting, but what I'm saying is instead that the area that needs to be checked will not expand, since everybody is already free to redirect any article at their own will, so I don't see how enforcing this new policy would make it more likely to miss a misredirection, be it to ArchWiki:Deleted or anywhere else :)
- Redirection diffs look like this, pretty hard to miss, and they're also usually accompanied by a bold-red negative byte count in RecentChanges, something that always immediately attracts my attention.
- — Kynikos (talk) 11:19, 11 May 2015 (UTC)
As another note on the redirect method, it should be mentioned that even redirects can be categorized, which could be utilized. -- Lahwaacz (talk) 21:43, 10 May 2015 (UTC)
- Additional note: I think on the ArchWiki:Deleted page we should encourage users to re-redirect the "deleted" titles to more appropriate existing pages, when possible. — Kynikos (talk) 03:35, 22 November 2015 (UTC)
- About categorization, ArchWiki:Archive now suggests to use Category:Archive. — Kynikos (talk) 14:13, 7 February 2016 (UTC)
Separation of archive content
Next issue is with separation of the archive from the normal content. Since your proposed way of dealing with double redirect involves messing with the pages' histories and titles, there is inevitable need to organize the archive. I think that "ArchWiki is not a muzeum" should still apply regardless of the chosen archival method, ideally the motto would be as easily followed as it is now.
Ideally the archive functionality would be built into MediaWiki itself (or any other backend we might use in the future), but publicizing Special:Undelete is the closest (also accidentally keeping the maintenance burden on minimum). As far as I learned since the last summer, the "security" consideration could be dealt with by deleting an individual revision instead of the whole page, for which there is a separate
deleterevision right.
-- Lahwaacz (talk) 21:43, 9 May 2015 (UTC)
- Can you please elaborate on the "need to organize the archive" part? How would the new policy influence "separation of the archive from the normal content"? — Kynikos (talk) 04:54, 10 May 2015 (UTC)
- In the first post in #Enforcement you described how double redirects would be managed, which suggests that the archive would be organized (at least a little) in order to allow easier searching. When a page is restored, either with updated or completely new content, it would make sense to also restore these "archived redirects", otherwise we risk having the same titles in the archive and the main namespace. But what if a page with the title of the former redirect is restored? Everything could be likely managed with the merge feature (and it may be interesting to find its limits), but the point is that all this seems like a lot of work for little benefit. Browsing the archive will never be a cakewalk due to broken links and old templates. -- Lahwaacz (talk) 20:33, 10 May 2015 (UTC)
- The problem of redirects to deleted/restored articles is already present: what we're doing now is simply delete/restore them without taking care of renaming, merging, etc. The procedure that I've outlined above tries to address such problem, but it's actually disconnected from the deletion method itself (full-deletion, redirect...), so if we feel it requires too much effort for little benefit, and you may indeed make a point there, we can just go back normally fixing the double redirects, and this wouldn't affect the practicability of the redirection delete method. After all, in theory redirects to a deleted article can still be found by e.g. browsing the contribution history of the "deleter" and looking at the edits that were made around the deletion date, since, if the article was properly deleted, those redirects will have been edited at the same time. — Kynikos (talk) 11:38, 11 May 2015 (UTC)
- We can also nuke the wiki a la AUR3 -> AUR4 ;P
- Every year we're going to suggest which articles should be kept and the rest is going to e.g. 2015-archive (read-only?). Every article in the archive should have a template at the top saying it's outdated and users are encouraged to update them in the main namespace.
- I think there's little reason to put the wiki on such a harsh diet and the separation could discourage users from touching the old articles at all. Some content may have been rephrased and merged into other articles and instead of using our old 'deletion' and 'merge' templates and having a history of what has been moved where, we would be stumbling on missing or duplicate content more than we do now. -- Karol (talk) 13:22, 8 August 2015 (UTC)
- The problem of redirects to deleted/restored articles is already present: what we're doing now is simply delete/restore them without taking care of renaming, merging, etc. The procedure that I've outlined above tries to address such problem, but it's actually disconnected from the deletion method itself (full-deletion, redirect...), so if we feel it requires too much effort for little benefit, and you may indeed make a point there, we can just go back normally fixing the double redirects, and this wouldn't affect the practicability of the redirection delete method. After all, in theory redirects to a deleted article can still be found by e.g. browsing the contribution history of the "deleter" and looking at the edits that were made around the deletion date, since, if the article was properly deleted, those redirects will have been edited at the same time. — Kynikos (talk) 11:38, 11 May 2015 (UTC)
- I've noticed the discussion got stuck (unless I'm overlooking something), so I wanted to prod it, to see if it's still alive ;P
- Yes, it's the 'separate namespace' idea and I think other ideas are a bit better, especially the 'publicize Special:Undelete' way. Any news from that front?
- I agree that the separate namespace is not the greatest idea, but "Page titles show in wiki search results" would be a better argument if the wiki search didn't require wading through results I don't care about as it is. "Pollutes other pages' backlinks and special pages" could be solved by removing some links but that's either more manual work or a fancy bot that would mark these backlinks as 'linking to archived content'.
- Tl;DR: is this horsie dead yet? ;-) -- Karol (talk) 09:26, 19 August 2015 (UTC)
- To combine the "Separate namespace" and "Publicize Special:Undelete" suggestions, we could create an external archive hosted e.g. on Github, including only the deleted pages (either all or manually selected). The history of wikicode could be kept in the master branch and the rendered static HTML pages could be in the gh-pages branch and accessible from github.io. The pros: does not pollute other pages' backlinks nor special pages and it is faster to implement than publicizing Special:Undelete (although my knowledge of git is so far too limited to do it). The cons: can you think of any?
- Sorry, I think the horsie has still many years ahead :P
- -- Lahwaacz (talk) 10:11, 19 August 2015 (UTC)
- Linking to archived/deleted pages would be at least discouraged in any case, but technically linking to external archive would be possible with an interwiki link, which is syntax-wise identical to the separate namespace solution. On the ArchWiki backend side, an entry in the interwiki map would have to be created.
- The other way round, the links from the archived pages could be mangled automatically by the export script to always point either to ArchWiki or the archive, something similar is already done in arch-wiki-docs.
- -- Lahwaacz (talk) 14:58, 19 August 2015 (UTC)
- Honestly I think we're losing sight of the real problem, leading to an overengineering of the solution: every day there's a lot of content that is deleted from the wiki, even if the articles it belongs to aren't deleted themselves (outdated sections, closed discussions, ...). If content gets deleted, there is usually (and hopefully) a good reason, and MediaWiki gives natively a way to retrieve it with the lists of article revisions.
- Our problem number (1) is that we currently have 2 kinds of deleted content, accessible and inaccessible, and this distinction doesn't reflect the nature of the deleted content at all. Eliminating this distinction is IMHO what we should first focus to do. If we create an external archive to make inaccessible revision lists accessible, I don't think we fix the problem, but we complicate things even more. We have to make all revisions visible on this wiki (redirects, separate namespace, special:undelete?).
- Then, once (1) is fixed, we're left with problem number (2), i.e. the fact that there isn't a search engine that (optionally) also looks through text in non-top-level revisions. This would be a great idea for a MediaWiki extension, or alternatively a service that could indeed be performed by a bot, probably on a per-article basis, since the database of all the revisions of all the articles would be too big to be queried/downloaded at every search.
- — Kynikos (talk) 11:30, 20 August 2015 (UTC)
Double redirects
I agree to most of the procedure. For double redirects, I vote for just delete them. Check their history is to much effort. --Fengchao (talk) 13:04, 27 May 2015 (UTC)
- Maybe the procedure I devised for double redirects should be executed by a bot, it shouldn't be too hard to program it. In that case, the policy would be to not fix double redirects to ArchWiki:Deletion manually, and the bot could be run daily or weekly. — Kynikos (talk) 03:59, 28 May 2015 (UTC)
- For the moment ArchWiki:Archive is simply suggesting to do fix the double redirects normally, i.e. point them to that very page. — Kynikos (talk) 14:13, 7 February 2016 (UTC)
- Related discussion above in #Separation_of_archive_content. My issue with "archiving" double redirects is that they usually have little to no history, so it'd be harder to find the "actual" archived article. -- Alad (talk) 16:29, 7 February 2016 (UTC)
- It's possible that I haven't understood your post, but finding the previous target of an archived redirect (is that what you mean with '"actual" archived article'?) should be trivially done by looking at what article its 2nd-to-last revision was pointing to, right? :)
- The only issue I see with archiving double redirects is the opposite thing, i.e. retrieving the original redirects of a given archived article. This problem could be solved by prepending the target article name to the redirect title, so that they appear together in Category:Archive, but it would probably not be worth the effort.
- In ArchWiki:Archive I've written to also blindly archive all the double redirects, but it should be better to indeed stick to the original plan, i.e. just delete them if they contain no history; otherwise attempt a merge (and then still delete); if merging isn't possible because of conflicts, then maybe we can suggest to put links at the top of the "main" archived article that point back to all the unmerged ex-redirects.
- — Kynikos (talk) 12:47, 8 February 2016 (UTC)
Rename Template:Deletion
As for the Template:Deletion --> Template:Archive renaming, I think that we could make use of both. After all archiving does not fully replace deleting, there are more reasons for deletion (archiving is currently one of them). Moreover, Template:Deletion can be used to flag sections, whereas Template:Archive is/will be only for the whole pages. In a similar fashion, I think that the master page should not be called ArchWiki:Deleted but ArchWiki:Archived. -- Lahwaacz (talk) 15:18, 1 June 2015 (UTC)
- Regarding Template:Deletion being used per section there is no confusion now & there is the template reason. Introducing something like ArchWiki:Archived easily gives the wrong impression about what ArchWiki:Deleted is about for starters. Besides, I am pretty sure most editors will be very hesitant to perform a deletion. Maybe something like a separate template is useful at some stage, but it should be easier to see how it goes and figure an enhancement then - not? I agree regarding the reasons for deletion; it should be clear only content pages are subject. --Indigo (talk) 18:09, 1 June 2015 (UTC)
- True, Template:Deletion will have to stay in any case, at least for sections only. I didn't think of that, so now I feel that having a separate Template:Archive could complicate things a little too much: I'm not sure what side I support now, maybe adding Template:Archive is something that we could implement later as Indigo says?
- If we decide to have both templates, maybe we should reconsider Template talk:Deletion#Rename and indeed rename "Template:Deletion" to "Template:Delete" so that it's more consistent with "Archive".
- I agree MediaWiki:Deletereason-dropdown should be updated.
- Regarding ArchWiki:Archive (which I think I'd prefer to "Archived") I think I quite like it, and maybe we could use that title even if we decide to keep using Template:Deletion to mark pages for archiving; I don't think that would create confusion. On the other hand, I'm not sure if this is what Indigo was saying, but ArchWiki:Deleted could indeed be more effective at preventing users from redirecting pages there without permission. In this case, perhaps we could start with ArchWiki:Archive and keep ArchWiki:Deleted as a plan B to implement in case we see that people misunderstand its purpose and the related archiving guidelines/procedure.
- — Kynikos (talk) 13:19, 2 June 2015 (UTC)
- So, the way I've implemented the archiving of pages is with ArchWiki:Archive as the redirect target, and 2 more templates besides Template:Deletion:
- Template:Archive should be used to propose the archiving (redirection to ArchWiki:Archive) of an obsolete page;
- Template:Remove should be used to propose the removal of a portion of content from an article, replacing the use of Template:Deletion for this purpose; the reason why I've chosen to implement a separate, specific template for this is that:
- the word "delete" has a special, very different meaning in MediaWiki, and I want to avoid any confusion with it;
- when applied to a whole article, a removal request (now "archiving") is a very different operation, and using the same template only because of language limitations/shortcuts seemed confusing as well;
- About Template:Deletion, I've left it alive for the moment, but my intention would be to change all its current instances to either Template:Remove or Template:Archive, as appropriate. Then, for the future, if the new procedures are followed properly, when an admin decides to really delete an article there should be such evident and unobjectable reasons for doing it (e.g. spam) that marking the page for deletion and discussing it should never be a real possibility. For this reason honestly I'd even like to propose deprecating Template:Deletion eventually, and redirecting it to Template:Archive (also merging its history there, probably).
- — Kynikos (talk) 14:13, 7 February 2016 (UTC)
- So, the way I've implemented the archiving of pages is with ArchWiki:Archive as the redirect target, and 2 more templates besides Template:Deletion:
- I generally agree with the plan, but there are stil legitimate uses for Template:Deletion: for example when there are pending actions needed before deleting it (e.g. when Special:WhatLinksHere still contains some/many pages: Category:Network managers or Template:Article summary start), or by users to request deletion a page in their user space or generally to gain attention of the admins. -- Lahwaacz (talk) 15:16, 7 February 2016 (UTC)
- I'd also agree we should move forward with Template:Remove and Template:Archive. That said, I don't see an obvious solution here: on the one hand it's true that Template:Deletion has legitimate uses, on the other hand there's some overlap (and thus possible confusion) with the section-only Template:Remove. Maybe rename Template:Deletion to something else, but with the MediaWiki Delete action named as such, there's little playroom. -- Alad (talk) 16:19, 7 February 2016 (UTC)
- edit: At the moment both Template:Deletion and Template:Remove have very few backlinks, so it's easy to make changes either way. -- Alad (talk) 16:22, 7 February 2016 (UTC)
- If kept, Template:Deletion would be page-only and Template:Remove section-only. But the names are confusing nonetheless... -- Lahwaacz (talk) 19:48, 7 February 2016 (UTC)
- -1 to keeping Template:Deletion, it really is ambivalent naming now. How about proceeding like Kynikos proposes, slightly expanding the first bullet of Help:Procedures#Remove an entire page for its legitimate uses? e.g.
- if inappropriate because of spam or other clearly malicious content mention SPAM in the template (evaluation is made by an Administrator), it is deleted right away. You can also request outright deletion of content on your personal user-space in the template, if you choose so;
- Without wanting to complicate existing procedure: It may be a little tricky with user-space (e.g. collaborative editing, copied wiki content, etc.), but (as an example) under local law here users have a legal right for deletion (not that many services care about it).
- -- Indigo (talk) 09:00, 8 February 2016 (UTC)
- -1 to keeping Template:Deletion, it really is ambivalent naming now. How about proceeding like Kynikos proposes, slightly expanding the first bullet of Help:Procedures#Remove an entire page for its legitimate uses? e.g.
- First, thank you Alad for already changing most of the Template:Deletion transclusions; I've completed the task, and currently its only transclusion is in its own page as an example (ready for final deprecation ;) ).
- The only place where we still link to — and suggest to use — Deletion is in Help:Procedures#Rename a category (and Help:Style where it references that procedure): I think in that case we can recommend to use Template:Archive with a proper edit summary instead, since it's such a rare operation that it can't be enough to justify keeping Deletion alive.
- About the other mentioned possible valid reasons to use Deletion, I actually agree with Indigo: we can just simply suggest to use Template:Remove (yes, also to mark spam), and the admins (it is up to them anyway after all) will know that the request is not to blank the article, but to actually delete it (if redirecting it was a possibility, we have Template:Redirect for that).
- — Kynikos (talk) 13:31, 8 February 2016 (UTC)
- If you guys think we can effectively use Template:Deletion through other means, then I'm +1 for deprecating it. -- Alad (talk) 16:39, 9 February 2016 (UTC)
- I've marked it for redirection for the moment. If we kept it, we should re-add its backlinks from Help:Template, #General requests etc., and seeing them next to the Template:Remove ones would be too confusing for normal contributors. Of course we should mention the special use cases in Template:Remove itself, and we admins will easily understand when it's used to actually ask a deletion. — Kynikos (talk) 09:07, 10 February 2016 (UTC)
How to archive templates
Now I'm not sure what archived templates should look like. If they redirect to ArchWiki:Archive like normal pages, its transclusions will be completely wrong. Somebody could use it in the future by mistake, and I think it would also affect browsing the history of pages that transcluded it in the past. -- Lahwaacz (talk) 16:47, 8 February 2016 (UTC)
- Interesting question. Now that history is freshly filled with the resolved deletion transclusions, how about one dares to ArchWiki:Archive the Template:Deletion as a test case to have a look at revision examples? -- Indigo (talk) 18:15, 8 February 2016 (UTC)
- Hmm I agree that archived templates shouldn't be usable anymore => they should be removed from the Template namespace => they must be renamed to something else: I was thinking about adding some sort of symbol after "Template", maybe change them from "Template:Something" to "Template~:Something", so their titles still appear where one would look for templates.
- An alternative, which I like less, would be to leave them as they are, but instead make ArchWiki:Archive transclude safely with some mw:Transclusion#Transclusion markup magic.
- The old revisions of articles have always looked "broken" because of the various template modifications, that's not something that archiving has introduced :)
- A similar problem exists for Categories, of course, maybe they should be renamed as well.
- — Kynikos (talk) 13:29, 9 February 2016 (UTC)
- To me any mw:Transclusion#Transclusion markup magic sounds like too much effort and broken transclusions not to worry about too. I like the idea of simply renaming when moving them. Deprecation is usually discussed in the template's talk page, why not handle them as everything else. Further, a simple renaming rule for such could be applied in other cases as well, e.g. DeveloperWiki, if wanted. Perhaps prepending something is a simpler rule, e.g. "_Template:Something", "_DeveloperWiki:something". -- Indigo (talk) 18:22, 9 February 2016 (UTC)
- edit: forget about the prepending, I missed the namespace colon ":" needs replacing anyway.Kynikos' rule now seems simplest to me, perhaps using an underscore instead of hyphen. --Indigo (talk) 18:35, 9 February 2016 (UTC)
- The colon does not need to be replaced, but underscores are treated the same as spaces and page title cannot start with a space, see mw:Manual:Page title.
- They could also be moved as subpages of some central page (e.g. ArchWiki:Archive) or even into separate Archive: namespace (as was one of the original suggestions). Or we could just leave them in place and replace the content with something like {{Archived template}} flag (see how mediawiki.org does this for extensions: mw:Extension:ABC), which would also do the <onlyinclude> magic. And then why do this only with special pages and not with all of them? (Seems like we're at the beginning again, sorry about that...)
- -- Lahwaacz (talk) 18:54, 9 February 2016 (UTC)
- Discarding the transclusion markup idea, that I mentioned only for completeness' sake, but didn't like in the first place, I've given an example of how I think Templates can be archived with the now-called Template;Wikipedia (thanks Lahwaacz for fixing its remaining transclusions). I think changing the colon to a semicolon is the most natural thing we can do: I've updated the procedure accordingly.
- Archiving a Template (or a Category) is not something we are going to do every day, probably not even every month, so I don't think that the procedure os "overcomplicated", i.e. not worth it: I think saving months, when not years of contributions that had been part of the wiki's life until then, is enough to justify the little more time needed to move the page when archiving it.
- I don't like the idea of using a completely new Archive namespace (I suppose Lahwaacz meant to use it in every case, not only for Templates/Categories): we can easily do without, and if we implemented it, we'd have to always rename a page when archiving it. I don't like the {{Archived template}} flag idea either because then the archived pages would still appear e.g. in Special:SpecialPages lists.
- — Kynikos (talk) 08:38, 10 February 2016 (UTC)
- Ok, I can see what you mean on the extra mile. I'm still not convinced on using a semi-colon (or generally renaming templates) - IMO, it's difficult to spot the difference with regular, semi-colon templates at first glance.
- Revisiting Lahwaacz's suggestion: a "deprecated archive" template doesn't involve renaming, keeps the history of the template, and explicitely directs users that a template is deprecated: w:Template:Deprecated_template. Consequently old revisions look cleaner, rather than just have a red link to a (now moved) template.
- It would also offer better seperation between archived content (articles) and formatting (templates).
- Arguably, new revisions may still end up using the template (only showing a warning text). However, considering how few templates in recent use the problematic applies to - particularly when we redirect, rather than archive, Template:Deletion - this shouldn't be a problem. We also clean up backlinks before deprecating templates, as a general rule.
- -- Alad (talk) 12:39, 10 February 2016 (UTC)
- edit: I don't have a suggestion on Special:SpecialPages. However in this case I believe the benefits outweigh the drawbacks; the arguments above are from a user's perspective, and the Special: namespace is mostly our turf ... -- Alad (talk) 13:06, 10 February 2016 (UTC)
- I don't want to insist obstinately of course, so if you guys prefer archiving by tagging rather than by redirecting, I'll be fine with it, no worries.
- Probably the most affected special pages will be Special:UnusedTemplates and Special:UnusedCategories, as their archived members will grow in number in the long run. There's a quite smart solution we can use for this, though, i.e. self-transcluding the archived templates, and self-categorizing the archived categories: this will keep them off the Unused* special pages.
- But now I'm thinking, if we use a "Deprecated" template for such pages, why not just be consistent and use it for any page, and maybe just call it generically Template:Archived?
- Finally, with a "Deprecated" or "Archived" template, ArchWiki:Archive should be merged into Category:Archive.
- — Kynikos (talk) 03:31, 11 February 2016 (UTC)
- Self-transclusion is smart indeed. Regarding Template:Archived, to me that's two birds with one stone, i.e. it would also solve the issue with (double) redirects. For some inspiration, a wiki that uses this approach (together with page protection for Archived pages, cf #Restoring revisions and redirection) is [12] (translation). -- Alad (talk) 09:05, 12 February 2016 (UTC)
- True, I think the most affected special pages would then be Special:DeadendPages (no, self-linking doesn't do the trick in this case), Special:LonelyPages and Special:ShortPages; also, it will be more difficult to find unused templates in Special:MostTranscludedPages (those that self-transclude them as an example), and Special:Categories will show everything too, but these shouldn't be real problems. At ubuntuusers.de they also move the pages as subpages of the main Archive page by the way (plus leaving the content visible including all the links). There are advantages and disadvantages on both sides, can Lahwaacz confirm that, after the latest considerations, he's still in favor of the Template:Archived solution? If so, I won't object at trying it, as now I'm getting undecided myself... — Kynikos (talk) 08:57, 13 February 2016 (UTC)
Is moving pages to user space a good idea?
Some pages in my watch list are deleted. Dig into the history, found some are moved to user namespace without leaving a redirection.
- Make Arch wiki main namespace clean.
- The page is complete gone, some user may re-create it without knowing it exist before.
- Information in user namespace is hard to find and reuse.
- Some pages should merged to List of applications but it is harder to track them now.
- New contributors will have very bad feeling and may stop here.
I think we should restrict such edits and use page flag template instead.Thoughts?
-- Fengchao (talk) 06:59, 5 September 2017 (UTC)
- [Copied from User talk:Larivact. -- Fengchao (talk) 10:07, 2 July 2018 (UTC)]
- Hi, scrolling recent changes here, I'm not sure about a couple of moves today. For example, User:Thestinger/Nessus. It has a dozen contributors over years, software is uptodate & article covers some specific info, a Nessus_(Русский) translation exists too. Why does it not have enough flesh to stay in Main? --Indigo (talk) 19:14, 17 August 2017 (UTC)
- Hi, the installation note is superfluous, if you are interested in how a PKGBUILD file works, read it; when a PKGBUILD does a silent HTTP request this should be fixed. The post-installation setup section is unnecessary as the localhost page tells you to do that anyway. The service name and the localhost URL are echoed in post_install. The removal note should be echoed in post_remove. So the few info that's there can just be echoed during installation / removal and doesn't require an article. I now commented my suggestions at the AUR package.[13] --Larivact (talk) 05:25, 18 August 2017 (UTC)
- Thanks, all good reasons, and good move to suggest the improvements to the AUR package. Yet, consider the following: (1) How did you come up with the improvements for the PKGBUILD? Without installing the package or scrolling years of comments, the info in the article helped you. You sure are right it is better served in the PKGBUILD, but it is not there yet - and if you did not explain here, the move reasons would not be transparent. (2) What may happen in six months, if another user sees there is no article on Nessus yet? S/he may create one from scratch, rather than improving an existing (fixing style and removing then superfluous info), or reconsider after finding the previous one via a Template:Archive). (3) Since User pages are not indexed in our search, there is no direct way to find the current one. Moving it like this also leaves translator teams in a flux figuring why the original is gone.
- I'm appreciating your effort to clean-up too, please don't think otherwise. I'd like to make another suggestion: We have Template:Stub and want to archive it. The problem is that it is still used in many articles, Special:WhatLinksHere/Template:Stub. Among these will be clearer cut candidates for archiving/Template:Merge for otherwise useful info/move to user space (the latter should be primarily for articles a single contributor started but never got round to bringing it to a full article). Cheers. --Indigo (talk) 08:28, 18 August 2017 (UTC)
- So do we have a uniform strategy on when to Archive something and when to move something back to the original author's user page? E.g. [14], [15], [16] would fall under the above "single contributor" criterion...
- Also I'll take advantage of this to remind ourselves of the behemoth discussion ArchWiki_talk:Administrators#Should_we_remove_or_archive_obsolete_articles.3F which is not yet completed. -- Alad (talk) 18:55, 18 August 2017 (UTC)
- I agree too with Lahwaacz's proposed guidelines, we can make them official in Help:Procedures#Remove an entire page. Sorry I don't have time to resume ArchWiki_talk:Administrators#Should_we_remove_or_archive_obsolete_articles.3F at the moment. -- Kynikos (talk) 09:39, 20 August 2017 (UTC)
- I've started deleting pages that are either irrelevant to Arch (e.g. ArchAudio which was some random third-party project, now dead) or are "stubs" without meaningful contribution (e.g. Bankid). @Larivact: great work on the categorizing/cleanup you're doing btw. -- Alad (talk) 10:29, 24 August 2017 (UTC)
- N.B. If there's a related page (such as a modern replacement), it's likely better to redirect pages there rather than delete or archive them. All this does show there's gaps in Help:Procedures#Remove an entire page and I agree to expand it. -- Alad (talk) 10:36, 24 August 2017 (UTC)
- I absolutely don't want to duplicate ArchWiki talk:Administrators#Should we remove or archive obsolete articles? here, but my position is that for the moment the issue is regulated by Help:Procedures#Remove an entire page which only considers deletion in case of "spam or other clearly malicious content". I think that all contributions that made it to stay published for long periods (ArchAudio even since 2009) are part of the history of the wiki and should not be deleted. I don't see the advantages of deleting except when in need to censor the content; the data is not actually removed from the database, so it's not even a relief for the server, as small as it would even be, and I still regret having the habit of deleting pages and especially discussions before the only (and I hope last) occasion in which the deleted articles were actually purged from the database without any warning. -- Kynikos (talk) 17:40, 26 August 2017 (UTC)
- In the case of ArchAudio I would say it never belonged on the wiki in the first place, or classifies as spam. See [17] which raised the original concern but was closed arbitrarily by two users. In the other cases I agree they might as well have been moved back to the user namespace. -- Alad (talk) 12:54, 27 August 2017 (UTC)
- Topic is closed but I do think some pages should redirect/merged to List of applications. I am now reviewing pages moved to user namespace and do the work if approprite. -- Fengchao (talk) 06:13, 5 September 2017 (UTC)
- In the case of ArchAudio I would say it never belonged on the wiki in the first place, or classifies as spam. See [17] which raised the original concern but was closed arbitrarily by two users. In the other cases I agree they might as well have been moved back to the user namespace. -- Alad (talk) 12:54, 27 August 2017 (UTC)
Policy on abuse/blocking users
Hi all, do we have a policy on blocking users?
The reason I ask is Special:Contributions/LennartD who has been vandalizing systemd. I've given him a warning after the first edit and banned him for a week after the second.
Lonaowna (talk) 18:55, 28 January 2018 (UTC)
- It happens quite rarely so I don't think a dedicated policy is needed. Usually a warning is issued when a user goes against the code of conduct, and should he disregard it, he is banned indefinitely. In this particular case it applies even more, as that same user was already banned on BBS for exactly the same behavior, and he's very likely to repeat it after his return.
- Side-note: you may also want to set the "block email" and "prevent user from editing talk page" flags when issuing bans. -- Alad (talk) 22:17, 28 January 2018 (UTC)
Deprecated templates
See deprecated templates here, see Article status templates, Should these be translated and How to archive templates. -- Svito (talk) 01:08, 26 July 2018 (UTC)
Package page style guide/template
I wrote a style guide/example template for package wiki pages. I wanted to get some feedback on it and possibly see if this couldn't be adopted as a standard on the wiki. This is the page: https://wiki.archlinux.org/index.php/User:Meskarune/package
Maybe a wiki template could be created for the application info table sidebar thingy, this way it is faster/easier to add.
I think this would help improve the quality of package pages and help users get useful information faster.Meskarune (talk) 20:37, 8 August 2018 (UTC)


text:
Peter Munro
Two men have been hospitalised with stab wounds after a violent home invasion by an armed man on the Central Coast.
The men, aged 31 and 57, were allegedly attacked by another man who forced entry to a unit at Booker Bay, south-east of Woy Woy, early Sunday morning. The armed man left the scene in a vehicle before the arrival of emergency services.
Police were called to the unit at about 1.45am on Sunday and found the two men suffering from stab wounds.
The 57-year-old man has had surgery to stitch up his wounds and is in a serious but stable condition at Gosford Hospital. The 31-year-old man is in a satisfactory condition, a hospital spokesman said.
A crime scene has been established at the home. Police are investigating the circumstances surrounding the incident.
Police are urging anyone with information about this incident to call Crime Stoppers on 1800 333 000.

subset: commoncrawl


text:
CategoriesSortTitleDistanceGoClearNo matching locations Show all locationsCategories: View location detailGet directions from GoGeo locate meNext »Page of « Prev
Explore the first distillery in the home of the Temperance Movement.
The Tasting Room is open for drop in tastings and purchasing 2pm-6:30pm Wednesday- Friday, Saturdays and Sundays are dedicated to tours, and quick purchase visits. Tours are currently offered: Wednesdays & Thursdays at 6:00pm, Fridays at 2:00 pm & 6:00pm, Saturdays at 2:00 pm, 3:30 pm, 5:00 pm AND Sundays at 1pm & 2:30pm. Tours are $10/person and include a tasting. We host Private Tours, too for 10+ e-mail email@example.com
Evanston City Distillery Tour & Tasting
Favorite Few product Too Hard to Decide!BourbonRyeAmerican GinBarrel-Aged Gin
Email address:
© 2020 FEW Spirits.
Please verify your age
I am at least 21 years old
Remember me


text:
Shop by Categories
All Store Items On Sale.
Time Limited Sale Now On.
Hello! Welcome to our store!
Quality is the first with best service. customers all are our friends.
Fashion design,100% Brand New,high quality!
Material: Silicone
Length: 395 mm
Width: 285 mmThere is 2-3% difference according to manual measurement.
please check the measurement chart carefully before you buy the item.
1 inch = 2.54 cm
Please note that slight color difference should be acceptable due to the light and screen.
What You Get:
1 x Baking Tray Sheets Mat
International Buyers Please Note:
Please give us your feedback about this page Click Here
China Wholesale | Security & Privacy | About Us | Help | China Manufacturers | Seller Home | New Products | Top Searches | Products Online | Refined Products | Discount Products | China Suppliers | Best Sellers | Customer Service | Terms of Use | Russian | Portuguese | Italian | Spanish | French | German | Turkey | 한국어 | العربية
Copyright Notice © 2004 - 2020 DHgate.com All rights reserved. License
Ship to:
Choose shipping method: (shipping Inquiry)
Notice: Please be advised that only post services such as China Post, EMS are permitted to deliver private packages to Russia. For all private orders, please choose from among those companies only.


text:
Jan 20, 2004 | ISBN 9781578565825
"Ministry of Motherhood is the story of one mother who has dared to go beyond the ordinary in loving, leading, and training her children to follow Christ. In this honest and inspiring book, Sally Clarkson paints a stirring vision of a mother's mission and challenges women to disciple their children to be passionate, devoted servants of Christ."
–Nancy Leigh DeMoss, author and host of Revive Our Hearts Radio
"Biblical, practical, motivational. This inspiring book belongs on every mother's nightstand."
–Linda Dillow, author of Calm My Anxious Heart and coauthor of Intimate Issues
"Here we have a book to substantiate that the ministry of motherhood and the Great Commission are not mutually exclusive, but a complement and catalyst to each other! With an extraordinary blend of humility, challenge, and encouragement, Sally gives an exalted vision to our calling and stewardship as mothers."
–Debby Thompson, wife and mother with 30 years of ministry leadership, currently with Campus Crusade for Christ, Eastern Europe and Russia
"If you feel like a hamster on a wheel–you're running, but you're not getting anywhere–then The Ministry of Motherhood is for you! Sally Clarkson inspires us to step off that wheel and parent with purpose, not by adding something else to our hectic schedules but by bringing God into everything we do. With down-to-earth, practical examples, she shows us how we, too, can build disciples as we reach our children's hearts. A very encouraging and easy-to-read book!"
–Sheila Wray Gregoire, author of To Love, Honor, and Vacuum
"My thanks to Sally Clarkson for her sacrifice and dedication and the example her life has been to me. Through her writings she is able to share some of what God has put on her heart. This book, along with her others, reveals her to be a shining example of one committed to honor God in all that they do. May you be blessed as you read this book and continue this journey we call motherhood."
–Lynn VanWingerden, wife, mother of 23 children, grandmother of 9


text:
It's official: Those confusing off-duty lights on New York taxis are going away
Today, a city commission voted to permanently do away with new York City's befuddling taxi rooftop light system.
The change was first proposed back in May.
Thanks to a near-unanimous vote at a meeting this morning, the Taxi and Limousine Commission will require taxi owners to replace their existing two-light system with a single light with two settings--on and off--to indicate a taxi's availabity.
The only dissenting vote came from Iris Weinshall, the city's former transportation commissioner, who is Senator Chuck Schumer's wife.
Technically, the new rule becomes official 30 days after it's posted in the city record, which will happen within the next few days, according to a commission spokesman. But the lights will in practice have to be changed by each cab's next scheduled inspection, between January 1 and April 30.


text:
confederate with (someone or something)(redirected from confederated with me)
confederate with (someone or something)
To unite or work together with someone or something. Those two groups confederated with each other to form this proposal.
See also: confederate
confederate with someone or something
to organize, join, or unite with someone or a group. A number of states confederated with one another and formed a loose association. I confederated with the neighbors and we filed a joint complaint.
See also: confederate


text:
<< Back
Arkansas Razorback Hoodie Christmas Ornament
62603 Merck Family's Old World Christmas
Size: 4.25"
Prepackaged Box
Each figural glass ornament produced for The Merck Family's Old World Christmas is hand crafted in age-old tradition using the same techniques that originated in the 1800's.
Molten glass is mouth-blown into finely carved molds available only to the Merck Family's Old World Christmas, before a hot solution of liquid silver is poured inside.
The ornaments are then hand-painted and glittered in a series of labor-intensive steps to achieve the beautiful creations
© 2020 TrendyOrnaments.com, a division of Trendy Tree, LLC. All rights reserved. | We respect your privacy.


text:
Senate Majority Leader Harry Reid and his wife, Landra, are leaving the Democrat's boyhood town of Searchlight, Nev., and moving to the Las Vegas area to be closer to their children and grandchildren.
"Landra and I love Searchlight, the place of my birth, and the memories we have had there, but the time came to sell and do something different," Reid announced Monday in a news release. "We want to be closer to our 16 grandchildren who live in Southern Nevada, and be able to spend time with them. This is why we will now purchase a residence in the Las Vegas area. Searchlight will always remain my home, my favorite spot in the world where I can look at the quiet desert for miles at end."


text:
0 Reviews
Write your review
No reviews found. Be the first to submit a review!
Thank you for logging in. You may now post your review.
Log Out
Please sign in with your favorite social network in order to post your review.
Sign in with Google
Sign in with Facebook
Sign in with Twitter
Rebuilt inside and out with an all-new powertrain and enhanced suspension tuning back in 2016, the Toyota Tacoma retains its throne on the mountaintop for dirt stomping adventurers. The Tacoma shares big brother Tundra's more chiseled face, with a hex grille. From there, Tacoma expresses its own identity with a front end that portrays an aggressive attitude with its bold upper grille and a taller, more muscular hood. Slim high-tech headlights are mounted high above the redesigned front bumper and feature projection beam lamps with available LED Daytime Running Lights.
Available in Access and Double Cab configurations, short and long cargo box offerings and SR, SR5, TRD Sport, TRD Off Road, TRD Pro and Limited models; power for the Tacoma is generated by one of two powerful engines: a 2.7L four-cylinder and a 3.5L Atkinson cycle V6 with VVT-iW (Variable Valve Timing with Intelligent Wider Intake) and equipped with Toyota's D-4S technology, featuring both direct and port fuel injection. Motorists have a choice of a six-speed manual gearbox or six-speed automatic transmission for both engines. Four-wheel drive is an available option for both engines.
Built tough, Toyota engineers started by adding high strength steel to the frame to help enhance rigidity and overall strength. Ultra-high strength steel was integrated into the body shell using a hot stamping process that reduces weight. To create a truck to meet the needs of active drivers on a variety of tamed and untamed surfaces, the suspension was fine-tuned to help deliver a smooth on-road ride, while making it even more capable off-road.
All Tacoma models are equipped with a coil-spring double wishbone front suspension and stabilizer bar combined with a leaf spring rear suspension with staggered outboard-mounted gas shocks. Brakes are power-assisted ventilated front disc and rear drum brakes with a tandem booster.
Inside the passenger cabin, Tacoma's tough exterior is complemented by an interior that conveys a sport truck image reflecting an athletic, go anywhere, off-road feel. Drivers will notice a sporty design theme in the instrument panel for a driver-focused experience. Soft-wrapped trim and metallic accents set the stage for a high-quality look and feel that is a starting point for an array of available premium features.
All Tacoma models feature a four-way driver's seat with lumbar support and four-way adjustable front passenger seats. The SR and SR5 grades are equipped with fabric-trimmed seats with a fun and youthful look. Seating for the TRD Sport and Off-Road grades are uniquely upholstered with embossed fabric that conveys a dynamic and rugged feel. The premium Limited grade features a rich, yet sporty leather.
Interior storage is maximized in Access Cab models with fold-up rear seats and under-seat storage. Double Cab models feature 60/40 split rear seats with adjustable headrests and under-seat storage.
Dimensions & specifications
Tacoma Access Cab
Wheelbase: 127.4; overall length: 212.3; width: 74.4; height: 70.6
Tacoma Double Cab/short cargo box
Wheelbase: 127.4; overall length: 212.3; width: 74.4; height: 70.6
Tacoma Double Cab/long cargo box
Wheelbase: 140;6; overall length: 225.5; width: 74.4; height: 70.6
All vehicle measurements are in inches.
Engine: 2.7L four-cylinder – 159 hp at 5,200 rpm and 180 lbs-ft of torque at 3,800 rpm; 3.5L Atkinson cycle V6 – 278 hp at 6,000 rpm and 265 lbs-ft of torque at 4,600 rpm.
Transmission: six-speed manual; six-speed automatic
EPA Fuel Economy: 2.7L four-cylinder – 17 city/21 hwy. (manual 4x4), 19 city/24 hwy. (automatic 4x2), 18 city/23 hwy. (automatic 4x4); 3.5L V6 – 19 city/24 hwy. (automatic 4x2), 17 city/21 hwy. (manual 4x4), 18 city/23 hwy. (automatic 4x4)
Payload capacity: 1,620 lbs.
Towing capacity: 3,500 lbs. (four-cylinder); 6,800 lbs. (V6)
Safety features
Dual front airbags, front seat mounted side-impact airbags, dual head curtain side-impact airbags, dual front knee airbags, four-wheel anti-lock brakes, electronic brake force distribution, brake assist, smart stop technology, vehicle stability control, traction control, automatic limited slip differential, pre-collision system with pedestrian detection, lane departure alert with sway warning system, automatic high beams, high-speed dynamic radar cruiser control, side-impact door beams, hill start assist control (automatic transmission), engine immobilizer, tire pressure monitoring system, daytime running lights, and integrated backup camera display. SR5 adds Bluetooth hands-free phone system, remote keyless entry, and Connected Navigation Scout.
TRD Sport adds Smart Key System, LED daytime running lights, and wide-angle fog lights. TRD Pro adds rear parking assist sonar, HomeLink universal transceiver, blind spot monitor and rear cross traffic alert.
Basic: 3-year/36,000 mile Comprehensive
Powertrain: 5-year/60,000 mile
Corrosion: 5-year/unlimited
Roadside Assistance: 2-year/25,000 mile 24-hour
The base Manufacturers Suggested Retail Price (MSRP) for the 2018 Toyota Tacoma pickup truck starts from $25,130 for the SR Access Cab, upto $44,420 for the TRD Pro Double Cab 4x4. Destination charges add $995.
Bentonville, AR 72712
Ready to see this 2019 TOYOTA TACOMA in person? Request
that the dealer contact you about scheduling a test drive.
By using this feature, you agree to EveryCarListed.com's Terms of Use.
Open This Map to the Dealership in a New Window
About Us |
Contact Us |
Terms of Use |
Privacy Policy |
Auto Dealer Marketing |
Site Map
©2020, EveryCarListed.com, LLC All rights reserved.