Wikinews:Water cooler/technical

Shortcut:
WN:WCT

Taking dialog to the next level[edit]

I expected to learn more about what's needed for dialog as I went along. It may be time to up the stakes in a major way, and I'm describing the challenge here so others can brainstorm as well (because you never know when an idea might come out of left field.User:AcagastyaUser:BawolffUser:Gryllida).

My original concept for dialog was to have

input fields; however many of them, arranged in whatever way, as desired.
buttons, however many and arranged however designed; each of which sends selected data from the input fields to some action.
actions, that receive data sent to them through buttons; especially, an action to view a page with given data, where the data sent can be folded into the viewed page as if it were a template parameter, and can also override the default initial value of an input field.
authorization features were built in from the start, rather strict ones, because of the obvious potential for abuse of a semi-automated system capable of making changes to the wiki — editing a page, sighting or unsighting ("deprecating") a revision, or even changing the protection on a page, deleting or undeleting a page, renaming a page. Basically, the pages that make real changes to the wiki have to be fully protected, and therefore effectively have to have been authorized by an admin.

What's additionally needed is the ability to do a dry run of both simple and complex interactions. That is,

an admin should be able to try out a dialog to make sure it does what it's supposed to, before deploying it (fully protecting the pages).
a non-admin should be able to set up a dialog and make sure it does what it's supposed to, before asking an admin to deploy it (and the admin would then of course also want to examine it carefully, including running through it, before deploying it).

There's also a related facility I've had in mind for years, in which a non-admin makes a proposed edit to a fully protected page (on Wikinews, this would likely be an article in the archives), then when they submit the edit, since they can't actually alter the fully protected page, the assistant mediating the interaction sets up an edit-protected request on the talk page, with a button an admin can use to get the exact proposed edit, which they can then consider, perhaps modify, and either decline or deploy. All of which could probably be done now (if one could slog through the design of it all), but also seems like it might somehow be related to the aforementioned dry-run facility. --Pi zero (talk) 20:10, 1 January 2021 (UTC)

Good description. Is this completed now, and it is time to start making all sorts of wizards? Just checking as I did not fully understand the intent of this message. Gryllida (talk) 20:16, 1 January 2021 (UTC)

@Gryllida: What's happened here is, as I tried to imagine what would really be involved with writing all sorts of wizards, it seemed to me that there's this whole additional level of functionality needed. And I'm not immediately sure how to make it happen, so this is a moment to consider where to go from here. It's not impossible this could require a major redesign of the whole facility; or, maybe there's an elegant way to arrange it all that doesn't involve any significant change to the existing facilities. --Pi zero (talk) 20:22, 1 January 2021 (UTC)

Ah. Thank you for the clarification. Looking at the 'additional functionality' part of your original message, it seems to me that I would wish to test a dialog by writing a copy of it in my personal sandbox, and by applying it to test pages rather than the actual pages. Is this not possible now? How could this be improved? Gryllida (talk) 20:26, 1 January 2021 (UTC)

Some food for thought, there.

On a related-but-different note, when debugging an action (not a dialog page, but the general-purpose engine behind the dialog), there's a provision in the code that while actions ordinarily have to be named {{SITENAME}}:Dialog/... (the action that does most everything atm is WN:Dialog/do), admins can also use actions in userspace. So admins can test new actions, and new versions of actions, in userspace without deploying them for general use.

Re debugging dialogs in userspace, what you describe might be workable for experienced admins, with two limitations:

applying the dialog to test pages may be awkward (e.g., we can't actually publish something), and
switching from a test scenario to deployment is apt to be complicated, therefore difficult and error-prone. Once you've got it working right in the test environment, you really want to be able to just throw a switch, with no opportunity to botch something in the process.

Afaics, the complexity makes this approach unsuited for ordinary users, and for the sort of small-and-inexpensive edits that characterize wikis. --Pi zero (talk) 02:17, 2 January 2021 (UTC)

Would suggest to just write wizards which don't publish things, that would help with plenty article authoring and reviewing tasks already. Gryllida (talk) 03:47, 2 January 2021 (UTC)

Regarding editing "Wikinews:Dialog/...", perhaps it can be done by non-admins if a separate user right for this exists? Gryllida (talk) 03:49, 2 January 2021 (UTC)

We may be getting tangled in a terminology difficulty. There are three different sets of pages involved, here.

action pages. An action page is the underlying engine that processes dialog parameters and performs some sort of general operation. The only action used ordinarily, atm, is WN:Dialog/do. (I had originally imagined there would be one for viewing a dialog page, one for editing a page, and so on, but later found there is a significant performance penalty for switching from one action to another, so things will go faster if everything is done by a single action. Thus, action do has a parameter called "verb" whose value is view or edit; additional verbs might be supported in future.)
dialog pages. A dialog page is used to interface with the user. This is where input fields and buttons occur.
subject pages (not really sure what to call these, but, sure, at least for now, let's call them "subject pages"). A subject page is affected by the dialog, according to what the user specifies through dialog pages, as acted upon by actions.

Dialog pages are expected to occur in constellations called "assistants"; each assistant exists to perform a particular function. I have an infrastructure set up for organizing things that way, similar to the way books are organized on en.wb (see Category:Interactive assistants). A better, crisper definition of dialog page is, perhaps, a page that belongs to an assistant; because potential subject pages may have buttons on them for invoking assistants. The one current example of this is the 'submit' button provided by the {{develop}} template; this button appears on articles that have not yet been submitted for review, and if the button is clicked it invokes a (simple) assistant that submits the article. (There are even more blurred situations, that I'm working on, but no actual examples yet.)

My concern here is that, if we cut corners on the design now in order to get something out the door sooner (so to speak), in the long run we'll get bogged down, unable to move forward to what we really want because of the existing stuff that we're stuck with. This is a familiar conundrum, of course. There's one sort of problem if you go too far in holding out for the really general solution (xkcd), another if you go too far in opting for quick-and-dirty solutions. Unfortunately, the whole commercial software industry today is drastically skewed toward the quick-and-dirty side. Throughout the development of dialog, I have been trying to take advantage of the non-commercial nature of the Wikinews environment by applying strategies that cannot be used in industry. One of those strategies is rejecting the quick-and-dirty solution in favor of the long-term win.

Specifically, here, I'm concerned that if we don't figure out now what's needed to support these sorts of 'dry runs', the development of new assistants will always be painfully difficult and we'll never be able to retrofit the dry-run support later. --Pi zero (talk) 14:32, 2 January 2021 (UTC)

(I've been wondering if there's a suitable link for the quick-and-dirty extreme, to go with that xkcd link for the general solution; closest I've thought of is the classic essay Worse is Better.) --Pi zero (talk) 15:44, 2 January 2021 (UTC)

I've not seen dry runs on any other platform, or in any programming language. Have you? Gryllida (talk) 21:35, 4 January 2021 (UTC)

No, I haven't. Afaik, we'd be breaking new ground. We'd need to work out just how much state one would keep, how far one would stretch things out and, if one did so, what one would do about any missing details. --Pi zero (talk) 21:40, 4 January 2021 (UTC)

As I recall, in web development it is common to have one "dev" version of the site where tools are tested (including things being published, as nobody and nothing will notice them there) and then these tools can be transferred to the "main/production" site without any modifications.

This could be, for example, at dev.wiki.wn-reporters.org, if Acagastya and you and I are content with such use of the server resources. Such a site would be the clone of Wikinews in many regards, including mediawiki version and versions of installed extensions, with the main exception that not all article archives would be imported (there is loads), whereas templates and code pages would be imported (perhaps all).

Would such site being available satisfy the need for dry runs in every possible light of it? Gryllida (talk) 00:03, 5 January 2021 (UTC)

┌─────────────────────────────┘
Huh. They do go about things that way, don't they. In this case, though, it would seem to be of help only for expert developers. Which brings out an important point: I have set out to make dialog a wiki thing. My perception of the nature of wikis is that (in the general case) a user reading a wiki page who sees something not-right can just fix it. The point of the "dry run" feature is that the ordinary user who sees something wrong with a dialog proposes an edit to a page that's part of an assistant, and before they submit their proposal they want to be sure of what it would actually do, like the "preview" feature of the edit panel — and, when an admin considers the proposal the admin also wants to be sure of what it would actually do before deploying it.

[A point I started to drive at here, but seem to have half lost track of, is that trying things out on a development version of the wiki is not lightweight.]

Your point about a development version flags out the sheer size of what I was somewhat-indirectly getting at: there's a limit to how much one can actually track in a "dry run". In the full-blown 100% case, you'd have a complete mock-up of the entire wiki; which is obviously not possible, because dialog is client-side, using javascript storage on the reader's browser. --Pi zero (talk) 02:28, 5 January 2021 (UTC)

dev.wiki.wn-reporters.org perhaps could accept logins from Wikinews. User rights would be different on the two sites. Is there a drawback to such approach, other than the effort in running and maintaining the site? Gryllida (talk) 02:40, 5 January 2021 (UTC)

I'm not sure how to articulate this, but I'll give it a try.

It's not a lightweight solution; changes to anything would be quite challenging to accomplish. It still seems to be a solution limited to experts, because only an expert would be able to work through it. Not a matter of what the software forbids, but what one is able to figure out without extensive training.
My sense of what's possible here says that making this stuff truly feasible requires a meta-assistant: a dialog-based tool for developing dialog-based tools (because assistants are for expert tasks, and developing them is an expert task). And my intuition is suggesting it'd be awkward to use a meta-assistant without being able to do some sort of walkthrough/dry-run.

--Pi zero (talk) 05:42, 6 January 2021 (UTC)

Why would a change be limited to experts?
- Because only an expert can host a wiki on their PC? But if we give any development inclined volunteers admin access to the testwiki, this wouldn't be an issue, because they'd use our testwiki and wouldn't need to learn to run their own.
- Because the JavaScript files are difficult to edit? That's possibly unavoidable.
- Some other reason? I don't know of it, please explain.
Meta assistant could be useful indeed. It seems unrelated to dry runs. It also seems like a next phase of the project; before going there, I would suggest to first practice making a few useful wizards (article creation, article review, etc) and documenting how they're made, how they work. I think completing this first would help with two goals:
- writing the meta-wizard correctly, and
- writing sufficient amount of documentation and examples for wizards to be possible to create via code, which I hope will increase the number of people who know how to do this.

Regards, Gryllida (talk) 10:05, 6 January 2021 (UTC)

A couple of thoughts.

You suggest making some wizards as part of preparing to make a meta-assistant. In fact, I have had pretty much this in mind, from the start: everything I've done, for years now, has been done with deep thought to what can be learned from it about more advanced things that would come later. All that deep thought has been part of why things have moved forward so slowly. However, several assistants have been written by now providing insights into the process:

An important insight, for me, from these assistants has been that they were hard to cope with despite being much smaller than some of the things we've discussed. I have therefore been planning out, very carefully, various devices to help with coordinating larger assistants, including the notion of a meta-assistant.

We are somewhat elite, in being at all clueful about software development; and it is therefore, I suggest, easy for us to underestimate how difficult it is to do nontrivial things. This is a delicate balance. The Wikimedia Foundation seems to me to have, unfortunately, gone one step too far in this regard, mistakenly classifying wiki markup itself as too "difficult" for ordinary people — failing to understand the dynamics by which wiki markup is communicated to contributors, and in defiance of the reality that wiki markup is the reason the wikimedia sisterhood exists at all. My assessment, based on my observations of how things have played out over the past half century or so, is that wiki markup is just far enough: one wants to embrace wiki markup and at the same time not go further than that. In particular, asking people to go to another site, experiment with changes to an assistant, then come back here and propose those changes, is not lightweight-enough.

--Pi zero (talk) 22:21, 6 January 2021 (UTC)

It's not fully my call to make, but if I wanted more people to be involved and getting the hang of it, I'd do three things:

document how these existing wizards have been made,
document what are the next 2-3 wizards that are wanted;
and if this involves more than just editing wiki markup, such as something requiring elevated user rights or risk of breaking things, then I'd proceed to host the testwiki immediately.

Regards, Gryllida (talk) 05:30, 7 January 2021 (UTC)

┌────────────────┘
Thoughts.

I've increasingly realized documentation is part of the problem. A few years ago I had occasion to mention Module:Wikilisp to one of the wikimedia devs. Another dev asked me whether I'd also created a javascript version of the interpreter. I replied that no I hadn't, but refrained from saying no with the level of scorn and borderline insult I felt at the question: my reflex was that anyone who has tried to provide identically-behaving implementations of a complex software system in two different languages, or even seen it tried, would never willingly try such a thing again. It is, by nature, a logistical nightmare waiting to happen. My thought was no, I'm not a complete noob. I didn't say it with such strong passion partly because it's my understanding that the wikimedia devs have committed this blunder and failed to recognize it, so that if I put strong feeling into it, that would have turned into a whole separate effort to get the point across to someone likely unreceptive to the message and apt to take offense. My point in mentioning all that is that, lately, I've realized part of the reason documenting software is such a mess is that the documentation and the code are supposed to be synchronized in a way that is the same sort of logistical nightmare as maintaining, say, Wikilisp in two implementation languages simultaneously. Anyway, wiki markup is supposed to be so simple it's self-documenting, isn't it. What more can I, and should I, say about how those assistants are made? (No, that's not a rhetorical question, if you have an answer to suggest.)

I'm reminded of literate programming. Not that I've [n]ever been all that attracted to it as a concept; if it were a silver-bullet sort of solution for software, you'd think it'd be universally adopted by now — but I am reminded of it.

The trouble with deferring the dry-run thing is that pushing forward with assistants is going to be a massive effort with-or-without it, but pushing ahead without it really means it will never be done: whatever it is one would do differently in the design of dialog to accommodate the dry-run facility, I suspect that most of the effort to move forward without that facility would be incompatible with what one would do with the facility, and the effort to switch to such a facility later would be prohibitively vast.

--Pi zero (talk) 14:37, 14 January 2021 (UTC)

strategy[edit]

I'm currently mulling over the idea of adding a alternative verb to dialog action do, parallel to verb edit, that, instead of requiring authentication, calculating the effect of a form, and modifying the target page by applying that effect, does only the second of those things — not requiring authentication, and saving the calculated effect of the form into a dialog field. One then has to decide between accomplishing this by copying the relevant code from verb edit (which would then require changes in one copy to be made in the other to keep them in sync) or by abstracting the relevant code into a subfunction so that if it were ever modified it would affect both verbs automatically (guaranteeing they'd stay in sync, but the complicating abstraction to achieve that would be another thing to possibly get wrong and would make the code harder to read and understand). --Pi zero (talk) 16:02, 1 February 2021 (UTC)

Technical maintenance planed‬[edit]

A maintenance operation will be performed tomorrow morning UTC time (Wednesday 17th at 07:00 AM UTC).

It will impact all wikis and is supposed to last up to one minute.

During this time, new translations may fail, and Notifications may not be delivered. For more details about the operation and on all impacted services, please check on Phabricator.

A banner will be displayed 30 minutes before the operation.

Thank you, SGrabarczuk (WMF) 17:45, 16 February 2021 (UTC)

Wikinews:Water cooler/technical

Contents

Taking dialog to the next level[edit]

strategy[edit]

Technical maintenance planed‬[edit]

Navigation menu

Search