Wikipedia:Requests for comment/userfication

Proposal: make it easier to userfy pages by adding it to WP:Twinkle, improve templates and pages associated with userfication, and create processes to manage issues arising from more frequent userfication. Rd232 ^talk 16:02, 22 October 2009 (UTC)[reply]

Proposal: make it easier to userfy pages by adding it to WP:Twinkle. Add a new button on the Move page (after clicking the Move tab), which when clicked

• identifies the page creator and suggests their userspace as the move target (but allow the Twinkle user to choose a different target)
• moves the page to the selected userspace (without leaving a redirect, if Twinkle user is an admin, or else WP:CSD#R2 nominating the redirect)
• removes any CSD, PROD, expired AFD tags or hangon tags
• comments out non-free images
• comments out categories
• adds {{userspace draft}} or equivalent
• notifies the creator and owner of the target userspace of the move.

In addition, similar functionality should apply (obviously for admins only) on the Undelete tab, to permit easy userfication of a deleted page.

Specific issues

• If open to non-admins, it may encourage (abuse of) userfication. This is discussed in more detail below (#Encouraging userfication?), so please don't go into it here as well.
• {{userspace draft}} currently applies categories related to the Article Wizard; a different template could be used (see below), or, as User:Gadget850 has suggested, "We could probably merge the templates and add a switch for cats and content. It should refer back to the userfication process for userfied pages." Please see discussion below under #Templates, and avoid discussing it here unless necessary.
• The proposal takes this form (adding things under existing tabs) to avoid adding yet another tab to Twinkle; but this may not be agreed as desirable, or turn out to be practical.
• The Wikipedia:Article Incubator could be added as an optional target, instead of userfying. In some cases this has clear advantages over userfication. However, making it a Twinkle option might well lead to the Incubator being overwhelmed.

Encouraging userfication?

Benefits

• Much reduced WP:BITEyness versus speedy deletion, proposed deletion (may be relatively easy to contest but it still looks scary and offputting to many newbies) and WP:AFD.
• Reduced deletion of potentially good material which currently isn't suitable.
• Reduced mis-tagging using CSD tags, particularly of A7 and G11, as userfication may be applied instead.

Concerns

• a concern is that when pages are userfied, they may still be search-engine indexed, so it's an easy way to keep something sort-of-on-Wikipedia.
  • However, all the userpage tags apply {{noindex}}, which may be enough to lay that concern to rest. If not, an RFC earlier this year suggested quite strong support for noindexing userspace, and that could be revisited if necessary.
• userfication is somewhat (and may become more so) a "backdoor CSD" (ThaddeusB). New page patrollers frequently CSD tag wrongly, and userfying wrongly would be much the same, with no supervision.
  • So we need to create some supervision.
• most userfied stuff goes absolutely nowhere, just languishes indefinitely, and useful stubs or better may be lost to the encyclopedia.
  • So we need to create a tracking system and try and rescue abandoned userspace drafts.

Suggested oversight/tracking system

There are a number of ways this could work. Aspects to consider:

• Conditions for userfication
  • bear in mind Wikipedia:Userfication#What can not be userfied
  • eg deleted page; already-tagged CSD candidate with some possible merit; non-tagged CSD candidate with some possible merit
  • ? Anything "PROD"able, if we ensure, in some way, a second user agrees?
• Conditions for deuserfication
  • Any time the user wants
  • Other users?
• Conditions for deletion of abandoned userspace draft
  • eg Automatic PROD-nomination by a bot after two months without activity; with bot-warning of impending deletion after one month. PROD still requires 7 days in PROD categories, with chance of rescue, and then an admin decision to delete.
• Mechanism
  • the userpage tag (eg {{userspace draft}}) can add suitable dated maintenance categories "Userspace drafts created on dd//mm/yyyy"
  • bots can work those categories and after 1 month notify creator and add suitable tag to the draft {{dormant userspace draft}}, "to be PRODded on dd/mm/yyyy", which also adds it to category "Userspace drafts to be PRODded on dd/mm/yyyy"
  • Article Rescue Squadron or whoever can work the dated maintenance categories.
  • Users returning to nearly abandoned drafts will see the extra "dormant" tag telling them what do (i.e. remove the tag if they want to keep the draft)
  • Some means of tracking drafts where tags are removed, eg a bot-created list of drafts, periodically checked for edit activity.
  • Tracking: in userfying, find a way to collect stats on reasons for userfication. Most obviously, dated maintenance categories based on preset classes of reason.
  • Supervision: non-admins will be CSD-nominating redirects created, which provides some visibility for users excessively userfying, or userfying incorrectly (particularly if we urge admins not to treat such CSDs as trivial).

Wikipedia:Userfication

Proposal: develop Wikipedia:Userfication per these discussions, and upgrade to guideline. Rd232 ^talk 15:12, 20 October 2009 (UTC)[reply]

Deuserfication

Non-autoconfirmed registered users

Non-autoconfirmed registered users currently can't "deuserfy" pages, i.e. move from their userspace to mainspace. Suggestion: permit such users to deuserfy pages from their own userspace, rather than making them wait til they're autoconfirmed, or ask someone. Rd232 ^talk 14:49, 20 October 2009 (UTC)[reply]

Easy deuserfication

If technically possible, help users deuserfying, eg by making the userpage tag Javascript-clickable so that it can execute a Twinkle-style move, including uncommenting categories, removing userpage tag, and perhaps adding {{new unreviewed article}} or something like it. Could also ask user if it's a BLP, and add appropriate category if not present. Rd232 ^talk 12:29, 20 October 2009 (UTC)[reply]

Templates

Overview of relevant templates moved to talk page to reduce clutter here.

Attempts should be made to move them to WP:INCUBATE instead, as this allows other users to keep track of their pages and gives them the publicity they need to get them up to standard. Too many pages by new users are moved in to their user space and left forgotten about for years.--Otterathome (talk) 21:10, 26 October 2009 (UTC)[reply]

Thanks for being the first to comment! Yes, this is one of the options mentioned above, under #Specific issues. The concern is that it might overwhelm the Incubator - it's not an unproblematic option, though I'm sure it is worth discussing in more detail. Rd232 ^talk 21:16, 26 October 2009 (UTC)[reply]

Maybe a 31 day prod for deletion would be suitable to deal with them.--Otterathome (talk) 21:32, 26 October 2009 (UTC)[reply]

Sorry, what do you mean by "Them"? Rd232 ^talk 21:44, 26 October 2009 (UTC)[reply]

Pages moved to the incubator that are collecting dust.--Otterathome (talk) 21:57, 26 October 2009 (UTC)[reply]

I wholly support adding Userfication and Incubation to Twinkle. I'd encourage more use of the Incubator. The more it is used, the more people will be aware of it and edit the articles within it. If too many articles are going stale we can work out ways around that like placing notices on the pages of relevant WikiProjects. Fences&Windows 00:28, 27 October 2009 (UTC)[reply]

I'd recommend them both on a single tab - defaulting to Incubation, with a checkbox which can be toggled between these choices. עוד מישהו Od Mishehu 12:15, 27 October 2009 (UTC)[reply]

Not sure if this is best to incorporate into Twinkle (it's bloated enough as it is), but it seems like an excellent idea for a standalone script. NW (Talk) 23:03, 27 October 2009 (UTC)[reply]

Not sure what you mean - the JS script file is bloated? Or that Twinkle already has too many options and tabs? If the latter, that's why I suggested putting it on the Move/Undelete tabs, rather than as Yet Another Tab On The Top. Generally, I wouldn't want to bury it in another script, I think it should be part of Twinkle. Rd232 ^talk 18:08, 30 October 2009 (UTC)[reply]

• I support standardizing userfication and creating some sort of tracking system. I am less enthusiastic about making userfication easy per previous discussion at WT:Twinkle/Archive 17#Adding userfication to Twinkle and WP:Village pump (proposals)/Archive 53#Easier/better userfication. Flatscan (talk) 03:43, 1 November 2009 (UTC)[reply]
  • Your comments seem to have been "How diligent are admins at reviewing WP:CSD#R2, e.g., following a non-admin userfication? It's plausible that a poor quality article on a viable topic would be userfied indefinitely versus being fixed at AfD. WP:Article Incubator would get the outside input, but could be overwhelmed. [...] I would prefer that a tracking implementation precede a trial." (VPR), "Are abandoned userfied articles a real problem, even in large numbers? I would prefer to avoid them, but I can't see that a mass clean-up (mostly deletion) would have consensus." (WT:Twinkle). Perhaps you could clarify exactly why easier userfication was opposed, especially as I thought I'd addressed those concerns with my proposal. Rd232 ^talk 08:31, 1 November 2009 (UTC)[reply]
    • My reservations (not objections, if that distinction matters) originate from Amalthea's comments regarding WP:New pages patrol at the WT:Twinkle discussion. The tracking system goes a long way towards identifying developing problems. I see that allowing access to non-admins is already mentioned as a separate consideration; I would be personally more comfortable if the feature was initially admin-only to limit its userbase. Flatscan (talk) 04:11, 2 November 2009 (UTC)[reply]
      • I'm fine with that as a start. What if non-admins could propose userfication in the same way they can nominate for CSD? Rd232 ^talk 10:41, 2 November 2009 (UTC)[reply]
        • I would prefer that. SoWhy and ThaddeusB have articulated issues that I forgot about. I also generally prefer the Incubator over userfication, particularly for its multiple experienced users and technical advantages of a dedicated project space. Flatscan (talk) 04:14, 4 November 2009 (UTC)[reply]

I think ThaddeusB puts it correctly that an easier and encouraged userfication can and will lead to deletion through the backdoor by non-admin users who currently make tagging mistakes. Userfication is a nice idea but it fails to take into account that new users usually have no idea of what userspace is or what to do with a page there.

Also, userfication actually limits the whole purpose of this project, i.e. collaboration by many editors on a single article by removing it from the view of most editors interested in it. The reason we allow articles that are in a bad shape but do not meet speedy deletion criteria to remain in article space is not because we don't have the means to get rid of them but because they could be improved by others interested in the subject.

Last but not least, encouraged userfication will not reduce mis-taggings but rather convert a part of those mis-taggings in mis-userfications that need more cleanup to be reverted and more work for admins to identify and fix. Userfication is already a tool that admins know about for those few cases where an article meets a SD criterion but is likely to be fixable. But in 95% of all SD taggings, the tag is either incorrect or the article is unlikely to be fixable and as such the current tools already handle the situation well. Regards SoWhy 09:51, 2 November 2009 (UTC)[reply]

Two specific responses to that: userfication by tool will ensure the addition of a tag with a helpful link on what to do next (cf {{userspace draft}} as seen here - it looks different in userspace); and there has been discussion of sending things to the Incubator instead. Any thoughts on that? Rd232 ^talk 10:31, 2 November 2009 (UTC)[reply]

Also, as noted above, the biteyness of (correct or incorrect) CSD nomination is something we want to reduce. Userfication (or proposed userfication) is surely a step in the right direction. "This needs work" is so much more welcoming than "somebody thinks this is so junky it needs deleting immediately" (or within 7 days or via discussion). Rd232 ^talk 10:37, 2 November 2009 (UTC)[reply]

My comment was about the previous comments as well as the RFC proposal since I object the whole idea of making userfication any easier or guideline-y which is the underlying necessity for your proposal to work.

Before one can discuss whether userfication should be added as an easy thing to do in Twinkle, one has first to discuss whether userfication should really be encouraged at all. I have previously commented at the incubator talk page (here) and WT:TWINKLE (here) on this and your proposal does not address whether non-admins should be allowed to userfy pages without supervision nor does it offer any solutions how such supervision could be created. I have previously suggested that a CSD-like system is created for userfication/incubation where a user can tag an article for suggested userfication/incubation (maybe using Twinkle) and an admin reviews the tag like an SD tag.

But the main point is this: Instead of tagging, new page patrollers should be encouraged to seek to improve the articles instead and to talk to the creating users. WSC's experiment at WP:NEWT illustrates that the main problem is not speedy deletion tagging but incorrect taggings and/or deletions without communicating with the user in question. Userfication will not fix this problem at all because a new user usually does not care which technical method was used to remove their article from main space. Regards SoWhy 10:50, 2 November 2009 (UTC)[reply]

I'm happy to discuss a CSD-like nomination-for-userfication approach (as you can see above in this thread). This RFC was supposed to be very broad and lively, not thumbs up/down on my proposal! And I have to disagree vehemently with your closing remark, as is clear from what I said earlier: "I think this needs work" is so much more welcoming than "I think this is so junky it needs deleting immediately" (or within 7 days or via discussion). This is true whether the CSD nomination, AFD or PROD actually result in deletion or not. As to fixing New Page Patrol in the way you imply - not gonna happen, because it's too much work, and the sort of people doing NPP (or people in that sort of mood) aren't much up for it unless they come across a topic of interest. What we need is to be nicer and friendlier and try harder to link problematic-but-fixable new pages with people willing to help or willing to fix, before biting newbies with deletion threats. If you have a better way of doing that than userfication/incubation, let's hear it. Rd232 ^talk 10:59, 2 November 2009 (UTC)[reply]

Your argument requires that a newbie creator understands that userfication is less than deletion. If we remember that both result in the article being removed from main space, a newbie will usually not understand the difference at first, thus feeling equally bitten. If we want to tell them "I think this needs work", then we can place a tag saying so on the article and tell them about it without removing it from main space. We could incorporate it into a PROD-style system, e.g. give them 7 days to fix the problems and sent it to incubation if they do not react within this time frame or agree to incubation. An admin would then assess the article again after this period and decide whether it should be sent to incubation.

Speaking of incubation, I would argue that we should abandon the idea of userfication in favor of incubation since the latter method is designed to allow cooperation by multiple users unlike userfication which places the main burden on the user whose user-space the article is sent to. Regards SoWhy 13:23, 2 November 2009 (UTC)[reply]

I agree with that last point entirely. My view of incubation is that it is primarily improved userification. --ThaddeusB-public (talk) 22:00, 3 November 2009 (UTC)[reply]

• I understand where this is coming from and appreciate the effort to reduce newbie bite. Unfortuantely, I don't really think this is the way to go about it. My concern is that it doesn't really solve any problem - it just shifts it elsewhere. I agree with SoWhy that the amount of articles that are deleted under CSD that have a legitimate chance of becoming a decent article is pretty small, and is certainly smaller than the amount of CSD nominations that are in error. Most deleted articles are either unsalvagable in that they are unverifiable or violations of WP:NOT

  From my POV, it is not the deletion of "junk" per say that is the problem, it is that we (as a community) are deleting things while providing the new user with only minimal relevant guidance, or in some cases none at all. Many NPPers do an excellent job, but the problem is that some see it as a race to tag. A great many article get tagged - or even deleted - within seconds of creation. Most of these would never survive, but others are very rough first drafts. The mere act of having their first attempt immediately tagged is enough to turn many people off, some of which never intended to be judged on that first draft at all. I don't see how moving the article is less bitey than tagging it - and it is my opinion that it is the tag, not the eventual deletion or non-deletion that is the main bite. The problem is compounded by the fact that few, if any, NPPers take the time to explain to the newbie why their article was tagged and instead drop a generic template that doesn't really help the newbie. Userify wouldn't fix the lack of proper explanation problem, and could possibly increase it do to added confusion. ("WTF is user space? I thought this was an encyclopedia.")

  Furthermore, I don't really think we are doing someone any favors by saying "here, work on this outside of mainspace" when the article has almost no chance of ever surviving in mainspace. That is, unless they specifically ask for it. If the article is truly salvagable, the best thing to do is almost always to offer advice on how to improve it, or better yet help improve it. Moving it to userspace might protect it from an overzealous admin (there are a few of them), but that's about the only benefit to the newbie.

  Encouraging regular editors to userify doesn't do anything to help the admin workload, since they have to at minmum delete the resulting redirect, and in theory review the moved article themselves anyway. It would be far better to leave the decision up to the admin to begin with. I am all for encouraging admins to userify more (or preferably incubate), but I don't want to encourage regular editors to do it. If a twinkle button helps make that happen, I'm all for it, but it should be admin only.

  Finally, I will point out that of the newbie requests to have their article userified after deletion, the vast majority never touch the article again - and that's those who specifically requested it. I can't really see easy userification doing enough to justify all the cleanup work it would create. --ThaddeusB-public (talk) 21:57, 3 November 2009 (UTC)[reply]

• I think both userfication and incubation should be available to editors. I trust editors to do the correct thing. I was the original editor who proposed this most recently, three cheers for Rd232 pushing this forward. Ikip (talk) 21:31, 6 November 2009 (UTC)[reply]
• If userification was available via twinkle, it would save me some effort when I deal with post-deletion CSD restoration requests. I'd probably use it in lieu of the "delete" button 3-6 times a week on CSDs. In other words, support. Jclemens (talk) 21:51, 6 November 2009 (UTC)[reply]
• A userification/incubator button for twinkle is a great idea. See Ikip's section for explanation. Sincerely, --A Nobody^{My talk} 17:11, 7 November 2009 (UTC)[reply]

Compromise

How about having (for access to the proposed Twinkle buttons) userfication as admin only, and allow everyone access to move articles to incubation? Would that be a good compromise in terms of various people's concerns and objectives? Rd232 ^talk 17:48, 7 November 2009 (UTC)[reply]

I... was about to post saying the same thing. Incubation seems to be the Saturday morning cartoons of actions new page patrols could use, compared to CSD rights to all akin to a digitally-animated Godzilla stomping around town. ANY reduction in the number of things marked as CSD, um, yes? It would keep the list of articles cycling through to double-check for possible CSD removal a lot easier to manage if only 1-2 people happen to be doing it randomly. Oh, and then there's less work for admins, too, but I mean that's minor in comparison, right? Whenever I save something out of CSD I always end up contacting the user anyway, and probably about 50% of the time I hear back from them...maybe half the time again we come up with improvements, so un-CSDing → Incubate would be, well, rough guess at ~25% success rate on some kind of eventual articles? Sounds better than losing them. The "big picture" on this is that even if a few people ever used it, it would still make us overall more welcoming of new users and new content, which is certainly an image problem now. Oh, and however much I like the new proposed newpage/construction tag templates, this would be much much easier for everyone. ♪ daTheisen(talk) 21:18, 7 November 2009 (UTC)[reply]

Clarification (hopefully this helps, because I think I initially misunderstood too):

TWO buttons added to twinkle:
FIRST button added to twinkle: Userfication. Only admins have access to this twinkle userfication button. But the policy of userfication stays the same. Anyone can still userfy an article, but only admins have access to the twinkle userfication button. SECOND button added to twinkle: incubation twinkle button, available for all editors to use.

If this is not correct, please let me know. Ikip (talk) 19:59, 11 November 2009 (UTC)[reply]

That's correct. Thanks for clarifying. Rd232 ^talk 20:07, 11 November 2009 (UTC)[reply]

• I support admin-only userfication and defer to Incubator editors on incubation. Flatscan (talk) 02:55, 8 November 2009 (UTC)[reply]
• I too support admin userfication and editor incubation, seems like an excellent way to reduce biting and CSD backlog! Frmatt (talk) 05:34, 8 November 2009 (UTC)[reply]
• Hesitantly support Because I feel that the majority of non-admins can be trusted to use our tools wisely, I am troubled by the extra userification restrictions on regular editors. But that said, I think this is a viable comprimise. Misunderstood...Ikip (talk) 06:21, 10 November 2009 (UTC)[reply]
• Strong oppose. We want articles "not ready for primetime" to be userfied and allow users to work on them. Incubator for some might be an excellent option and if there is some strong reason and article can't(?!) be userfied then perhaps that is an elegant solution. But adding a bureaucratic step seems like a really bad idea when other solutions likely should address any actual problems. And an incubator environment may be wonderful for some but not all - similar that people learn things in different ways. We - no longer - assume that someone spatially challenged or dyslexic is simply stupid, we to to help them achieve their goals of learning through complementary methods. Having stated this it might not be a bad idea to contact all who have userfied content to alert them to how incubation works and give them a some easy steps to move the work there if they see it as a better option. If items are routinely deleted from the incubator we should also be clear that that happens and under what circumstances. -- Banjeboi 20:33, 10 November 2009 (UTC)[reply]
  • Making it easier to send articles to the incubator is "adding a bureaucratic step"? Can you run that by me again?? Userfication where appropriate will remain possible, manually, and via Twinkle for admins. And many cases where it's appropriate have to be handled by admins (undelete/userfy). I think the question really is, what exactly do you have against the Incubator? It seems to me to just be a sort of collaborative userfication. You do realise that the vast majority of userfied articles are abandoned? At least in the incubator somebody else might come across them. Rd232 ^talk 20:59, 10 November 2009 (UTC)[reply]
    • Making it easier to send to incubator is different than requiring it. Having the incubator as part of a set of solutions to address perceived abandoned content in userspace would, of course, be welcome. -- Banjeboi 21:34, 10 November 2009 (UTC)[reply]
      • Who said anything about requiring anything? This is an RFC about adding options to WP:Twinkle. Rd232 ^talk 22:34, 10 November 2009 (UTC)[reply]
        • This section states "userfication as admin only" which by default means incubation would be required by non-admins. As any user can presently userfy I'm not sure why this would be a benefit. I do see however that in many cases accompanying a userfication with a talkpage note - maybe a handy template that talks about the benefits of the incubator - could be seen as welcome assistance. Empower and encourage the cooperation but don't require it. -- Banjeboi 00:23, 11 November 2009 (UTC)[reply]
          • I think we were not clear in explain this, for that I apologize. We give up userfication for the twinkle incubation button. Simply ask a friendly admin to userfy an article. Ikip (talk) 01:16, 11 November 2009 (UTC)[reply]
            • To me it still feels odd but perhaps a trial could see how it works. If something is pushed to incubator then a welcoming and civil message should spell out what this means and offer the user an alternative to userfy instead. -- Banjeboi 02:41, 11 November 2009 (UTC)[reply]
              • Incubation via Twinkle should be accompanied by a Twinkle user talk message, and I suppose there's no reason it can't point out that a user could request userfication of the incubated article (though it escapes me really why anyone would bother). Since your oppose seems to be founded on a misunderstanding ("userfication as admin only" refers to access to the option to be added to Twinkle - manual userfication is unaffected), will you strike it? Rd232 ^talk 09:43, 11 November 2009 (UTC)[reply]
                • On technical grounds that I am indeed less familiar I will amend to weak oppose as logically I'm still stumped why both userfying and incubation can't be employed by any editor, it is just moving an article as far as i can tell. -- Banjeboi 00:47, 12 November 2009 (UTC)[reply]
                  • Anyone can userfy and incubate without Twinkle. this proposal adds two buttons to Twinkle. Only admins will have the twinkle userfy button available. Every editor will have access to the incubate button. Ikip (talk) 20:00, 16 November 2009 (UTC)[reply]
• Strongly support userfication being worked into Twinkle, I really don't support it being an admin only function, but understand why others might want only experienced users to have the capability. There have been various periods when userfication was a frequent result at MfD (lately mostly userpages come up there, but often a half-baked wikiproject, portal, or (historically) userbox in template space, would need to be userfied). It's an occasional result at tfd as well. The pain of userfication, isn't the actual userfication, which is nothing more than a move but the notification to the user who's getting it stuck in his or her userspace. Automating this would be way nice.--Doug.^{(talk • contribs)} 16:26, 11 November 2009 (UTC)[reply]
• Support compromise, but with the caveat that if NPPers incubating things that shouldn't be deleted the button will be removed/made admin only. --ThaddeusB (talk) 19:19, 11 November 2009 (UTC)[reply]
  • Agreed, we should keep a close eye on the usage, and make sure it can be tracked easily. Rd232 ^talk 19:51, 11 November 2009 (UTC)[reply]
    • Currently editors are speedy deleting pages which should not be deleted, Wikipedia:Newbie_treatment_at_CSD I would much rather have editors incubate pages which should not have been incubated in the first place, than having an editor delete a page that should have never been deleted. I think incubation serves as a less bitey way to get more eyes on a potential article. Ikip (talk) 23:09, 11 November 2009 (UTC)[reply]
      • Yeah except that 80-90% of the incorrect tags were declined by the reviewing admin. If we relied solely on the tagger's judgment, 100% would have been deleted. Those 80% might well still be moved out of mainspace under this alternative. That scenario is unacceptable and the reason why I am hesitant to support this. I doubt that there is much difference between "moved out of the encyclopedia" and "deleted" in terms of bite. Frankly, I think the initial tagging is the part most likely to bite the newbie. --ThaddeusB (talk) 01:19, 12 November 2009 (UTC)[reply]
        • I think that such mistagging (and its effects) needs to be handled separately. Wikipedia:Requests for comment/new users is now closed, but maybe we can try and focus specifically on this issue with a new RFC. Maybe there are other things we can do to indentify and correct mistaggings. The biggest problems are with A7 and G11; maybe those should be removed from the current CSD format and moved to a process which works similarly but is friendlier, partly by being less speedy in deletion since it isn't so dramatically urgent for those. There is [1], which I'm not convinced of. Rd232 ^talk 01:49, 12 November 2009 (UTC)[reply]
• Strong support We need to make incubation easier to encourage the process, and this seems to be a great way. Saebjorn! 01:33, 14 November 2009 (UTC)[reply]
• Support Not really seeing how this is more bureaucratic. The idea seems enough, and even if it bloats Twinkle a little more, it is definitely worth it. NW (Talk) 10:21, 16 November 2009 (UTC)[reply]
• Oppose the idea of incubation, Support making userfication through twinkle available to everyone, regardless of admin bit. Non-admin CSD tags the CNR, admins move without leaving redirect. I had volunteered to write the code for this myself a while back even, but I never got a round tuit. Those are the hardest kind to get. Gigs (talk) 20:10, 16 November 2009 (UTC)[reply]

I would be interested to know why you oppose a incubation button, and yet support userfy button. I see the admin userification button as a first step. If it works well, it could possibly be expanded to everyone. Ikip (talk) 22:19, 16 November 2009 (UTC)[reply]

Because non-admins can already userfy. It already is expanded to everyone. I could write a little javascript to implement this button for non-admins right now, without anyone's approval. I don't need community permission to do it; it's just doing a normal editing function. Since it's a normal editing function already available to everyone, it's silly to put out a crippled tool to non-admins, forcing them to use custom JS if they want the real thing. Gigs (talk) 03:12, 17 November 2009 (UTC)[reply]

I agree, I am entirely Java illiterate, and the button will only be a shortcut. Power to you, Gigs. Maybe Autoconfirmed is a better group, instead of Admins. Saebjorn! 02:29, 20 November 2009 (UTC)[reply]

You could make a little javascript app, but the hurdle comes in having to have consensus in instituting it into wikipedia.

This argument is like a starving man refusing to accept a half loaf of bread because he demands the full loaf or nothing. We have to look at this as a first step, at the long term. Barring abuse, which I doubt will happen, we can point to the sucess of the incubation button as a reason why the usefy button should be added for all editors.

Remember, we are not losing anything by accepting this, we only lose if we oppose. Please reconsider. Ikip (talk) 20:58, 20 November 2009 (UTC)[reply]

We lose if this incubation junkyard idea gets pushed through because it's bundled with what is otherwise a good idea. So no, I absolutely oppose any attempts to force incubation on the community which has already rejected it through lack of use. Gigs (talk) 03:07, 24 November 2009 (UTC)[reply]

Nothing is being "pushed through" or "forced". We're talking about adding buttons to Twinkle. Whether people want to use them (or Twinkle for that matter) is up to them. And Incubation is still a relatively new and under-publicised idea, so "lack of use" (however quantified) doesn't mean much. Rd232 ^talk 10:32, 24 November 2009 (UTC)[reply]

• Support There's no guarantee that the user who created the article has any intention on improving it, so incubation would be ideal for most situations. Userfication will of course still be an option available to users who believe that the article will be worked on in the userspace, but keeping the automated userfication method admin-only should reduce inappropriate userfication. Reach Out to the Truth 18:12, 20 November 2009 (UTC)[reply]
• Support in any way possible: Even if this doesn't go through, maybe it'll get the Incubation project "done" compared to its present depressing state, so patrols at least have that option available manually. My only "issue" with the Twinkle would be making sure proper user talk templates were placed and that they be 100% polite and anit-biting. Really, this is a win-win-win across the board. Admins win with less CSDs and especially less "questionable" ones. Patrols win so they needn't have a panic attack about tagging things and Twinkle can even pretend to demonstrate good faith regardless of the opinion of the user (I mean that as a good thing), and the authors win when their article is returned to them unharmed. Get this up, add sections in the CSD and PROD procedure pages, etc. Things have been kinda sad in the whole CSD realm this month, with the infamous WP:NEWT and continued general frustrations... this idea has been around awhile but now seems like a great reason to push it over the top. The idea of reflecting a new article back for additional work from a user without "penalty" or any harsh words in templates, big red boxes everywhere, etc;... should be attractive to every editor on Wikipedia. ♪ daTheisen(talk) 13:56, 23 November 2009 (UTC)[reply]
• Support Useful, consistent with policy. Just ran across a candidate earlier today. ˉˉ^anetode╦╩ 16:37, 23 November 2009 (UTC)[reply]