@MusikAnimal In the planning meeting we wanted to create some more tasks for the Intake form; hopefully this is on track. Lots of the details not yet defined; please change as you see fit.

I think ideally we'd have our survey sandbox working (T362809) before tackling this, but that's a ways off. Most of us don't have admin rights on Meta so you won't be able to easily delete test proposals.

That got me to thinking… so far there's not a whole lot of Meta-specific things we're doing. For T362809 I was thinking of offering an XML dump of all the templates and the homepage needed for FOTW. This could be included in the repo for wishlist-intake. This way, we can do all of our testing completely on our local. Then we don't even need the server mentioned at https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/#quickstart (though it's fine to still develop this way if you want).

How does that sound? If we get a "local" wishlist intake working, then there's no harm at all with saving test proposals as you (the dev) can delete them. That allows this task to proceed without a sandbox and/or Meta admins cleaning up our tests.

Saving as JSON would be cool, and would make it easier to edit proposals using the intake form. However, we need a template to render the content, so we'd be doing a JSON-to-wikitext conversion more often than not (every page parse). I was thinking that the bot that parses proposals (T361067) would eventually be responsible for data storage, which we'll later use in the dashboard. So JSON wouldn't benefit us in that sense.

The bigger issue (maybe?) is that on Meta, only admins can change the content model of a page. At least for the mainspace, .json pages are by default wikitext.

If it means anything, it's not hard to split a template into key/value pairs when we know what the keys are. This is how the bot and CWS Manager currently work. So I'm not personally concerned with wikitext as the content model, especially if that's the way it's meant to be displayed.

The bigger issue (maybe?) is that on Meta, only admins can change the content model of a page. At least for the mainspace, .json pages are by default wikitext.

I forgot about this! Basically makes this proposal moot, I think. I guess storing JSON as wikitext isn't impossible, it would mean that we wouldn't get any validation etc. which is less good.

I was thinking that the bot that parses proposals (T361067) would eventually be responsible for data storage, which we'll later use in the dashboard. So JSON wouldn't benefit us in that sense.

I'm not sure I follow: won't the bot be reading out from wikitext into a database? So having the data ready to go in a structured form would mean the bot doesn't have to duplicate the wikitext parsing that we'll do for the intake form. Or would that be moved out into a common place somewhere?

For T362809 I was thinking of offering an XML dump of all the templates and the homepage needed for FOTW. This could be included in the repo for wishlist-intake.

That sounds like a terrific idea!

Comments from @Samwilson. Break into 3 tasks/subtasks

• build form first
• add rich text second
• support uploads third

Lastly - saving form data into the page // how we read data into form.

samwilson opened https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/13

Add initial form-contents saving

My hope was to have T362809 largely done before we worked on saving and other parts of the survey, as that adds the missing pieces of the puzzle that are apart from the intake form.

I see an MR has already been created, and by all means don't let me stop it from moving forward, but I'm a little confused as to why we're working on saving right now when the form isn't done yet? We're not even sure where to save the page to, much less be able to grab all the data together and pass it to a template which doesn't exist yet (T362809 / T363223).

I think I picked it up because it was in the ready column and rated as high priority; sorry if it's too soon! But I do think it can be a good idea to build a thing very simply from end to end, and then go back and fill in the details. So, to try to get the form be able to open and save a page as soon as we can, so that it can be tested and played with as we build more functionality and so we react better to feedback.

No worries! That's fine :) I guess it's just the "saving" part we're focusing on here for now. I.e. the acceptance criteria of this task includes fields we haven't built yet, so I had it in my mind those would get worked on first.

musikanimal merged https://gitlab.wikimedia.org/repos/commtech/wishlist-intake/-/merge_requests/13

Add initial form-contents saving

The next part of this that I would like to look at is how to read and write the list of phab tasks. I'm imagining that we'll want to have a comma separated list of links, as it has been in the past, e.g.

| phab = [[phab:Tnn|Tnn]], {{phab|Tnn}}, {{phabricator|Tnn}}

We don't really need to support all these forms, because the form is in control of writing the data, but it seems that we might as well because a simple way to do it is to read out all unique T[0-9]+ strings, and write them back normalized to the simple interwiki prefix form [[phab:Tnn]].

We talked briefly at the Hackathon about maybe having the form display the actual titles and perhaps status from Phabricator, live, for easier data entry (akin to how Patchdemo does it with patch numbers). That'd be cool, but it might be odd if they don't then also get the same title display in the page after saving — and I think that might be out of scope.

So I think to start with we do the above normalization and no fancy Phab lookups. Sound okay?

Although actually, perhaps that and the other remaining fields listed in the description above should have their own tasks? Adding VE is certainly a separate chunk of work, and project is already T362275. I'll update the description.

In T362761#9785660, @Samwilson wrote:

So I think to start with we do the above normalization and no fancy Phab lookups. Sound okay?

Sounds good to me! Fancy stuff can come later if we have time :)