Wikinews:Water cooler/proposals/archives/2015/January

This is an archive of past discussions from Wikinews:Water cooler/proposals/archives/2015. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current page.

Tools for experienced writers

What sort of tools would help to make article writing easier for experienced Wikinews writers? It appears folks sometimes start to write an article, then don't have time to finish it within deadline; what sort of tools might cut down on how often this happens, by reducing the time and effort required? Feel free to speculate wildly; I'm trying to fashion building blocks from which to build interactive tools, and I'm looking for ideas about what sort of tools the building blocks should be able to build. --Pi zero (talk) 16:38, 8 November 2014 (UTC)[reply]

At first glance, this one might sound silly, but it would be fantastic to have a push-button option to help find file photos on Commons for certain topics. (e.g. If I'm writing an article about President Obama, with just a click or two, Commons would offer me up 2-3 file photos from which to choose.) --Bddpaux (talk) 16:41, 10 November 2014 (UTC)[reply]

That's an interesting thought. It's occasionally occurred to me that our category pages have images on them that could be drawn on for generic usage on related articles, which ought in principle to be something a semi-authomated tool could orchestrate. --Pi zero (talk) 17:19, 10 November 2014 (UTC)[reply]

I agree with the push button idea. So to clarify, there would be a button beside an article I'm writing to retrieve photos? Anyways, I think a semi-automated tools should orchestrate images from category pages, which I think is a good idea. Sam.gov (talk) 22:52, 10 November 2014 (UTC)[reply]

I'm not sure tooling helps fix the "don't have time to finish it within deadline" issue. The only way to fix that is to have more people helping out. Perhaps a template tag to say "look, I started this, can someone help finish it and/or adapt it into a new article". —Tom Morris (talk) 18:37, 28 November 2014 (UTC)[reply]

@Tom Morris: we do have a similar templete like this one:

This article is being developed. You can contribute or discuss its development.
If it is ready to be checked, you can Submit for review.
This is not a way to ask others to expand or finish the article!
If original reporting is contained in this article, you must provide notes.

As you can see, it says, "You are welcome to contribute to it", but it also says "This is not a method to request someone else expand, or complete, an article for you!". I think it says this because it doesn't automatically send out a request to individual editors to help out. So the problem is that other editors may not respond it it for whatever reason, even though it is inviting. I think a better method is to invite individual editors to help out by going to their talk page and say, "Hey do want to help out writing this news article?" or something like that. That is one method I can think of right now. —Sam.gov (talk) 00:47, 8 December 2014 (UTC)[reply]

I'd be more interested in tools to help me curate the archive. BRS ^{(Talk) (Contribs)} 14:02, 5 January 2015 (UTC)[reply]

That too, of course. Thoughts welcome.

(Aside: About my development process. It's basically the antithesis of the way the Foundation develops software. Their administrators and developers are insulated from the hands-on expertise that can provide insights into the deep workings of wikis, and their organization evidently favors top-down software design: choose something you think there should be software to do, and assign a team to create software to do that. Rather than rant at length on why this doesn't produce good results, I'll remark that wikis inherently grow from the bottom up, and by Conway's law you don't expect a top-down organization to produce software well-suited for a bottom-up system. My design process is bottom-up. Driven by personal experience with wikis, I try to envision what sorts of higher-level tasks we'd like to do, and what sorts of primitive tools could make those sorts of higher-level tasks possible; then, I carefully craft and polish primitives, with an eye constantly toward how they can be used for higher-level stuff (both stuff I was hoping to do, and stuff that occurs to me from considering the primitives). The shaping of the primitives is constantly guided by efforts to use them for higher-level tasks, an organic mix of developing idioms for using them and recognizing how the primitives themselves could be tweaked to make it all work better.)

Although I'm still actively pursuing some improvements to the primitives, I'm also now starting to struggle seriously with idioms for using the primitives. And to develop these idioms, I want to have in mind as broad a range of high-level tasks as possible. From my personal experience, I can more-or-less envision

Tools for routine tasks, such as submitting an article for review, or starting/closing/archiving a nomination for deletion/promotion/accreditation/whatever.
Tools to help reviewers review articles.
An "article wizard" for helping newcomers to write articles; while I have somewhat limited personal experience with being a newcomer, I've worked with newcomers quite a lot, which might help me judge what's needed.
Tools for curating the archives; I've done a bunch of curating myself.

However, for a variety of reasons I don't do a great deal of writing myself, and even if I did, I doubt the generality of whatever experience I'd glean from it, as there isn't just one kind of article, nor one kind of writer. Which is why I'm certainly interested in thoughts on any high-level tools, but had chosen to ask about tools for experienced writers. --Pi zero (talk) 15:44, 5 January 2015 (UTC)[reply]

I'll put in a section, below, with ideas for that. I think the reason actionable feedback is a little slow is less to do with your lack of experience writing and more to do with the fact there's a limit on ways to assist writing. One minor but helpful function did come to me this instant, though, which is something that suggests wikilinks not already in the article. A couple of configurations come to mind; perhaps users could customise it to add a list of common things not to link, or perhaps rather than suggesting anything it could find it would be asked very trivially (from within the edit window) by the user if something could be linked. The latter would be useful for example to check film names in French campaigning film director René Vautier dies, not all of which existed on Wikipedia. BRS ^{(Talk) (Contribs)} 22:21, 5 January 2015 (UTC)[reply]

Archive curating tools

As above, I'd appreciate tools to help curate the archives. Here are some ideas;

Something to make filling out {{missing image}} painless
Something to help convert an article to {{w}}
Something to rapidly convert links en masse from {{w|links like this}} to [[links like this]] where appropriate
Can {{w}} already tell you how many articles are linked to a given target? If not I'd like that.
This lil gem of a problem to create
Something to make creating redirects to categories simple. Give it a list of things to redirect to a target (usually a cat) and let it create them all, protect them all, add the protected redirect cat to them all, and sight them all. I want this most of all.

Most likely more to follow. BRS ^{(Talk) (Contribs)} 22:33, 5 January 2015 (UTC)[reply]

I envision an assistant that would

convert hard links to sister projects so they use {{w}}.
check {{w}} links to see which ones link locally.

if a {{w}} links locally to a category the article belongs to, convert it to a hard local link.
if it links locally to a category the article doesn't belong to, ask the user what to do — add the cat and convert to a hard local link, or don't add the cat but convert to a hard link anyway, or leave it for now.

I'm not 100% sure how to accomplish some of that, but I have it in mind as an objective.

It could, indeed, also be useful to know for a non-local {{w}} how many other articles also have {{w}} links on that same target. Right now, the way I find that out is

follow the link to Wikipedia.
edit the url by replacing "wikipedia.org" with "wikinews.org".
click "What links here".

This gives a list of all articles that link to that target on en.wn. Even though the target doesn't exist, every {{w}} link to that target shows up in Special:WhatLinksHere. --Pi zero (talk) 23:32, 5 January 2015 (UTC)[reply]

Messy, but workable as a bodge. BRS ^{(Talk) (Contribs)} 22:35, 8 January 2015 (UTC)[reply]

More ideas;

Something to help me deprecate transclusion of cats via infoboxes (I recently did {{BBC}} which was a relatively small job).
Something to make renaming cats easy by automatically changing all the pages in the originally-named cat to use the new name. This would also let us preserve such history as cats contain; I've always found deleting them to move them a little icky. BRS ^{(Talk) (Contribs)} 22:35, 8 January 2015 (UTC)[reply]

Every country in the world

Happened to notice, whilst curating in the archives: though I'd heard we've published at least one story about every nation on Earth, and this jibed with my experience in the category hierarchy, I've discovered one we seem to have missed: São Tomé and Príncipe. This did prompt me to get around to a minor cat task I'd been mulling over for a while, on an article from 2005 about a UN vote; but that's not really the same. --Pi zero (talk) 16:38, 28 November 2014 (UTC)[reply]

I had a poke at GNews but didn't readily find any non-stale, non-{{single source}} candidates. Local news seems to largely be unavailable in English. BRS ^{(Talk) (Contribs)} 21:11, 12 January 2015 (UTC)[reply]

Portal deprecation

The above section seems to indicate the old portal system is finally, officially, finished. (Not that it can't in theory be revived years down the line.) Might I suggest that, since people landing on them are looking for the latest news, we should redirect them to their category counterparts? BRS ^{(Talk) (Contribs)} 18:54, 24 December 2014 (UTC)[reply]

Two or three of them do that now. When redirecting a portal to its associated category, add to the category's {{topic cat}} call the line |portal=no, so it won't link back to the portal. -Pi zero (talk) 21:16, 24 December 2014 (UTC)[reply]

If portals are truly deprecated perhaps {{topic cat}} itself should be edited to stop portal being shown as default, with portal=yes being the exception rather than the rule. BRS ^{(Talk) (Contribs)} 23:50, 1 January 2015 (UTC)[reply]

There is something to be said for defaulting to yes, so that existing {{topic cat}}s can be changed one at a time as portals are redirected. We could create a hidden category to track the ones that link to portals, giving us a list of which ones still need doing.

Newly set up {{topic cat}}s effectively default to no because that's now part of the template provided for setting them up (which one imagines becoming part of an assistant at some point). --Pi zero (talk) 17:27, 10 January 2015 (UTC)[reply]

Yes please to a hidden cat... And to a tool to easily close down portals. BRS ^{(Talk) (Contribs)} 21:08, 12 January 2015 (UTC)[reply]

I'll arrange for the hidden cat, maybe later tonight. The tool seems feasible to me, but less immediate as it's predicated on several improvements to the dialog primitives (it's just that they're all improvements I know, in principle, how to do; nothing scary). --Pi zero (talk) 21:43, 12 January 2015 (UTC)[reply]

Template:Infobox

I'm planning to move Template:Infobox to another name, without leaving a redirect, in preparation for replacing it with a template of the same name and greater functionality. I'm announcing it here so folks can object, as well as so they know about the new template.

The existing template is meant to be subst'd, with a parameter for the category, to create a new infobox template that you then customize by tinkering with the template internals. Presumably it can serve that purpose from a different name. There is a redirect to Template:Infobox from Template:Issues, but that's just because in 2009, the old Template:Issues was retired by redirecting it there; I foresee no problem with letting the redirect go to the new template I want to put under the name Template:Infobox.

The replacement template would allow customization without subst'ing and without hacking template internals. When the client says {{infobox|Carpathia}}, the template looks for a page called Template:Infobox/lookup/Carpathia, which it expects to be a wikitable of customizing parameters. (There'll be a template for setting up the right sort of wikitable, as well.) If you want to be able to just write {{Carpathia}}, you set up that template with content {{infobox|Carpathia}}. This allows uniform infoboxes controlled from a master template, and easy customization of individual infoboxes, with the bonus that it's trivially easy to conjure up an infobox for an arbitrary category. --Pi zero (talk) 11:03, 11 January 2015 (UTC)[reply]

I've (already!) shifted the old template over to {{Infobox pattern}}. Maybe there's a better name for it, but as I assemble the prospective replacement template, having the old one in place under the name {{infobox}} was confusing. --Pi zero (talk) 15:17, 11 January 2015 (UTC)[reply]

The new template is in place. What it doesn't do is add the article to any categories, and that's deliberate; it does mean we can't instantly covert all the infoboxen to use this under the hood.

Although I'd rather not overburden it with bells and whistles, if there's any other customization we really need, well, we can add options to the template. --Pi zero (talk) 23:28, 11 January 2015 (UTC)[reply]

Default search

Currently, we're cofigured so that by default, Special:Search looks at mainspace and portal space. This is currently inappropriate, I suggest, because our portals are not maintained and are not nearly as useful, to anyone, as our categories. Most of our topical redirects from mainspace go to categories rather than portals (though there are still a few that go to portals merely because they haven't been updated).

I suggest we change the default for search to mainspace and category space instead of mainspace and portal space. --Pi zero (talk) 03:26, 4 December 2014 (UTC)[reply]

I certainly Support the change. Even were we to have maintained portals, categories makes more sense as a search target unless we were pushing out a couple of dozen articles daily. --Brian McNeil / ^talk 12:16, 4 December 2014 (UTC)[reply]
Hmm, how times change (I always thought portals were stupid, and people used to love them so much for no apparent reason) </reminiscing>. Bawolff ☺☻ 02:59, 7 December 2014 (UTC)[reply]
Support After so much argument, in the end it was apathy towards them that deprecated portals by default. BRS ^{(Talk) (Contribs)} 00:04, 11 December 2014 (UTC)[reply]
Yes, please. Gryllida 09:22, 11 December 2014 (UTC)[reply]
Support --Ochilov (talk) 16:38, 13 December 2014 (UTC)[reply]
Support I too believe portals should not be considered useful anymore. Wikinews has a small community and so it was almost impossible to mantain all these portals. Diego Grez (talk) 00:48, 18 December 2014 (UTC)[reply]
Support - I fondly recall the good old days of active portals. Alas there time has passed. Brian |(Talk) 12:29, 22 December 2014 (UTC)[reply]

I've requested implementation. I think. I must admit I'm struggling with even the basics of the new interface. BRS ^{(Talk) (Contribs)} 01:53, 25 January 2015 (UTC)[reply]

"I know engineers — they love to change things." (Leonard McCoy) --Pi zero (talk) 02:18, 25 January 2015 (UTC)[reply]

Although I can't tell from the phabricator page, which looks like so much gobbledygook to me, I see from Special:Search that the default search has, in fact, been changed. --Pi zero (talk) 23:31, 28 January 2015 (UTC)[reply]