Jump to content

Wikipedia talk:WikiProject Articles for creation/Helper script/Rewrite/Archive 2

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:WikiProject Articles for creation | Helper script | Rewrite
This is an old revision of this page, as edited by ClueBot III (talk | contribs) at 18:40, 21 May 2014 (Archiving 7 discussions from Wikipedia talk:WikiProject Articles for creation/Helper script/Rewrite. (BOT)). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
Archive 1Archive 2

[0.7] Feedback about Postponing G13

{{resolved}} Hello again. I tried to postpone deletion of Wikipedia talk:Articles for creation/Douglas Richard Ferguson. The script gives me only the options to Comment or Submit. There is clearly a G13 notice on the page. —Anne Delong (talk) 09:55, 6 May 2014 (UTC)

Thanks Anne -- this was the result of a silly typo. Now fixed. (Of course, ironically, in the course of fixing this I reset the timer on the submission...) Theopolisme (talk) 10:56, 6 May 2014 (UTC)

[0.7] Feedback about cleaning the article again

{{resolved}}

This is releated to an archived discussion located here.

@Theopolisme: Please read the last line of that section again! (t) Josve05a (c) 21:38, 28 April 2014 (UTC)

@Josve05a: Thanks very much; this has now been fixed. Theopolisme (talk) 02:39, 8 May 2014 (UTC)

Teahouse invites

{{resolved}} When accepting/declining a submission, Teahouse invitation should automatically be sent unless the user already has one. I think this is pretty easy, and makes for directing users to the location that is set up to help them. Hasteur (talk) 02:29, 6 May 2014 (UTC)

Dup of #.5B0.7.5D_Feedback_about_the_teahouse above; already tracked in trello. Currently working on this, stay tuned! Theopolisme (talk) 11:07, 6 May 2014 (UTC)

[0.7] Feedback about time stamping of redirects

{{resolved}} Please read this thread and comment about whether the script can be modified to fix the timestamp so that the new search engine will search the most recent version of redirects, and thus not include them in the search when they no longer have the requested text. —Anne Delong (talk) 11:01, 6 May 2014 (UTC)

Never mind; it seems that this is not a script problem, and is being fixed as we speak. —Anne Delong (talk) 16:32, 6 May 2014 (UTC)

Force reload after cleaning

{{resolved}} As much as I appreciate the tool and the clever activity the inline refresh, if you take the click path

  1. Enter a AFC page
  2. Activate the "Clean" routine
  3. Wait for the cleaning to finish
  4. Click the "Review AFC" menu option

You are not presented with the AFCHR tool, but instead presented with nothing. As much as I don't want to go back to the server to get the updated page, the AFCHR tool is in a "final" state at that point. Hasteur (talk) 13:13, 6 May 2014 (UTC)

@Hasteur: Thanks for the report. The "BACK TO OPTIONS" link in the upper lefthand corner takes you back to the main screen and allows you to perform another action; I think you're saying that clicking the "Review" link when AFCH has already been loaded should perform the same behavior. Is this correct? Just trying to make sure I understand what you're requesting :) Theopolisme (talk) 21:56, 7 May 2014 (UTC)
"Back to options" is an option but I almost think that re-painting the page overall would be a better functionality since the text claims it was reloaded. If the text said "Changes displayed here" instead of "reloaded automatically" it would be more normal web page behavior. Hasteur (talk) 23:50, 7 May 2014 (UTC)
That would remove all the diff links/log of changes, which is not desirable. Back to options is not just an option, btw... it's been implemented since v0.2. Thanks, Theopolisme (talk) 00:32, 8 May 2014 (UTC)

I have now updated the script so that clicking the "Review (AFCH)" link when an instance is already open will refresh the instance and return to the main options panel. I'm going to go ahead and mark this as a resolved -- if I've jumped the gun, please feel free to comment here again and we can continue to discuss alternate solutions. Theopolisme (talk) 02:28, 8 May 2014 (UTC)

DEFAULTSORT

{{resolved}} When we accept a biography we are asked to populate LISTAS for the talk page. PLease could you consider also population DEFAULTSORT for the article page at the same time and from the same data? Fiddle Faddle 12:10, 8 May 2014 (UTC)

Hi Tim! The tool actually already updates DEFAULTSORT as well -- I agree, though, that it isn't made especially clear right now. In the rewrite script this should be more intuitive. :) Theopolisme (talk) 22:16, 13 May 2014 (UTC)

Unable to open the tool/gadget

{{resolved}} It won't open on User:Mycroft Sanchez/sandbox/, is this due to the articles name? (t) Josve05a (c) 13:24, 8 May 2014 (UTC)

Thanks, fixed now! Theopolisme (talk) 23:00, 13 May 2014 (UTC)

Sending message to user about accepting article

{{resolved}} In this edit it didn't put the template-message under a seperate section/headr. Why not? (t) Josve05a (c) 13:15, 11 May 2014 (UTC)

@Josve05a: Thanks for the report! I've fixed this now. Theopolisme (talk) 23:01, 13 May 2014 (UTC)

Where is the "Submission is improperly sourced" decline option?

{{resolved}} I have just started using this script and ran into a snag on my first try. Declining due to either total absence of references or no reliable independent sources is one of the most common reasons to decline a submission - but that decline reason is not in this new script. Declining as not notable might be an alternative except that when there are no references at all it is actually impossible to form an opinion about notability - without any sources we simply cannot know whether the subject is notable or not. Roger (Dodger67) (talk) 14:01, 15 May 2014 (UTC)

This decline reason is particularly needed for cases where the text of the article makes it very likely that the subject is notable (a professor, for example, or an actor who has won an Oscar, or an Olympic athlete), but reliable sources are needed to verify the information. —Anne Delong (talk) 18:02, 15 May 2014 (UTC)

@Anne Delong and Dodger67: I think you are mistaken; this decline option is included in the decline rationale list under "Submission content". Screenshot (second item) Are you saying that it is not appearing for you? My apologies if I've missed anything. Theopolisme (talk) 21:21, 15 May 2014 (UTC)

@Theopolisme: Now that I've seen your screenshot I realize that actually the entire "Submission content" section was not showing earlier today - but now it is. Something must have changed in the last few hours that fixed the problem. Roger (Dodger67) (talk) 21:46, 15 May 2014 (UTC)
@Dodger67:I'm glad it's working now. That's very odd, as I haven't made any changes to helper script in around 24 hours (and none to that section of the code in weeks). Let me know if the issue crops up again, and we can investigate further (perhaps there is an issue with MediaWiki's core script loading functionality?). Theopolisme (talk) 21:50, 15 May 2014 (UTC)
Happy to hear that this item is included. I will check for it the next few times I use the list just in case it's a gremlin. —Anne Delong (talk) 22:35, 15 May 2014 (UTC)

Talk pages?

{{resolved}}

Hello again, Theopolisme. I haven't accepted any Draft: submissions that have talk pages, so I can't check this for myself. I presume that if a draft is accepted, the script checks for this and moves the talk page if it exists. Right? —Anne Delong (talk) 15:38, 16 May 2014 (UTC)

Feel free to call me Theo if you'd like to save a few characters. :) Actually, no! Great catch of something I forgot to implement (*looks away guiltily*). I'll get on this soon. Theopolisme (talk) 00:07, 17 May 2014 (UTC)
  • You should get to it VERY soon as I plan on starting to break the comments and AFC templates out of mainspace and put them in talk space like they are suppose to be next week. Templates I expect to land on /editnotice as well so they can be seen on all pages. — {{U|Technical 13}} (t • e • c) 12:58, 17 May 2014 (UTC)
  • Wait a sec, what? You're moving AFC templates/comment to the talk pages too? I knew that was the general idea, but how are users going to see them? Is there a link to a consensus for this? Editnotices are only seen "when editing"...this sounds like something that would require an extension (:P), at which point the whole idea of templates at all is a waste and we should just use a db table... Have I been under a rock recently? Theopolisme (talk) 15:21, 17 May 2014 (UTC)
@Technical 13: Wait what? "as I plan on starting to break the comments and AFC templates out of mainspace and put them in talk space like they are suppose to be next week." Do you have consensus for this change? (t) Josve05a (c) 16:46, 17 May 2014 (UTC)
  • It was the consensus and whole purpose for creating the draft namespace in the first place. So, yes. — {{U|Technical 13}} (t • e • c) 19:24, 17 May 2014 (UTC)
  • Link to that consensus... I don't think a consensus for what you're suggesting exists. To have the AFC submission banner on the Talk page will mean annother click that a reviewer has to make when doing reviews. To have the AFC submission banner on the talk page means that the "article" won't show any difference when a new user submits it, meaning we'll get hordes of the submits on the same page. Having the AFC comments on the talk page means that both reviewer and advocate for the subject have to read the talk page to improve. I see a valid case for "on acceptance" of a AFC submission moving the AFC comments to the talk page, but definitely not before. Hasteur (talk) 19:47, 17 May 2014 (UTC)
  • There is a difference between a consensus that articles-in-waiting should have have talk pages so that discussion among contributing authors can begin and a consensus that Afc comments on the existing submissions should be all moved to the talk pages. Please provide a link to the location of the specific discussion where the AfC reviewers decided to do this, because it seems that you are the only one who is aware of it. This is too important a change for the details and/or timing to be decided by one person. —Anne Delong (talk) 19:50, 17 May 2014 (UTC)

I've implemented and released a fix for the original request -- talk pages associated with AFC submissions will now be moved as well (if they exist) when a submission is accepted. I'm marking this thread as resolved, because the original request has been resolved. If and when clear consensus is demonstrated for reshuffling/repositioning of AFC templates/comments, please create a new thread on this page. Thanks, Theopolisme (talk) 22:55, 18 May 2014 (UTC)

Thanks, Theo - that was an important fix. —Anne Delong (talk) 17:45, 19 May 2014 (UTC)

[0.7] Feedback about the browser back button

{{resolved}} A small thing I noticed: I spend a lot of time looking at this category page: Category:G13 eligible AfC submissions. I select a page to examine. Sometimes I postpone or request deletion. When this happens, the script displays the new version of the page, but keeps the large colourful script notification saying that it is automatically reloading. Now, since I can see that the script has behaved properly, it's time to go back and look at the next submission, so I select my browser's back button. Nothing happens. I press it again and I am taken back to the category list. This is a minor nuisance, but since the back button doesn't work right away in some cases (for example, slow response from the Wikipedia server or spotty mobile connection) , I find myself waiting for the reload that isn't coming.... —Anne Delong (talk) 16:59, 19 April 2014 (UTC)

@Anne Delong: Sorry, I'm afraid I don't understand what you're saying -- the "reloading" never turns into a "reloaded"? Maybe I just haven't had enough sleep... Theopolisme (talk) 17:10, 20 April 2014 (UTC)

Resolving as stale; please feel free to reopen. Theopolisme (talk) 10:58, 21 May 2014 (UTC)

[0.7] Feedback about accepting articles

{{resolved}} I have found 2 problems when acception articles.

  1. It does not recognize {{WikiProject Disambiguation}} as a WikiProject.
    This is by design; the Disambiguation WikiProject is added based on the article's class. I've just added a check to ensure it won't be added twice, though (if the user manually enters it too for whatever reason), which will be uploaded soon. Theopolisme (talk) 21:18, 21 April 2014 (UTC)
  2. In the Add categories it says "Start typing to add categorie, missing an 's'?
    Looks like a spacing/style issue...that is supposed to say "to add categories...". Will investigate. Theopolisme (talk) 21:18, 21 April 2014 (UTC)

(t) Josve05a (c) 12:17, 21 April 2014 (UTC)

First issue fixed; the second issue is a problem with chosen.js, which has been reported upstream, but I can't fix on my end. Theopolisme (talk) 10:58, 21 May 2014 (UTC)

[0.7] Feedback about the teahouse

{{resolved}} I miss the option to invite users to the teahouse... . (t) Josve05a (c) 20:53, 21 April 2014 (UTC)

Gosh! I didn't notice that! I used it all the time. —Anne Delong (talk) 10:38, 28 April 2014 (UTC)
Thought, perhaps we want to auto-drop a Teahouse invite on users if they aren't displaying one? 95% of users who are taking the AFC route are not experienced and if they don't have a teahouse invite, it would help. The false positive case set (where the user is established, uses AFC, and gets a Teahouse invite when they don't really need it) is really small. Thoughts Anne Delong and Josve05a? Hasteur (talk) 13:09, 6 May 2014 (UTC)
I am usually somewhat selective about the invitations, avoiding spammers and jokers, etc, but it likely wouldn't matter that much if they got one. Would you include IP submitters? If you want to target a little more specifically, maybe the script could also check to see if the user's talk page has an archive page - if so, they're likely not a new user. And if it has a Teahouse Talkback message they likely already know about the Teahouse. Some users routinely remove notices from their talk pages after reading them and might be annoyed if they are replaced every time their submission is declined, but on the other hand the same thing could happen with a manually selected invitation. Another option might be to have a checkbox for an invitation, but to have it pre-checked. I would be happy with either the automatic or the checkbox approach. It's only the lack of a way to send the invitation that would be problematic. —Anne Delong (talk) 14:15, 6 May 2014 (UTC)

I have now added a checkbox (checked by default) shown when declining to add a Teahouse invite to the submitter's talk page if they have not already received one (and by received one, I mean "has a Teahouse invite on their talk page at this moment"...yes, there are fancier ways of determining this involving page history and who knows what, but I don't necessarily see the value in them at this point: worst case, they get a second notification, life will go on). Anne Delong/Josve05a/Hasteur, please give a whirl when you get a chance and let me know if I've missed anything. Thanks! Theopolisme (talk) 02:24, 8 May 2014 (UTC)

I only suggested the more complex algorithm for the case where the invitations are automatic. As long asthere is an option to uncheck the box if the submitter is Hasteur, for example, or Jimbo Wales, maybe, then I am happy. —Anne Delong (talk) 12:56, 8 May 2014 (UTC)

[0.7] Feedback about tagging for deletion using "rewrite" (again)

{{resolved}}

This is releated to a discussion that is archived here.

I would like to get a diff link for when logging the deletion at CSD log. There is non at this moment. (t) Josve05a (c) 10:44, 29 April 2014 (UTC)

Draft: namespace and the review tool

{{resolved}} Please see Wikipedia_talk:WikiProject_Articles_for_creation#Draft:_namespace_and_the_review_tool for a discussion which seems to be relevant here. Fiddle Faddle 16:22, 7 May 2014 (UTC)

Seen. Theopolisme (talk) 10:58, 21 May 2014 (UTC)

[0.7] Feedback about the "Common / recently used"

{{resolved}} How does the "Common / recently used" work. I know I use 'blank' around 60% of the times, 'cv' around 20% and 'bio' around 10%. Still 'blank is not even on my list. Here is the 'suggestions':

  1. custom (which I never use)
  2. music (which I use around 5% of the times)
  3. test
  4. cv
  5. bio

Either I'm missing something, or 'blank' is not there....why not, since I use it so much (just check my contrb.) (t) Josve05a (c) 20:40, 8 May 2014 (UTC)

  • Josve05a I use custom a fair amount of the time. Sometimes it's to indicate multiple issues all at the same time, others it's to give explicit instructions that don't fit the pre-defined reasonings, others it's to give the exact guideline I think the submission is failing (i.e. Decline for notability vs Custom decline "This submission does not appear to pass WP:NFOOTY"). IMO, because we have that search box and we can type the first few characters of the decline reason to get it filtered down it makes it very simple for me to get to an answer quickly. Hasteur (talk) 11:45, 9 May 2014 (UTC)
  • I hardly ever use "Custom". However, it should be fairly easy to find out which decline reasons really are frequently used, since they art all categorized, "AfC submissions declined as whatever". One thing that bothered me, though, is that the general notability reason isn't listed under the notability section because it's at the top. The general one shouldn't be used unless the reviewer has already checked and made sure that none of the specific ones apply, so having it in a separate place slows one down, or encourages the reviewer to overuse the general reason without looking through the others. —Anne Delong (talk) 15:05, 11 May 2014 (UTC)
  • Hi Josve05a and Anne Delong. I agree that the list title is rather misleading; in fact, the only "common" element in it is "custom" (as there isn't really anywhere else for it to go). The rest of the list is very literally "recently used" -- it simply displays your last 4 decline rationales. It would probably be more useful to have some sort of counting mechanism to collect your most frequently used insteads...I'll look into the pros and cons of that at some point (specifically, the overhead of storing/processing that data, which shouldn't be too great). Thanks! Theopolisme (talk) 22:26, 13 May 2014 (UTC)
Having the most frequently use items at the top is often very handy in software, but unfortunately in this case there is no way to know which reason will be needed next - it's not like you can say, "I think I'll do all of the blank ones now'. I would rather have them sorted and in a predictable place where my brain can gradually learn where to look. If others like to have a shortlist at the top, I would prefer that there was also a complete list below rather than one with random items displaced. This is just me, though, and I think you'll find that there's no way to please everyone on this particular feature. —Anne Delong (talk) 22:42, 13 May 2014 (UTC)
Actually, I am using CatScan to find all the blank once. (t) Josve05a (c) 23:23, 13 May 2014 (UTC)
Yes, I've used Catscan in the past, but that won't work for most of the other reasons. Mostly I just go to the list of pages awaiting review and pick one, and I think that's what most reviewers do. —Anne Delong (talk) 16:36, 14 May 2014 (UTC)
@Anne Delong: Right, that makes a lot of sense. I've made the following changes:
  • Instead of recently-used decline rationales, *frequently used rationales* will be shown instead. Note that it will take a fair number declines for this list to become populated.
  • Rationales shown in the frequently used list will appear in the normal list as well.
  • (in the future) Once prefs are implemented, the option to disable the freuquently used list all together will become available.
Hope this is helpful :) Theopolisme (talk) 01:01, 14 May 2014 (UTC)
Looks like you have everything covered. Thanks. —Anne Delong (talk) 16:36, 14 May 2014 (UTC)

Checking the whitelist

{{resolved}} Dear Theopolisme: Can you explain why the script checks the whitelist every time someone loads up a reviewable page, rather than just checking once when the reviewer adds the script in their preferences? I am presuming there is a good reason, but the question is being asked at Wikipedia talk:WikiProject Articles for creation (okay, I started it...) —Anne Delong (talk) 19:18, 15 May 2014 (UTC)

Hi Anne. The script checks every time the page is loaded in case the user has been removed from the list (per the details on the Participants page about removing users). The information provided at WT:AFC by Technical 13 is completely incorrect, however...contrary to what has been said, checking the whitelist does NOT slow down page loads. I'll be honest, this irritates me quite a bit; the fact that someone is speaking on behalf of AFCH when they aren't actually involved in its development at this point any more than you and making inaccurate and exaggerated statements to push their own POV is bothersome, to say the least.
Let me attempt to clarify. I was concerned as well about impacting page load speeds when I implemented this feature, so I specifically modified it to check after the page has already loaded completely. This means that checking the whitelist has *zero* impact on load speeds, *zero*. In the case that AFCH is opened before the whitelist check finishes, the panel is simply destroyed if and when the check completes.
We could consider checking the whitelist only after every x days (or, say, once every browsing session, perhaps) -- that makes sense to me, if the community agrees (as the original RfC consensus was the AfC helper script [sh]ould be modified to not function unless they are on the whitelist, which implies checking on every load). I hope this helps, and I also apologize for any iciness in this post -- I appreciate everyone's help and feedback with the script. Theopolisme (talk) 21:38, 15 May 2014 (UTC)
I know absolutely nothing about scripts and programming, so feel free to tell me this is nonsense. Could the whitelist be checked when a user logs in or opens the site in their browser (for those who have "remember me" set) and then the script "remembers" the result of this "once per browsing session" check for as long as the user has WP open in their browser? Roger (Dodger67) (talk) 22:12, 15 May 2014 (UTC)
Yes, that's essentially I was saying above, except the check would be run and cached the first time in their browsing session when they opened an AFC-applicable page. (Techies, see js window.sessionStorage API for how this would be done). Theopolisme (talk) 22:17, 15 May 2014 (UTC)
  • I can see that I was entirely unclear, and that is entirely my fault. What I was saying, is that the list needs to be checked every time the script runs, so you can not review until the entire list has been checked by the script. The page will still load and you can read it, but you can't quickly quick decline because you will still need for the script to read the whitelist before reviewing will be an option. — {{U|Technical 13}} (t • e • c) 22:44, 15 May 2014 (UTC)
  • @Technical 13: Nope, I'm afraid you're still incorrect. Please read what I wrote above. In the case that AFCH is opened before the whitelist check finishes, the panel is simply destroyed if and when the check completes (and determines that the user shouldn't be using the script, of course). AFCH runs without waiting for the whitelist to load, and due to the magic of asynchronous JavaScript you can review just as quickly with or without the whitelist being checked. I hope this makes sense. Theopolisme (talk) 22:52, 15 May 2014 (UTC)
  • Well, it wouldn't matter anyway, Technical 13, because no one should be declining or accepting a submission within a few seconds of seeing it. Even the blanks and test pages need to be checked for technical errors. Thanks, Theopolisme, for your clear explanation, and good planning. —Anne Delong (talk) 23:21, 15 May 2014 (UTC)
  • I was really hoping you wouldn't emphasize that. Basically, that means the whitelist doesn't need to be checked to use the script and therefor can easily be bypassed and doesn't require anyone to be on the list to use the script. Bad planning. Please rethink this as there is a clear consensus that no-one not on the list should be reviewing. — {{U|Technical 13}} (t • e • c) 01:04, 16 May 2014 (UTC)
  • @Technical 13: I believe you are taking the whitelist waaaay to serious. The whitelist is a stopgap measure to prevent good-faith editors from reviewing if they do not meet the criteria - not a measure intended to build a fortress around the AFCH script. If a user wants to use the script they can, whitelist or not. Just consider these:
  1. The Participants page is not protected. Anyone can add themselves to the list to use the script.
  2. The AFCH script is javascript and thus publicly readable. If i wanted to bypass the whitelist i could just copy the script to a user .JS file and remove or reverse the whitelist check.
  3. Even if you were to use some extreme measures such as obfuscating the script it is still code executed in the users browser, allowing them to alter it.
Long story short: If someone wants to use the script, they can - and there is little we can do to prevent this. Excirial (Contact me,Contribs) 08:19, 16 May 2014 (UTC)
  1. Yet, but that is suppose to be the goal once we make sure that it is working properly.
  2. There has been talk about coming up with a way to prevent that including adding an edit filter to prevent moves from draft space by those not on the list.
  3. See point above, and the the additional point is "why make it easy for them?"
(edit conflict) Well, regarding the issues you raised:
  1. Fair enough, it can indeed be protected.
  2. I cannot fathom this will be implemented. When WP:Drafts was implemented it was explicitly intended for all drafts - submitting drafts trough AFC is recommended but not required. Locking down the movement of drafts trough an edit filter would effectively lock the draft name space to the AFC project, a change that I predict will be opposed by a quite a few editors. Any other filters that attempt to distinguish an AFC draft from a non AFC draft will be ineffective at best - If the script can be altered any identifying characteristics can be edited as well. Failing that an editor can just opt to press the move button, manually move the page and remove the AFC template.
As for the reduction of abuse potential: How many people have actively attempted to evade the whitelist so far? And how many have done so by means other than listing themselves on the whitelist? (As the error suggests?). Is there actually a storm we should bolt the door against, or are we closing the castle gates because there may be invisible enemies down in the woods? I honestly believe the vast majority of the editors will not attempt to evade the whitelist, and the ones that do will find some means to do so anyway. We can try to increase the difficulty of doing so but it feels like a waste of time to me. Excirial (Contact me,Contribs) 11:10, 16 May 2014 (UTC)
  • (re T13's "I was really hoping" comment) That's...not right, either. How about you just take a look at the code? [1] and [2]. All script-based processes are killed the moment the check is complete...not enough time for actions to complete. Theopolisme (talk) 10:56, 16 May 2014 (UTC)
  • (re later comment) The edit filter will never happen. Draftspace !== AFC space, and the community would explode if anything like this were to be implemented...and rightly so, I believe. AFC is just a project, one process for doing things, and community-wide discussion would need to occur before ever considering making it essential (!!) to the Draft workflow. And to answer why make it easy for them? WP:AGF, mainly, and it's open source and if they really care so much about using a script, they'll figure out how to use it regardless, as Excirial says. Theopolisme (talk) 10:56, 16 May 2014 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Articles_for_creation/Helper_script/Rewrite/Archive_2&oldid=609561087"