User talk:Pi zero/essays/vision/sisters

Feedback from Peteforsyth

Are you talking about the kind of "wizard" in use at Commons, that for instance facilitate the nomination of a collection of images for deletion? Or are there any other examples that illustrate the kind of thing you're talking about? Glad to read about this, and I'd encourage you to think about moving this essay to Meta, where it might get a more diverse audience. -Pete (talk) 17:35, 21 November 2015 (UTC)

@Peteforsyth: You're right, I s'pose, I might put this stuff on meta... though I count myself lucky to have finally scraped up extra time to write it down at all, with the time sink of the actual tool development.

I don't know much about what sort of tools are in use at Commons. Here are some examples of things I expect the tools I'm developing should be able to do.

• We've got (at least) four bits of automation now on en.wn that I'd expect could be converted.

• Buttons for changing the status of an article. We've only got one of these now: when an article is under development it has a {{develop}} template at the top with a button on it to submit the article for review; we've been wishing for years we could make it a bit smarter, but it's now powered by a bit of code in common.js and anything we do to our common.js should reduce its clutter rather than increase it. I mean to convert that button to use the dialog tools, maybe smarten it up, and create a bunch of other state-change buttons, perhaps some of them dependent on user privs (things only a reviewer can do, or things only an admin can do).
• We have a WN:Make lead device for setting up leads on our main page; if that were dialog-tools-driven we have some upgrades in mind we'd like to try.
• We have a review gadget, that we'd also really like to convert to use dialog so we can make changes/upgrades/whatnot.
• We also use HotCat a lot. There's something to be said for using the standard tool that everyone else is using, but I do note that it should be possible to implement a similar device via dialog (maybe; there are probably one or two refinements that would require some upgrading of the dialog tools, something to think very deeply about).

• There are a bunch of semi-automated assistants I hope to cook up. Such as,

• An interactive assistant for creating an article. We have a good tutorial on writing an article, but it's just got a "creation form" for creating the article, after which you'd have to switch back and forth between the tutorial and the edit page. I once tried to write an "article wizard" similar to Wikipedia's, but that's not really interactive, it just asks a bunch of multiple-choice questions. I'd like to be able to explain about a part of the writing process and have the user enter stuff into boxes, then move forward and perhaps the software could check the inputs to give validation/advice/feedback and process it somewhat, and explain some more and have some more input boxes, and so on. Could be very cool, and optimistically might significantly streamline en.wn recruitment (although my pessimistic side can easily imagine ways for it to cause new kinds of problems).
• Tools for aiding a wide variety of tasks during review (the current gadget only assists reporting on a review once completed). We're already using a couple of tools on toollabs for copyright-checking, but frankly I'd really like something whose behavior could be customized/upgraded and I also really hate being at the mercy of stuff at toollabs, which I've found quite unreliable over the long term.
• We've got article-curation tasks that really cry out for semi-automated assistance. Like, something in the same general class as HotCat but more sophisticated, that manages all the wikilinks in an article, converting hard links to en.wp (or any other sister) into calls to {{w}}, and processing calls to {{w}} according to whether they have a local target; if there is a local target, is it a redirect to a category that the article doesn't already belong to; and finally whether the user wants to add the article to that category, make it a hard local link without adding the category, or leave it as a {{w}} for now to be reconsidered later.
• Opening nominations, closing nominations, and archiving nominations are all complicated; I've seen a whole bunch of different kinds of procedures for each of these things, with different pages using different patterns, and some of those procedures get rather elaborate as well as simply hard to remember if one doesn't do them all the time.

--Pi zero (talk) 21:50, 21 November 2015 (UTC)

Pi zero (t · c · b): Yikes, I missed this excellent reply for 4 months (I thought I had email notifications on for Wikinews, but apparently not!) The new cross-wiki notification feature pays off. I'll delve in and give you a more thought-out response shortly, but just wanted to let you know I finally saw this in the meantime. -Pete (talk) 23:22, 11 March 2016 (UTC)

I am trying to think about using tools to lower barriers to editor engagement. I am part of a small team doing a 2-day Wikinews wizard creation project at Wikinews:Editorslab. Our tool has a different scope than what is proposed above but still, I hope it adds to the conversation about what kinds of tools are desirable. Blue Rasberry (talk) 19:55, 8 April 2016 (UTC)

Comment from Shashaanktulsyan

@Pi zero: Hey thanks for letting me know about this. Glad that you found me (I don't know how you did). I see what you are working at. Actually I would like to take a moment and link to the idea I have in mind, it is only related to wikinews. It is centered around these points

• Keeping wikinews up-to date with latest content using automation
• Filtering out tabloid journalism, paid news, false news etc.
• Keeping a track of authenticity of different news sources and giving them a numerical score.

https://en.wikipedia.org/wiki/User:Shashaanktulsyan/DataDrivenNews—The preceding unsigned comment was added by Shashaanktulsyan (talk • contribs)

I hope to comment properly on this when I've some time to do so (just atm there are three articles waiting for review on the queue). Here's a teaser: Wikinews won't be the place for you to pursue those ideas, but you may benefit, wherever you may pursue them, from some insights I've gained over the years into the nature and challenges of news sites as well as the philosophy of wikis. --Pi zero (talk) 12:21, 23 November 2016 (UTC)

Comment from Jeff G.

@Pi zero: that's all well and good. Let me write to you about the way I did editing decades ago, with WordPerfect 6.0 for DOS ca. 1995 and later versions for Windows. Its main editing area was WYSIWYG, but it had an option to open up another area, maybe 1/3 the size, to reveal the "codes" underneath. If we could do that today with a visual editor and wikicode, I would welcome it and I think new editors would have much more control over their output, and less frustration.   — Jeff G. ツ 19:30, 2 April 2017 (UTC)

@Jeff G.: Viewing the markup and resulting layout simultaneously would be great. Any viable solution that direction would, I think, have to bypass the Foundation entirely, to prevent the Foundation from poisoning the effort with its agenda. I've gradually concluded that in the long run I'm going to have to deal with the editing problem within dialog; the first thing is to get dialog working at all, of course. --Pi zero (talk) 19:49, 2 April 2017 (UTC)

Some feedback

Successful development of such tools must be intensively managed by people with intimate knowledge of the tasks, and only the wiki community can have that intimate knowledge.

In principle I agree with this section, however, I believe the use of "managed by people with intimate knowledge of the tasks" seems wrong. I totally agree the best tools can only be developed for the users of such tools if those same users are involved in the development process but I do not see them as project managers. In fact, I find software consumers often are not good managers nor developers but are more akin to customers. Having worked in the software industry, I believe it is the duty of a good project manager to regularly communicate with the project's users to obtain and ultimately ensure requirements can and are met. Users often do not know what they want or how to go about addressing their needs in a project so developing and maintaining (as they usually change often) project requirements for a software project is key to its success. A good project manager also needs to know how to limit the scope of a project too—meaning after a set of requirements are obtained limiting the changes to such requirements. This is necessary because otherwise the project can and often does spiral out of control and never reaches completion. It it is better to succeed in something small and return to make a better tool later.

Perhaps the above statement could be changed to something like:

Successful development of such tools must involve the people with intimate knowledge of the tasks, and only the wiki community can have that intimate knowledge.

I did not read and research to sufficient depth to feel I have an adequate understanding of what sort of tools a typical WN user might be interested in—that said I have been around MediaWiki and the WikiMedia projects and for quite some time so I understand the needs of such users in general fairly well.

I hope this is helpful. Cheers, 50.53.1.33 (talk) 16:02, 15 August 2017 (UTC)

Some thoughts

When dealing with any type of computation program there are tradeoffs, some are good and some are bad. The good is forks can create great new features. The bad is the user experience of non-wiki contributors. If the WPF really wants an open place to provide knowledge then they should allow the open community the latitude to allow some type-specific development room.

Instead of requesting changes directly to the WPF, think about creating a collision of sister projects requiring the same abilities. From there, suggest a pilot program for developing the features. Then make the WPF feel like they have power by requiring all the sister projects and the WPF have a vote on inclusion of a feature in the next version.

Another feature that is a little far out there, maybe years from now we can have live time story input. —The preceding unsigned comment was added by AZOperator (talk • contribs) 17:37, 27 December 2017 (UTC)

Not sure why you want to say Wikipedia Foundation?
•–• 19:03, 27 December 2017 (UTC)