In T269310#6698758, @Esanders wrote:

@matmarex We need a way to suppress the anon edit notice as we already have one built in to the widget.

@Esanders: good spot. I've been thinking this work will happen in T270454. Please comment there whether you think adjustments need to be made to the task description.

In T269310#6699739, @matmarex wrote:

In T269310#6697554, @ppelberg wrote:

• I think we should only enable this on pages that "opt-in" somehow, at least at the beginning. (…)

• @matmarex Can you say more here? In suggesting we make the new discussion tool opt-in on pages using preloads to start, what scenario(s) are you wanting us to avoid?
  
  ...the examples you shared above don't immediately strike me as concerning considering the tool seems to have no issue with publishing a topic without the Topic field containing any content.
  
  Asked another way: is there something about how the New Discussion Tool currently behaves that you think is more likely to cause disruption and/or confusion than the existing workflow on pages like wp:Files for discussion where the posting instructions ask people NOT to fill content in the Subject field?

In this particular scenario, you'd get an annoying warning about the topic field being empty (and if you fill in the field, then you might annoy other editors when they see a heading in the wrong place).

There are also workflows where you're not supposed to add a signature, or where the signature is included somewhere in the preloaded text, and our tool would always insert (another) one. (Example: undeletion requests at pt.wp: https://pt.wikipedia.org/wiki/Wikipédia:Pedidos/Restauro click "Inserir um novo pedido")

It doesn't completely "break", but I think it would be a negative experience, both for the user of the tool, and for others who might need to fix the page to follow the existing conventions.

The kinds of issues you had in mind are now clear to me; thank you for explaining this.

In light of the above, I too agree pages that use preloads in their section=new form should have to opt-in to using the New Discussion Tool to start.

@Esanders had some ideas for how this could be implemented. I've documented this work and the ideas Ed shared in T270797.

I've also updated this task's description to reflect the above. See the revised "Step 1." within the ===Behavior section.

• Given the above, I think we should support the visual mode as well. Somebody has to explicitly enable the new tool, so they can probably also take care to make the preloaded text work well in the visual mode.

• @matmarex: what would it look like for someone to adapt the preloaded content work well in the tool's visual mode? And what would "working well" look like/mean for the person using it?

• [before you start: Verify that this is a discussion workflow (that is, you want users to provide a topic title, and to sign their comment at the end), rather than something different (e.g. a form for adding yourself to the list of members of a wikiproject). Otherwise, you probably don't want to use the new tool.]
• Avoid {{subst:…}} syntax
• Put instructions into the editintro, instead of wikitext comments (<!-- … -->)
• If you have a signature in the preloaded text, ensure it's at the end so that the tool doesn't insert another one

I see. I've added this point as a question in T270797 as it's not yet clear to me what might be a good way to make page "maintainers" aware of why and how they can enable the New Discussion Tool for preloads and how to adapt said preloads so they "cooperate" with the New Discussion Tool's visual mode.

• @matmarex: are there paramters within the Edit and submit section the New Discussion Tool will not be able to support? I ask this in anticipation for editors wondering what – if anything – constrains their ability to potentially customize the way the New Discussion Tool handles preloads.

We probably don't want to support the 'preview' parameter, since we have an "always-on" live preview in wikitext mode, and don't want to have a preview in visual mode.

I've mentioned the 'nosummary' parameter earlier, and we could support it, but on second though, I don't think we want to. I'd expect it to be used for mostly non-discussion workflows (also… I've never seen it used in practice).

As mentioned, we can support 'summary'. All other parameters remaining don't apply to the new section mode.

Understood. A resulting question...

• @matmarex, in T269310#6699739 you alluded to pages [i] where it would be unexpected/undesirable for people using the section=new workflow to populate the form's Subject/headline field. This leads me to wonder: Why did you suggest that we not support the nosummary parameter [ii] considering it seems, as @Tacsipacsi shows in T269310#6703855, there are cases where disabling that field by way of the nosummary parameter seems like it would be useful?

i. https://en.wikipedia.org/wiki/Wikipedia:Files_for_discussion
ii. https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Edit_and_submit
iii. https://w.wiki/rrB

Change 650006 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] ApiVisualEditor: Support 'preload' etc. for new sections in visual mode

https://gerrit.wikimedia.org/r/650006

Change 645211 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] ArticleTargetLoader: Allow customizing 'editintro' parameter

https://gerrit.wikimedia.org/r/645211

In T269310#6711173, @ppelberg wrote:

• @matmarex, in T269310#6699739 you alluded to pages [i] where it would be unexpected/undesirable for people using the section=new workflow to populate the form's Subject/headline field. This leads me to wonder: Why did you suggest that we not support the nosummary parameter [ii] considering it seems, as @Tacsipacsi shows in T269310#6703855, there are cases where disabling that field by way of the nosummary parameter seems like it would be useful?

I think these pages probably have somewhat complicated workflows with templates and stuff, and it would probably be more practical to just keep using the old interface for them rather than try to adapt our new interface.

Also, adding the ability to hide that field would make validation (T269285) more difficult to implement.

i. https://en.wikipedia.org/wiki/Wikipedia:Files_for_discussion
ii. https://www.mediawiki.org/wiki/Manual:Parameters_to_index.php#Edit_and_submit
iii. https://w.wiki/rrB

In T269310#6740915, @matmarex wrote:

I think these pages probably have somewhat complicated workflows with templates and stuff, and it would probably be more practical to just keep using the old interface for them rather than try to adapt our new interface.

Understood.

Also, adding the ability to hide that field would make validation (T269285) more difficult to implement.

Noted.

This will require T269033 first, as custom preloaded text often comes with a custom edit notice containing instructions.

For example:

• via @Tacsipacsi: https://hu.wikipedia.org/wiki/Wikipédia:Bürokraták_üzenőfala/Átnevezés → "Új kérelem benyújtása" → new section form
  
• via @Whatamidoing-WMF: https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/Edit_warring → "Click here to create a new report" → new section form
  

Below are notes from today's team conversation about this task's dependence on T269033 per T269310#6749816...

Next steps

• We are going to pause work on support for prelaods and edit notices until after the New Dicussion Tool is available as a Beta Feature (T269471) and before we consider offering it as an opt-out preference (T271964).

Agreements

• We came to agree that it would be risky to incorporate the contents of the edit notice component into the New Discussion Tool's Description field, even temporarily.
  • Reason: we assume, in most cases, "page maintainers" populate edit notices with content that is notably different from the content they populate the new section form's Description / Body field with. As such, we think people would be confused were they to open the New Discussion Tool and see the Description field filled with two kinds of guidelines: 1) guidelines for how and what to talk about on a given talk page and 2) guidelines for how a new topic's description ought to be formatted.

Considerations

• Related to the "Agreement" above, we thought we could save "page maintainers" effort by offering support for preloads and edit notices within the New Discussion Tool at the same time.
  • Thinking: if preloads and edit notices are introduced at the same time, we can save "page maintainers" the effort of having to reconstruct the page's existing preloads in ways that will work with the New Discussion Tool's source and visual modes (T270797), having some time pass and then having to come back and do something similar for the to-be-designed edit notice component (T269033).

We should also consider buttons generated by the <inputbox> extension, as mentioned here: https://www.mediawiki.org/wiki/Topic:W0n4nevz8ty8it1r

In T269310#6784358, @matmarex wrote:

We should also consider buttons generated by the <inputbox> extension, as mentioned here: https://www.mediawiki.org/wiki/Topic:W0n4nevz8ty8it1r

Here's a task for this: T285117

The Growth team would really benefit from this. Part of our Positive Reinforcement project includes prompting Mentors to send encouraging talk page messages to "praiseworthy" mentees, and current designs require this functionality. T322449: Personalized praise talk page message

@ppelberg - is there any chance this task will be revived?

In T269310#8619892, @KStoller-WMF wrote:

The Growth team would really benefit from this. Part of our Positive Reinforcement project includes prompting Mentors to send encouraging talk page messages to "praiseworthy" mentees, and current designs require this functionality. T322449: Personalized praise talk page message

@ppelberg - is there any chance this task will be revived?

hey @KStoller-WMF: as of this moment, the Editing Team does not have plans to work on this ticket, as it falls outside of the scope of what we have planned for the remainder of this first phase of the Talk Pages Project.

Of course, learning more about the timing of the Growth Team's need for this could, of course, alter the above. Thank you for adding this ticket as a topic for us to talk about the next time we meet 1:1.

Hi @ppelberg, chiming in as a Growth engineer responsible for the Personalized praise project :). I understand this falls outside of the scope defined. However, this patch has already a patch prepared by @matmarex (so, as far as I can see, it should consist only of reviewing it). I can ask fellow Growth engineers about that patch and see if perhaps someone's comfortable merging it, if the feature is OK from your product perspective?

Per what the Editing and Growth Teams discussed offline (Slack): the Editing Team is supportive of offering volunteers the ability to explicitly opt-in to using the New Topic Tool for preloads. In doing so, the Growth Team will be able to introduce a feature that depends on this functionality: T322449.

Doing the above would amount to/require:

2. @matmarex and @Urbanecm_WMF: reach an agreement on what the URL parameter that 650007 introduces will be called
3. @Urbanecm_WMF : once "1." is done, update Extension:DiscussionTools/How_it_works#New_topic_tool with the following information:
   • The technical limitations dtpreload/dtcompatible is currently bound by. Read: what functionality it will NOT currently support.
   • The fact that this functionality is currently experimental
   • What steps people would need to take in order to use this new functionality

In T269310#8670255, @ppelberg wrote:

Per what the Editing and Growth Teams discussed offline (Slack): the Editing Team is supportive of offering volunteers the ability to explicitly opt-in to using the New Topic Tool for preloads. In doing so, the Growth Team will be able to introduce a feature that depends on this functionality: T322449.

Thanks!

Doing the above would amount to/require:

2. @matmarex and @Urbanecm_WMF: reach an agreement on what the URL parameter that 650007 introduces will be called

I responded to @matmarex's note on Gerrit. As I mentioned there, I feel dtpreload is easier to understand (but I'm not against the suggested dtcompatible). Looking forward to receiving a reply there.

You can go ahead with dtpreload for now. If Bartosz can convince us to change it on his return it shouldn't be too hard to change.

Change 650007 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Support '&preload=...' etc. in new topic tool when '&dtpreload=1' is set

https://gerrit.wikimedia.org/r/650007

Change 896161 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Clicking "reply" was broken

https://gerrit.wikimedia.org/r/896161

Change 896161 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Clicking "reply" was broken

https://gerrit.wikimedia.org/r/896161

I think this is done now?

Are Growth QAing?

@Esanders Yes, thanks for the reminder! I've moved to to Growth QA.

In T269310#8702490, @matmarex wrote:

I think this is done now?

As far as interaction with GrowthExperiments is concerned, yes. I assume you want to eventually support preloads without an opt-in, though? Should that be a different task?

Test wiki created on Patch demo by Martin Urbanec (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/2abf1605fe/w

Test wiki created on Patch demo by Martin Urbanec (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/6411b44c82/w

In T269310#8670255, @ppelberg wrote:

[...]

2. @Urbanecm_WMF : once "1." is done, update Extension:DiscussionTools/How_it_works#New_topic_tool with the following information:
   • The technical limitations dtpreload/dtcompatible is currently bound by. Read: what functionality it will NOT currently support.
   • The fact that this functionality is currently experimental
   • What steps people would need to take in order to use this new functionality

This is now done: https://www.mediawiki.org/wiki/Help:DiscussionTools#Experimental:_Preloading_message_content. Please let me know if you want me to make any other changes!

In T269310#6699739, @matmarex wrote:

• Put instructions into the editintro, instead of wikitext comments (<!-- … -->)

Unfortunately custom edit intros (&editintro= URL parameter) don’t seem to work, even if I add &dtpreload=1. Could you please add support for it?

In T269310#8728299, @Tacsipacsi wrote:

In T269310#6699739, @matmarex wrote:

• Put instructions into the editintro, instead of wikitext comments (<!-- … -->)

Unfortunately custom edit intros (&editintro= URL parameter) don’t seem to work, even if I add &dtpreload=1. Could you please add support for it?

Hi @Tacsipacsi! Thanks for the message. Unfortunately, as of today, support for preloading in DiscussionTools is considered experimental (see MW.org docs), added primarily to help Growth's Personalized praise project (T322449: Personalized praise talk page message in particular). While it is technically possible to reuse the feature elsewhere, it is still considered an experimental feature that likely doesn't include all features of native MediaWiki preloading. If Editing-team decides to add full preloading support to DiscussionTools, I believe editintro would be something to include. Thanks for your understanding.

@Tacsipacsi I had a look since it was supposed to work. And it works for me, but it's unreliable, because:

• editintro is lost when restoring from autosave
• following a preload link will immediately autosave the preloaded text
• restoring autosave takes priority over preload links

As a result, editintro will sometimes not be shown when it should be, particularly when you're testing a form that makes use of preloads.

All three of these points should probably be improved (and this is probably relevant to Growth team's work too), but I think it mostly affects people creating/testing forms rather than their real users.

edit: Filed T333188 for these issues

In T269310#8730150, @matmarex wrote:

All three of these points should probably be improved (and this is probably relevant to Growth team's work too)

I don't think we have any plan to use editintro. The others are relevant but an edge case (the mentor would have to follow a recomendation, abandon the new message dialog, then get a recommendation for the same user again and follow that).

Test wiki on Patch demo by Martin Urbanec (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/6411b44c82/w/

Test wiki on Patch demo by Martin Urbanec (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/2abf1605fe/w/