Wikinews:Water cooler/technical/archives/2012/March


Toolserver??

[If I've missed this somewhere.....sorry] When I check on some of my watched users "User Submissions" etc., I get a weird error message. ...something at toolserver.org.......our something-something has expired? Huh? Bddpaux (talk) 01:33, 15 February 2012 (UTC)[reply]

https://toolserver.org/~soxred93/pages/index.php?name=Nakon&lang=en&wiki=wikinews&namespace=0&redirects=noredirects I think our mojo has expired or something. Bddpaux (talk) 03:28, 28 February 2012 (UTC)[reply]

Whoever's toolserver account soxred93 is, simply hasn't been logged into in over six months.
If I were looking for new pages/articles by user Nakon, I'd use this link. --Brian McNeil / talk 03:45, 2 March 2012 (UTC)[reply]

Template:Oceania/subdivisions

Template:Oceania/Subdivisions is shown on Portal:Oceania, but it appears that template is deleted. Does the deleted version of the template contain something useful, or does it need to be rebuilt from scratch? --Sigma 7 (talk) 22:09, 28 February 2012 (UTC)[reply]

Required: Userspacing gadget

Looking at use of Wikinews for education projects, such as the UoW ones, there is obviously a need to quickly and easily move articles to userspace. Deletion as stale/abandoned means that examples of not-up-to-scratch work are being lost, and the educational value from failing with them.

I would like to see a gadget developed to deal with this — possibly also being included as a button from within the {{abandoned}} and {{stale}} templates. The required functionality is, I believe, covered by the below:

  1. Retrieve the article's edit history, this is to be parsed for possible target userspace to put the article in.
  2. As-default, offer the most frequent contributor prior to the first addition of the review template. (Identified with edit summary: Please review this article. (moved using js via button)).
  3. Then, ignore edits by the same editor leading to a failed review (Identified with edit summary: Not ready when reviewed: article needs improvement(s). Add article flag. (Using easy peer review)) back to the next differing editor. With the remaining revisions, offer contributors in order of how many contributions.
  4. Lastly, offer option to open edit history in new Window/Tab next to a box to manually specify the user whose space the article should be moved to.
  5. When "Userspace article" is clicked, article is moved with a redirect left behind.
  6. Once article is in userspace:
    1. 'Deactivate' {{date}} templates (insert the tl| to avoid category inclusion)
    2. 'Deactivate' any infobox template (method as-per date template, but assume any template within the 1st 3-4 lines is an infobox).
    3. 'Deactivate' categories by prefixing the Category: with a colon (":").

Saving failed articles in this way will allow a great deal more to be learned from submissions which don't end up published. And, with a single automated edit, the most troublesome work of userspacing an article is automated. --Brian McNeil / talk 16:39, 12 January 2012 (UTC)[reply]

We'd likely want ability to manually specify a userspace by a parameter to the template, which when present would settle the question of whether to move to userspace and obviate the elaborate automatic search for a choice of destination. Conceivably, we might want to limit the move-to-userspace option to articles marked in some way (either the parameter, or otherwise).
When an article's problems include (non-blatant, hence non-speedy-able) copyvio, moving to user space on a permanent basis may be the wrong approach (though the article talk page may be less problematic).
Though {{tl}} disables thoroughly, it may also obscure what the template was supposed to look like; a parameter (perhaps nocat=1 ?) might be better if supported. --Pi zero (talk) 17:31, 12 January 2012 (UTC)[reply]
  •   UPDATE: I've taken the liberty of putting this, and several other wish-list items over on the MediaWiki wiki (see my userpage there, plus the Google Summer of Code 2012 pages. Input is not just welcome, it's needed.
Questions I'm asking are: Is the workflow as-is suitably clearly documented? Have I missed any points in the list of weaknesses? How do we expand each of the weaknesses to best-justify, and interest, some hacking? How do we lay out an improved workflow? Or, do we simply seek a toolkit that allows it to be build by people who aren't hip-deep in the intricacies of coding?
Tommorow night is the deadline for organisations applying, following on from that students will be signing up. That's why I've spent the last 5 hours knocking together what's there. --Brian McNeil / talk 06:47, 8 March 2012 (UTC)[reply]

Notification of review

This would likely be an added function of EZPR (terrifying thought). When a review is submitted, the gadget would automatically identify users who have done nontrivial work on the article, and would put a notice on each of their user talk pages.

  • This function should probably be optional, so a reviewer can choose not to do it.
  • We'd need to hammer out the automated criteria for who to inform. (To get fancy, should the reviewer be able to adjust the criteria, or even remove and add users to the list to be informed?)
  • The notice would go in a section titled "[[Name of article]]".
If there is already a section on the user talk page with that name, the notice should probably be put in that already-existing section.
  • Here's a likely form for the notice:
* This article, [to which you have contributed/which you created], has been [published/found not ready on review]. See: [[Name of article#anchor|review comments]], {{plainlinks|{{fullurl:Name of article|action=history}}|history of edits during review}}. <small>—review via easyPeerReview by ~~~~</small>
where the anchor sends the link directly to the particular review section for that review.

--Pi zero (talk) 18:00, 4 February 2012 (UTC)[reply]

These little extra messages should probably be manual customizations, or at least manually customizable. This also highlights that we don't want review notifications going to users whose contributions to the article were vandalism. —The preceding unsigned comment was added by Pi zero (talkcontribs)
Questions I'm asking are: Is the workflow as-is suitably clearly documented? Have I missed any points in the list of weaknesses? How do we expand each of the weaknesses to best-justify, and interest, some hacking? How do we lay out an improved workflow? Or, do we simply seek a toolkit that allows it to be build by people who aren't hip-deep in the intricacies of coding?
Tommorow night is the deadline for organisations applying, following on from that students will be signing up. That's why I've spent the last 5 hours knocking together what's there. --Brian McNeil / talk 06:50, 8 March 2012 (UTC)[reply]

LQT broke

Not sure where to file this one,...

On LQT comment pages, assuming you use vector, the History, Edit, Delete, Merge into another thread and Link to options are now appearing on individual lines instead of rolled-up as a dropdown. I assume this bug's been introduced via the 1.19 upgrade. --Brian McNeil / talk 03:48, 2 March 2012 (UTC)[reply]