Wikipedia talk:WikiProject Articles for creation/Helper script/Rewrite/Archive 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)

• Wikipedia:Village pump (proposals)/Archive 107#Proposed new Draft namespace is the consensus. You need to read the entire thing to see it, not just the summary. The summary isn't the consensus, the entire proposal is. — {{U|Technical 13}} ^{(t • e • c)} 19:57, 17 May 2014 (UTC)

  I think you are misinterperting a minority (at best) consensus and therefore have put the question to a explicit consensus exercise (Wikipedia_talk:WikiProject_Articles_for_creation#Proposal:_AFC_submission_and_afc_comments_location_on_Draft_namespace_articles). As the process you are proposing implementing is under discussion (especially evidenced by 3 editors indicating that this sounds like a bad idea) any actions to implement that will be treated as against consensus and reverted as such. Hasteur (talk) 21:01, 17 May 2014 (UTC)

  I have replied in detail about this HERE, so I won't duplicate. —Anne Delong (talk) 03:51, 18 May 2014 (UTC)

  T13: if you insist on carrying out these actions contrary to consensus, you will probably find your account blocked fairly quickly. I urge you to discuss and find the best approach to this and, frankly, stop being so pig-headed on this issue. — Martin (MSGJ · talk) 20:45, 18 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.
   • And it added 2 {{WikiProject Disambiguation}}'s here.

   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?"

• Long story short, the potential for abuse can be greatly reduced; so, why not reduce it? — {{U|Technical 13}} ^{(t • e • c)} 10:14, 16 May 2014 (UTC)

(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)

`small=yes`

{{resolved}} @Hasteur and Technical 13: Do either of y'all know if it was ever decided whether or not the script should add "small=yes" to old decline templates? It's trivial to implement, but I wasn't sure if there was some sort of Lua solution in the works... By the way, as a proof of concept, I am extension-izing AFC in a mini-sprint over the next few weeks mainly as a proof-of-concept for using databases and whatnot. So feel free to look forward to that ;) Theopolisme (talk) 23:53, 20 May 2014 (UTC)

• IIRC But I've slept and gone well over the Ballmer peak several times but I think there was support for it, but support for the parameter in the template needs to be wired in first. I definitely don't have the TemplateFu to try and figure out the right way to supress the majority of the AFC declined template. Hasteur (talk) 01:15, 21 May 2014 (UTC)
  • It was working well before and I don't remember reading any complaints about it. I think it's a great idea. We need to see the previous decline history, but not very detail in a giant box. An alternative might be to have all except the last decline inside one of those collapsible NavFrames, but I suppose that would be trickier to implement and to strip out when accepting. Aren't the templates already set up for this, since it's not new? —Anne Delong (talk) 11:30, 21 May 2014 (UTC)
• Yes, Theo, there is support for it. The template does accept the parameter just fine, the only issue was with a bug in the system depending on which order the templates were posted on the page and human interference. The TemplateFu thing I believe Hasteur is thinking about was the talk about incorporating all of the decline templates into a master multiple decline template of the same style as multiple issues. That is unlikely to happen at this stage and it is more likely that the guided tour that will be in place in the draft namespace will automatically help with the proper display of this. For now, the script should make all except the most recent small, and if there is any doubt about which one is the most recent, none of the questionable ones should be small. — {{U|Technical 13}} ^{(t • e • c)} 11:46, 21 May 2014 (UTC)

Okey-dokey, this has been implemented and is now live on enwiki. Thanks, Theopolisme (talk) 22:35, 21 May 2014 (UTC)

[0.8] Feedback about funny name

{{resolved}} Is there not a "funny name" for 0.8? (t) Josve05a (c) 11:15, 21 May 2014 (UTC)

@Theopolisme: Please change AFCH.consts.versionName = 'Less is More'; to Wandering Walrus in afch-rewrite / src / afch.js. (t) Josve05a (c) 11:38, 21 May 2014 (UTC)

Hi Josve05a. The version name was updated when the new version was released (your link leads to an old version of the code), however, as we move towards a production 1.0 release, (I feel that) the fun names aren't exactly appropriate for a major script. A little easter egg, though: if you hover over the version number, you can still see the "internal codename" (aka, me having a little fun now and then). :) Theopolisme (talk) 20:42, 21 May 2014 (UTC)

[0.8] Feedback about timestamps

{{resolved}} I think the tool resets both the submission date (ts) and decline date (declinets) to be CURRENTTIMESTAMP when declining. No bugs or problems though and pretty fast. Rankersbo (talk) 06:14, 22 May 2014 (UTC)

@Rankersbo: Could you provide an example of this? I think you may be looking at WT:AFC/sand, the development sandbox which I use for testing the script, where I have actually changed the timestamp manually so that it doesn't appear mixed into the review queue...the script shouldn't be changing any of this on regular submissions, though, and if it is, I'll be happy to take a look. Theopolisme (talk) 10:51, 22 May 2014 (UTC)

OK see this diff [3] Rankersbo (talk) 14:26, 22 May 2014 (UTC)

@Rankersbo: Thanks, great catch! This was an accident and has now been fixed... the timestamp will *not* be reset from now on. Sorry for the inconvenience, Theopolisme (talk) 20:49, 22 May 2014 (UTC)

[0.8] Feedback about cleaning the submission

{{resolved}} I "cleaned" Draft:Yigal Meir and the script reported "Working", and then the small text on the left reported that the file was saved, but the "Working" did not disappear. The submission was cleaned, though, and the file saved, so everything was okay.. —Anne Delong (talk) 13:14, 22 May 2014 (UTC)

@Anne Delong: Sorry about that; you encountered one of the temporary side effects of a possible resolution for User_talk:Theopolisme#AFCHRW which, sadly, apparently didn't work as I had hoped. Thanks for bearing with me! Theopolisme (talk) 22:41, 22 May 2014 (UTC)

Automatically open the review panel on AfC submissions

{{resolved}} I do not want it to "automticly open" on the submissions history page or when wieving diffs. Thanks. (t) Josve05a (c) 18:27, 24 May 2014 (UTC){

Thanks! Fixed. Theopolisme (talk) 22:43, 24 May 2014 (UTC)

[0.6] Feedback about marking a submission as under review

{{resolved}} Dear script developers: Today I wanted to postpone a G13 eligible submission, but I accidentally clicked on the "Mark as reviewing" instead. I got one of those "bad token" errors. That was good, because I didn't really want to review the draft, but maybe a more informative error message such as "Draft hasn't been submitted" or some such would be better. Not a priority, since the script did the right thing by not marking the draft. —Anne Delong (talk) 08:43, 2 April 2014 (UTC)

Cleaning out backlog... I don't think I'll be implementing this based on the way that the code is currently structured (I haven't really created a mechanism to drop in secondary listeners, and I'm not sure it's worth the time given other issues). If this is found to be unclear for other users, though, we could revisit it. (An aside: bad token errors should now be a thing of the past as I've created a "just-in-time" token fetcher which alleviates the problem). Theopolisme (talk) 14:42, 26 May 2014 (UTC)

Speedy a vandal/attack subission

{{resolved}} @Theopolisme: An option to mark a submission for speedy after declining for vand (possible other reasons too). A dropdown-list with possible criteria like G3 and G10 instead of just {{db-reason}}. (t) Josve05a (c) 12:43, 7 April 2014 (UTC)

• Josve05a is there any reason to not just use Twinkle for this? I'm concerned about script bloat otherwise. The other option is that since Twinkle is modularized, perhaps AFCH could just call that module (hence we don't have to recode everything)? — {{U|Technical 13}} ^{(t • e • c)} 14:26, 7 April 2014 (UTC)

The option to call that module is good. I feel like I want to decline an article to make it dissapere from the category and clearing the backlog faster instead of just tagging it for deletion with Twinkle. (t) Josve05a (c) 14:30, 7 April 2014 (UTC)

(Plus I want to get as many points in the drives as possible...) (t) Josve05a (c) 14:40, 7 April 2014 (UTC)

Well, a submission can be declined, and then Twinkle can be used right after. However, this means two different messages on the submitter's user page. There may be cases when this would be confusing; for example, if the first one said "Fix this and resubmit" and the second was a deletion notice. The combined function works well with copyvios - are there others which are just as obvious - maybe hoaxes? Silly test edits like "my girlfriend is sooo pretty"? However, I don't think any of this is necessary before the script is handed out for people to use. —Anne Delong (talk) 17:33, 7 April 2014 (UTC)

Cleaning out the backlog... I've tracked this as something to contemplate in the future (it seems like a good idea), but for now I don't have the development resources to devote to further investigation. Probably will be a post-1.0 feature. Theopolisme (talk) 14:43, 26 May 2014 (UTC)

[0.7] Feedback about sending messages to users

{{resolved}} When sending a message to user it adds two blank lines at the top of the page (see this). It should not add those. (t) Josve05a (c) 20:22, 3 May 2014 (UTC)

Gotcha, these are (sorta) intentional for cases where the message is *not* at the top of the page. But I see what you're saying...there's not really an easy mechanism to test for this, but I'll see what I can do if I have time. I think some other bugs are more pressing, though. Theopolisme (talk) 10:46, 5 May 2014 (UTC)

Tracked as something to contemplate in the future (post-1.0). Given the way we structure the text addition to minimize API requests (resulting in a faster save), I'm not sure it's worth making the extra request to determine whether or not the page exists... but we'll see. Theopolisme (talk) 14:45, 26 May 2014 (UTC)

Provide an option to use the old, small, less in-your-face buttons

Resolved

The large, colourful interface works okay on a vertically oriented screen, but is too large and space consuming on a 16x9 screen, which has plenty of width to show all of the options instead of hiding some, but not much height for multiple rows of text. Perhaps in the future the script will give users a choice, allowing them to select the larger style when using a touch screen or mobile device or the small one if using a pointer. However, again, as long as the old script is not removed, this shouldn't deter you from rolling out the new script for general use. Just be prepared to field lots of opinions about this. —Anne Delong (talk) 17:48, 7 April 2014 (UTC)

Actually, providing a less in-your-face style should not be too difficult to do. I'm putting this on my todo list -- through the (coming soon) preferences dialog, it should be possible to configure the script to use a different look and feel :) Theopolisme (talk) 21:58, 7 April 2014 (UTC)

Yeah right, "soon". :-P (t) Josve05a (c) 22:01, 7 April 2014 (UTC)

@Josve05a: Come on, we're all volunteers here. WP:DEADLINE, etc. Sadly, this isn't my day job (no matter how much I wish it was). Theopolisme (talk)

• E = mc^soon — {{U|Technical 13}} ^{(t • e • c)} 01:02, 8 April 2014 (UTC)

Well, functionality comes first, and the script appears to be pretty functional right now. Another difference between the old interface and the new is that the text box for adding comments in the new one is very narrow. Perhaps the box size could be a percentage if the screen width instead of a fixed size. Again, though, this is just a perk, and shouldn't hold up any roll-out. And many of us appreciate how time consuming software programming is, and how difficult it is to design something that will please everyone. —Anne Delong (talk) 03:16, 8 April 2014 (UTC)

• Josve05a the problem with the small buttons that is used in the legacy script (can we call it that yet?) is that they won't load on a mobile device on anything new than FF19 I think it was they broke when using FF. The new buttons Theo is using seem to work on all browsers with no issues. — {{U|Technical 13}} ^{(t • e • c)} 03:21, 8 April 2014 (UTC)

[0.8] Placeholder text

I'm really not liking the placeholder text in the "input boxes" (terminology?) presented when declining a draft. I just declined one as "already exists" and the dialogue had "Chocolate chip cookies" in the space where the actual existing article title was to be entered. A "Comments" box was also pre-filled with a quite large paragraph of "blah blah" that I didn't bother to read. IMHO an "input box" should be empty when presented for filling - particularly when filling it is not mandatory. Reviewers are not newbies, I found the placeholder text to be quite patronizing. Roger (Dodger67) (talk) 11:04, 20 May 2014 (UTC)

Fair enough. I'm inclined to agree with you, and you're entirely correct in that reviewers are hardly newbies. The goal is to find a balance between "no information provided at all" and "enough information provided to explain how a given field should be filled out"... @Anne Delong, Technical 13, and Hasteur: thoughts on removing these placeholders? (And/or which should be possibly retained/slimmed down/whatever). Thanks Roger for bringing this up! Theopolisme (talk) 20:57, 20 May 2014 (UTC)

Hrm... Comment box I think could be blanked out, but I'm sondering if we want to pre-populate on some of these.... Hasteur (talk) 21:08, 20 May 2014 (UTC)

• I actually prefer a fair amount of automated pre-selection/pre-filled text input fields. Quite often this is an extremely repetitious task and the more the script can do on its own, the better in my opinion. Roger, it's not meant to imply that reviewers are newbies or are incapable to put in the right things. Would a simple <button class="clearField" title="Clear the default text"><img src="http://upload.wikimedia.org/wikipedia/commons/2/2c/WikEd_clear_summary.png" alt="Clear field" /></button> that clears the default text work? — {{U|Technical 13}} ^{(t • e • c)} 21:12, 20 May 2014 (UTC)

T13, he's not talking about prefilled, he's talking about placeholder text that tells users *how* to fill out fields (and/or provide examples of syntax). I agree more automated prefilling would be nice, but that's not what this thread is about, unless I'm misunderstanding something... Theopolisme (talk) 21:15, 20 May 2014 (UTC)

• In the case that I'm misunderstanding the topic (entirely likely), there is no reason for the placeholder= text to not be there and there is no reason for it to not be specific. Not having it is discouraging and more likely to turn new reviewers away or old reviewers with memory issues or simply people that don't review often enough to keep up with the constant stream of interface changes. These texts are a very light grey (at least on my browser) and technically do nothing except remind new reviewers what is expected. — {{U|Technical 13}} ^{(t • e • c)} 21:38, 20 May 2014 (UTC)

I think that the placeholder for the "comment" functionality should stay: Enter your comment about the submission using wikicode syntax. Your signature will be added automatically. This is useful information about *how* to comment, and should not be removed.

I think that when declining, we should change the placeholder to: Elaborate on your decline reason here using wikicode syntax. This is once again valuable information (wikicode syntax is okay), but I've removed the fluffy "clear supportive..." text.

Thoughts on these two? Theopolisme (talk) 21:15, 20 May 2014 (UTC)

• I don't think that the comment boxes should be filled with any text that is intended to show up - if there is default text it is likely in the template itself. I've try to ignore the sample text, but it could be confusing to new reviewers - especially since the colour of the text is only slightly lighter than active text (at least on my screen). For the first while I kept trying to delete it. Maybe the comment box, if unused, could say <no comment entered> or something bland like that. When reviewing I have a word processor open with the most common comments that I like to write, and I copy, paste and modify to save typing. —Anne Delong (talk) 21:27, 20 May 2014 (UTC)

Right, that makes sense. My worry is that users wouldn't understand that they could enter wikicode in the comments, for example, or that they were signed automatically... Placeholder text in and of itself isn't something new (see the Search box in the upper righthand corner, for example :) ). Theopolisme (talk) 21:31, 20 May 2014 (UTC)

I've remove the fluff about being clear and supportive, since that's (to me) obviously unnecessary. We can continue to discuss other placeholders. Theopolisme (talk) 21:55, 20 May 2014 (UTC)

Problem with frequently-used declines

Moved from User talk:Theopolisme

• It would also be nice if the helper knew which our most-used criteria were, and list them as a top-10 before the other ones. I think that's what you intended with the current layout, but its based on general AfC statistics, right? Because my top 5 aren't the ones appearing there. I know nothing about coding, so I might be way off here... FoCuSandLeArN (talk) 00:21, 23 May 2014 (UTC)

• Actually, what you suggest is pretty much what I originally implemented in the script! The "frequently used" list at the top of the decline menu builds itself as you decline submissions, based on your personal decline habits, by storing a list of the number of times you use each decline rationale. If this doesn't appear to be working, let me know, though, and I can check out if there's some sort of logging error and it's not picking up your declines... It only works with declines made using the rewrite, so it will take a while for you to make enough declines to create a useful dataset. Theopolisme (talk) 00:32, 23 May 2014 (UTC)

• Yeah, it doesn't seem to be logging them correctly as far as I can tell. It should have a decent sample size by now. I also wanted to point out that the previous problem also happens for comments. Regards, FoCuSandLeArN (talk) 19:20, 23 May 2014 (UTC)

• @FoCuSandLeArN: Okay, that's weird. What do you see in the "Frequently-used declines" list? Also, while we're at it, can you do me a favor and let me know the output of this debugging statement?

• In Chrome, load the Wikipedia Main Page.
• Open the JavaScript console by pressing Ctrl-Shift-J ([4] has more instructions)
• In the text prompt next to the blue right arrow, type mw.user.options.get( 'userjs-afch-decline-counts' ); and press enter
• Please copy and send me the text that it outputs in response.

Thanks very much for your help with this, and sorry it wasn't working as desired. Theopolisme (talk) 20:40, 23 May 2014 (UTC)

• "{"music":3,"joke":1,"cv":1,"corp":2,"lang":1,"exists":1,"adv":1}" is what appears. Exist and adv do not come up on the actual list I see when I load it. If I were to give an estimate of what I think those should honestly be, I would say nn, bio and corp are my most used by a big margin. I am bemused as to why lang, cv or joke are there; I seldom use those. No worries, this is how we make things better! Thanks for your dedication, FoCuSandLeArN (talk) 19:34, 25 May 2014 (UTC)

• Theo, I can confirm it isn't working correctly. I got {"v":1} returned this first time I queried it and {"music":1} the second and subsequent times for this chunk of reviewing. — {{U|Technical 13}} ^{(t • e • c)} 21:35, 25 May 2014 (UTC)
• I've expanded by reviewing base with this chunk of reviewing and am now getting {"music":1,"context":1,"nn":1} on every query of mw.user.options.get( 'userjs-afch-decline-counts' );. — {{U|Technical 13}} ^{(t • e • c)} 22:04, 25 May 2014 (UTC)
• I should note that before I started the two chunks of reviewing above, I was getting null (because I've been slacking in my reviewing duties). — {{U|Technical 13}} ^{(t • e • c)} 22:20, 25 May 2014 (UTC)

This is interesting, mainly because I can't replicate it, which makes it all the more difficult. :/ @Technical 13: can you also look at AFCH.userData.get( 'decline-counts' ) just in case that's returning different results?

Also... if you'd like to be really helpful, could you set AFCH.consts.mockItUp = true; in your console before using the script, then simulate a single decline (just do it normally -- it won't actually decline the page, though, because you've enabled mocking), and compare the value of decline-counts (via userData) before and after and seeing if it changes based on what you did?

Thanks again guys. This is a very weird bug -- I just did exactly what I described above and everything worked flawlessly. Theopolisme (talk) 23:46, 25 May 2014 (UTC)

• I'm not sure about that...

mw.user.options.get( 'userjs-afch-decline-counts' );
"{"music":1,"context":1,"adv":1}"
AFCH.userData.get( 'decline-counts' );
ReferenceError: AFCH is not defined
AFCH.consts.mockItUp = true;
ReferenceError: AFCH is not defined

is what I got back (haven't attempted a decline yet). — {{U|Technical 13}} ^{(t • e • c)} 23:57, 25 May 2014 (UTC)

@Technical 13: Uh...that means AFCH was never loaded...you are on an AfC-applicable page, right? :P Theopolisme (talk) 00:01, 26 May 2014 (UTC)

• Theo, of course... (ZzzzZZZZzz)

Long image of technical crud no-one really understands no matter how much they say they do...

File:Test results (test set 1).png

— {{U|Technical 13}} ^{(t • e • c)} 00:11, 26 May 2014 (UTC)

@Technical 13: Cool. So it looks like there it *is* recording an update, which is a start. When you reload or go to another page, does that `nn: 1` persist? Theopolisme (talk) 00:18, 26 May 2014 (UTC)

By the way, to clarify why mw.user.options and AFCH.userData have different results: mw.user.options is only populated once on pageload by MediaWiki. I implemented some frontend caching in userData so that results are reflected immediately (mw.user.options is set via api request). Theopolisme (talk) 00:21, 26 May 2014 (UTC)

• Theo:

Long image of technical crud no-one really understands no matter how much they say they do...

File:Test results (test set 2).png

— {{U|Technical 13}} ^{(t • e • c)} 00:34, 26 May 2014 (UTC)

• Okay, so that appears to work correctly. Let's try to figure out when items disappear, then..? Theopolisme (talk) 00:36, 26 May 2014 (UTC)

• Okay, so I ran a couple tests, and when I selected the decline reason from the list of "frequently used" up top, it registered the decline on AFCH.userData.get( 'decline-counts' ); but forgot about it when I reloaded the page. When I selected the decline reason from the static list below, it registered and remembered. — {{U|Technical 13}} ^{(t • e • c)} 00:47, 26 May 2014 (UTC)

• @Technical 13: Hmm, I can't replicate that, and I don't see where in the code it would be possible for that situation to occur, given how we treat the "frequently used" as identical to normal declines (same <option value='x'>...in fact, they are literally clones of the other elements). Could you try again and ensure that wasn't just a random occurrence?

Feel free to take a look at the code, too -- maybe I'm just missing something obvious because I've been working with it for so long. displaying the reasons in the list, incrementing the counters, AFCH.userData implementation. Theopolisme (talk) 01:02, 26 May 2014 (UTC)

	if ( declineCounts[declineReason] ) {
		declineCounts[declineReason] += 1;//Why not just// declineCounts[declineReason]++;
	} else {
		declineCounts[declineReason] = 1;//This triggers an internal red flag for some reason
	}

Theo:

Long image of technical crud no-one really understands no matter how much they say they do...

File:Test results (test set 3).png

I will do some more testing in the sandbox tomorrow when I'm awake as to not be disruptive and not using mock up mode. Good night good sir. — {{U|Technical 13}} ^{(t • e • c)} 01:52, 26 May 2014 (UTC)

• As far as image licensing goes, CC-zero supersedes the CC BY-SA 3.0 requirement. — {{U|Technical 13}} ^{(t • e • c)} 00:34, 26 May 2014 (UTC)

Screenshot of what to do in FireFox

Anne Delong report

• Just out of curiosity, what does mw.user.options.get( 'userjs-afch-decline-counts' ); return for you per the instructions above? If you are using Firefox instead of Chrome, it is ctrl+⇧ Shift+k to access the console where you type in the code. — {{U|Technical 13}} ^{(t • e • c)} 22:25, 25 May 2014 (UTC)

Yes, I am using FireFox - trying not to contribute to megacompanies taking over the world - and using your keyboard shortcut I was able to access the console. I haven't done this before, so I didn't see an obvious place to paste in the code. Sorry, the only web programming I've done besides HTML, CSS and Wikicode is server side stuff. —Anne Delong (talk) 23:02, 25 May 2014 (UTC)

(oh, yeah, and Java, but that had to be compiled) —Anne Delong (talk) 23:15, 25 May 2014 (UTC)

• See screenshot. → — {{U|Technical 13}} ^{(t • e • c)} 23:36, 25 May 2014 (UTC) → → →

@Technical 13: You need to re-license that file as CC-BY-SA 3.0, because it has Wikipedia-text (this disussion) on it. (t) Josve05a (c) 00:26, 26 May 2014 (UTC)

• CC-zero is fine. — {{U|Technical 13}} ^{(t • e • c)} 00:30, 26 May 2014 (UTC)

• Okay, silly mistake - the text input box was hiding behind my task bar. I moved it to the top and voilà! Here are the results:

mw.user.options.get( 'userjs-afch-decline-counts' );
"{"lang":1,"corp":2,"cv":2,"test":2,"not":1,"blank":1}"
mw.user.options.get( 'userjs-afch-decline-counts' );
"{"lang":1,"corp":2,"cv":2,"test":2,"not":1,"blank":1}"
mw.user.options.get( 'userjs-afch-decline-counts' );
"{"lang":1,"corp":2,"cv":2,"test":2,"not":1,"blank":1}"

—Anne Delong (talk) 00:12, 26 May 2014 (UTC)

• That implies you've only reviewed 9 total drafts... Not quite working right... Would you say that you use corp, cv, and test the most often? — {{U|Technical 13}} ^{(t • e • c)} 00:30, 26 May 2014 (UTC)

I wonder if data is being erased at some point in time... since it looks like new data is added correctly, and then disappears... just thinking aloud. Theopolisme (talk) 00:34, 26 May 2014 (UTC)

• That's likely right. According to my contributions, in the past week I have accepted nine submissions, declined eight, and postponed 15. I've also been using the script for making comments and cleaning submissions. Some of my Afc work has bypassed the script: changing old submissions into redirects, moving sandboxes to Draft, fixing format problems, adding reflists, deleting G13s, etc. Off-wiki musical events, WP:IEG committee work, learning to do history merges and undeletions, etc., have also been keeping me away from the queue. —Anne Delong (talk) 01:56, 26 May 2014 (UTC)

Analysis

@Technical 13: I'm not even going to pretend I can look at the console logs without my eyes glazing over. Could you summarize your findings, perhaps? Thanks so much for all your help. Theopolisme (talk) 14:49, 26 May 2014 (UTC)

• Theopolisme, my eyes were glazing over too... What I found is that section of the script works flawlessly in mockup mode, but not in live mode. I will need to do some more testing to isolate the steps to reproduce every time, and I'm too brain blah to do it today... — {{U|Technical 13}} ^{(e • t • c)} 18:16, 26 May 2014 (UTC)

• Is there anything I can do to help speed up that process while your brain de-blahs? FoCuSandLeArN (talk) 18:37, 26 May 2014 (UTC)

• Depends on how techy and JS knowledgeable you are. You are welcome to go to the AFC sandbox, open up your console and try all kinds of different things to see if you can isolate when the script counts the decline and when it doesn't. Will need to test each reason (standard and frequent list versions both), and test with mockup on and off... Many, many tests to see which reasons (in which section) fail in which modes... — {{U|Technical 13}} ^{(e • t • c)} 19:14, 26 May 2014 (UTC)

• Well I'm sorry to say I'm not knowledgeable... FoCuSandLeArN (talk) 19:18, 26 May 2014 (UTC)

Okay, cool! Thank you T13 :) I'm able to replicate the "not working in real mode" issue with a decline as "adv" and will look into it further tonight. Being able to replicate the bug is most of the battle -- I'll try to knock this out. :) Theopolisme (talk) 23:15, 26 May 2014 (UTC)

I spoke too soon. It worked flawlessly the second time I tried a decline as adv in real mode. This is so strange. Theopolisme (talk) 23:41, 26 May 2014 (UTC)

• I noticed it is somewhat hit or miss as well, still needs more refining to find the exact cause. — {{U|Technical 13}} ^{(e • t • c)} 23:43, 26 May 2014 (UTC)

@Technical 13: Can you try this behavior out and see if you can replicate what I get:

• Decline a page using a decline reason for the first time (i.e. one that isn't listed in decline-counts)
• Examine AFCH.userData (it should include the updated item)
• Now reload the page once, and examine AFCH.userData (the item should appear to disappear from the list)

  If you decline the page *now*, the item will be lost and overwritten *for real*, so DON'T DO THAT, instead...

• Reload the page *again*! The old items might appear now in the list... if so, stop, otherwise:
• Use the script to perform another action on the page (say, comment or submit).
• Then reload *again*. The previously missing items should reappear now.

Any luck with this? Rather convoluted, I know, but something I encountered pretty consistently... is MediaWiki caching the values of mw.user.options and not pushing out an updated version until the page is purged (or edited), perhaps? Theopolisme (talk) 23:55, 26 May 2014 (UTC)

Debugging console

Update: I've modified the script to print out the values of userData and mw.user.options whenever the main panel is loaded (so initial load and whenever you hit "back to options"). Hopefully this will make debugging a bit easier.

I've been replicating this on testwiki (not consistently, though). Just looking for a pattern... :) Theopolisme (talk) 02:23, 27 May 2014 (UTC)

• On this note, it would be cool if there was an independent debugging console that returned all kinds of information that could be useful for submitting bug reports. I'm also wondering if all this stuff we are saving in the browser's local storage shouldn't be saved on an actual page, ya know, for if people use multiple browsers or computers, or review only at the library/cafe/etc? This way the script will work consistently for them no matter where they are. I understand that mw.user.options should be saving it to their logged in user account, but that may not always be the case or they may use two accounts (a secure one and one for insecure locations). This presents its own new feature option: being able to specify a location for the configuration settings. Otherwise it may appear that the feature (and the saving of user preferences) doesn't work at all to some non-tech people. — {{U|Technical 13}} ^{(e • t • c)} 17:29, 27 May 2014 (UTC)

• I don't know, I feel like that might be over-complexifying things. mw.user.options does work for the overwhelming number of cases, and with our net of fallbacks I find data loss quite unlikely. I'd rather avoid editing wikipages if possible, plus the value for multiple accounts just doesn't seem to be worth the development effort at this point in time. Theopolisme (talk) 18:17, 27 May 2014 (UTC)

I think I may have an answer

@Technical 13: Further simplified process for replicating the bug:

1. Decline the submission once using the script.
2. Now reload the page. If the decline appears not to be counted, continue reloading the page repeatedly. Eventually the decline will show up in the counts list.

And... that's it. In short, ResourceLoader occasionally serves cached versions of mw.user.options. This is almost certainly a bug, but not with AFCH. Rather, it's with MediaWiki itself and its ResourceLoader caching infrastructure. This explains why the issue has been so difficult to replicate -- if the user reloads/browses to other pages enough times before their next decline, the old cache will expire and update itself, and the problem won't occur.

I hope this makes some sense -- T13, let me know if you think I've missed something, since I may just be very tired and desperate to latch onto a solution (any solution!), but I have tested this quite a bit and it's always been the case that enough reloads update the cache. Thoughts? Next steps? (Bugzilla?) Theopolisme (talk) 02:54, 27 May 2014 (UTC)

---

Resolution: this bug should now be resolved -- or rather, at least worked around. I've added *another* layer of AFCH caching (via localStorage). Here's the explanation I added to the source code, if you're interested:

The reason for this redundancy is because of an obnoxious
little thing called caching. Ideally the script would simply
use mw.user.options, but *apparently* MediaWiki doesn't always provide
the most updated mw.user.options on page load -- in some instances, it
will provide an stale, cached version instead. This is most certainly a
MediaWiki bug, but in the meantime, we circumvent it by adding numerous
layers of redundancy to the whole getup. In this manner, hopefully by
the time we have to rely on mw.user.options, the cache will have been
invalidated and the world won't explode. *sighs repeatedly*

And here's the commit in which the issue should be resolved. Basically it just relies on the user visiting pages that *aren't* already cached in order to force an update to mw.user.options. This should probably be a bug, though. :P Aaccttualllyy... Legoktm, could you possibly help redirect this to wherever it needs to go? I don't really know who deals with caches and varnishes and ResourceLoader and whatnot, but the tl;dr is that mw.user.options isn't always updated when the page is reloaded.

Thanks to T13, Anne, and FoCuSandLeArN for your help in hunting down this issue! Theopolisme (talk) 04:16, 27 May 2014 (UTC)

• I've only read the post I was pinged in but that makes sense as to why I got two different results for my first batch of reviews (v then music). Certainly implies a caching issues. — {{U|Technical 13}} ^{(e • t • c)} 12:10, 27 May 2014 (UTC)

• Hooray! Well done! FoCuSandLeArN (talk) 12:27, 27 May 2014 (UTC)

Heads up

Sorry to spring this on everyone, but User_talk:Theopolisme#Heads_up:_no_internet_access_until_June_19th. Thanks! Theopolisme (talk) 14:57, 28 May 2014 (UTC)

Enjoy your vacation, Theo! —Anne Delong (talk) 15:33, 28 May 2014 (UTC)

And I'm back! I've got a few things waiting for me first, and then I'll be able to get back to work on the reports here. Thanks, everyone! Theopolisme (talk) 14:21, 20 June 2014 (UTC)

Feedback about the AFCH script

Dear Theo: I used the script many times today and ABSOLUTELY NOTHING WENT WRONG. What's up with that? —Anne Delong (talk) 22:21, 25 May 2014 (UTC)

<discussion about a technical problem merged into the applicable thread @ 14:54, 26 May 2014 (UTC)>

I really just started this thread to cheer Theo up because this page has so many postings about problems that he must get tired sometimes. —Anne Delong (talk) 01:56, 26 May 2014 (UTC)

@Anne Delong: Thanks, I definitely appreciate the sentiment. :) 1.0, here we come -- albeit slowly. Then again, I checked a week or so ago and it looked like over 4,000 edits had been made with the new script, certainly something to smile about. We're getting there! Theopolisme (talk) 04:35, 26 May 2014 (UTC)