@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