It will be very easy, but before working on. I need views of MediaWiki team on this. ping @Legoktm @CCicalese_WMF that we will add Special:NewSection in MediaWiki, or not? :)

I think I have an example use case that I'd need right now: I'm creating a global userpage on meta.wikimedia.org and would like to add a globally working "Add new message to my talk page" link. This does not seem to work without having a local page that can be accessed using an internal wikilink to execute the action. Any magic words are parsed on Meta before being displayed on the other wikis, external links are unflexible, but wikilinks are being interpreted locally.

This seems like the perfect use for a RedirectSpecialPage - I can take a stab at it if no one else wants to, but I've never tried to write a special page before.

Change 518399 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Create Special:NewSection special page

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

I've made a start, and the patch is ready for review

@Krinkle noted on the patch that:

This adds a new feature to MW, but it is unclear who would be the steward/owner of this feature. The task has Editing-team tagged, but please do not merge this until there is a steward and that steward's product owner agrees with this direction and the added responsibility for maintaining this.

Is anyone willing to be responsible for this?

@Krinkle Can you please point to a policy that all core features require someone at WMF to take "ownership" of it for maintenance even though there are plenty of parts in core and WMF-deployed extensions that are completely unmaintained by WMF? I am unaware of such a policy. This seems like a very odd double-standard where WMF employees can do whatever arbitrary thing they want, but volunteer developers have barrier after barrier erected to block their contributions and make them feel as unwelcome as possible.

For wide-sweeping changes we have the RFC process, but something like a basic special page which performs a redirect falls far under the requirements for needing such a process.

If a volunteer wants to contribute something minor like this, you should let them instead of turning them away. If it requires maintenance later, a bug can be opened and either someone at WMF or another volunteer could pick that up and fix it. Or it might go unfixed for years, like plenty of bugs that already exist in mediawiki. Either way, that's not a valid reason to block an otherwise perfectly-valid contribution.

If the code here is good, and there are no solid reasons for rejecting such a change on technical merits, then it should be merged. The attitude that someone at WMF is required to maintain a niche feature only serves to make mediawiki development an increasingly toxic place for volunteer developers by making it exceedingly difficult to get their contributions recognized. I kindly ask that you reconsider things from that point of view.

The statement I made is not intended to be uniquely aimed at volunteers. While product approval or intent to maintain is often assumed on code by WMF staff and contractors – if in doubt, I would raise the same questions.

Unmaintained. It is indeed unfortunate that we have vast quantities of code without a steward. However, I'm afraid your description of "unmaintained software" is not realistic. Some features are "without active development" – annoying bugs might remain unfixed and no new feature investments are made. But, such software still cannot exist in the modern world without maintenance. These unstewarded features still require routine maintenance. And as such, one could say, all WMF-deployed features are looked after, maintained and secured. This costs time and resources, often in an uncoordinated, stressful, or train-blocking fashion. Because software can cause cascading failures. Look at the Gerrit history for any such "inactive feature" and you'll find no shortage of patches from WMF engineers interrupting their regular work to keep up these features. It would be irresponsible to intentionally add to this burden without seeking approval of such financial spendings and delaying other work.

Reference to relevant documentation: Code Stewardship, Best practice, Code stewardship review, Code-Stewardship-Reviews.

Product. I also mentioned that this feature may overlap with developments planned by the Contributors department, specifically the Editing and Growth teams. Perhaps you would be okay with this feature being removed a year from now if it turns out incompatible with other plans. But we also have to worry about other users and workflows that may come to depend on the new special page before then. Perhaps they'll quickly come around and say it's fine for it to exist and they don't have any concerns. I just want them to have a chance to look it over before we move on.

In T207577#5344311, @Krinkle wrote:

The statement I made is not intended to be uniquely aimed at volunteers. While product approval or intent to maintain is often assumed on code by WMF staff and contractors – if in doubt, I would raise the same questions.

Do you have any examples?

Unmaintained. It is indeed unfortunate that we have vast quantities of code without a steward. However, I'm afraid your description of "unmaintained software" is not realistic. Some features are "without active development" – annoying bugs might remain unfixed and no new feature investments are made. But, such software still cannot exist in the modern world without maintenance. These unstewarded features still require routine maintenance. And as such, one could say, all WMF-deployed features are looked after, maintained and secured. This costs time and resources, often in an uncoordinated, stressful, or train-blocking fashion. Because software can cause cascading failures. Look at the Gerrit history for any such "inactive feature" and you'll find no shortage of patches from WMF engineers interrupting their regular work to keep up these features. It would be irresponsible to intentionally add to this burden without seeking approval of such financial spendings and delaying other work.

So basically... you object to changes not introduced by the WMF? Because this is a tiny change. If you'll apply that reasoning to this, you can apply it to anything.

I also mentioned that this feature may overlap with developments planned by the Contributors department, specifically the Editing and Growth teams. Perhaps you would be okay with this feature being removed a year from now if it turns out incompatible with other plans. But we also have to worry about other users and workflows that may come to depend on the new special page before then.

From a designer point of view, I'm going to have to say that this is incredibly unlikely. This new 'feature' is consistent with other existing redirect special pages, and would suit the same workflows - if anything conflicted with this, it would conflict with the others too, and would likely require a total overhaul of extant user workflows, something we try to avoid doing unless there is a very good reason.

A more coherent interface that uses any of this should simply be shelling to the same special pages etc that the users would previously be interacting with directly, and would be unaffected by what is already implemented and what isn't, in this regard.

I just want them to have a chance to look it over before we move on.

You want to block this on a team not currently working on this to comment about the potential impact to something they might eventually work on? That's interesting, because I've almost never had anyone even tell me when something impacts something I am currently working on, even when they clearly knew I was working on it and even commented as such on their own tickets. (And how long did you want to give them? I don't disagree that any input they do have would potentially be useful, but it's been a month.)

All in all, nice double standards.

Change 518399 merged by jenkins-bot:
[mediawiki/core@master] Create Special:NewSection special page

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

Change 528940 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Fix Special:NewSection showNoRedirectPage form handling

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

Testing on the beta cluster works for navigating to Special:NewSection/User:DannyS712, but the form fails:

[XUs@oawQBHcAAEa9-FAAAAAR] /wiki/Special:NewSection BadMethodCallException from line 65 of /srv/mediawiki/php-master/includes/specials/SpecialNewSection.php: Call to a member function getFullUrlForRedirect() on a non-object (string)

Backtrace:

#0 /srv/mediawiki/php-master/includes/htmlform/HTMLForm.php(689): SpecialNewSection->onFormSubmit(array, OOUIHTMLForm)
#1 /srv/mediawiki/php-master/includes/htmlform/HTMLForm.php(581): HTMLForm->trySubmit()
#2 /srv/mediawiki/php-master/includes/htmlform/HTMLForm.php(596): HTMLForm->tryAuthorizedSubmit()
#3 /srv/mediawiki/php-master/includes/specials/SpecialNewSection.php(59): HTMLForm->show()
#4 /srv/mediawiki/php-master/includes/specials/SpecialNewSection.php(46): SpecialNewSection->showForm()
#5 /srv/mediawiki/php-master/includes/specialpage/RedirectSpecialPage.php(52): SpecialNewSection->showNoRedirectPage()
#6 /srv/mediawiki/php-master/includes/specialpage/SpecialPage.php(571): RedirectSpecialPage->execute(NULL)
#7 /srv/mediawiki/php-master/includes/specialpage/SpecialPageFactory.php(582): SpecialPage->run(NULL)
#8 /srv/mediawiki/php-master/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#9 /srv/mediawiki/php-master/includes/MediaWiki.php(892): MediaWiki->performRequest()
#10 /srv/mediawiki/php-master/includes/MediaWiki.php(523): MediaWiki->main()
#11 /srv/mediawiki/php-master/index.php(42): MediaWiki->run()
#12 /srv/mediawiki/w/index.php(3): include(string)
#13 {main}

In T207577#5401032, @mobrovac wrote:

The branch has already been cut. so it's not relevant for this week's train.

That's why I added the next train (there isn't one next week, so 2 weeks from now)

Change 528940 merged by jenkins-bot:
[mediawiki/core@master] Fix Special:NewSection showNoRedirectPage form handling

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

Change 529048 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Fix Special:NewSection showNoRedirectPage form handling (2)

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

And found another bug: trying to submit an empty page title:

[XUvh6awQBHcAAEsghWcAAAAL] /wiki/Special:NewSection/ BadMethodCallException from line 66 of /srv/mediawiki/php-master/includes/specials/SpecialNewSection.php: Call to a member function getFullUrlForRedirect() on a non-object (null)

Backtrace:

#0 /srv/mediawiki/php-master/includes/htmlform/HTMLForm.php(689): SpecialNewSection->onFormSubmit(array, OOUIHTMLForm)
#1 /srv/mediawiki/php-master/includes/htmlform/HTMLForm.php(581): HTMLForm->trySubmit()
#2 /srv/mediawiki/php-master/includes/htmlform/HTMLForm.php(596): HTMLForm->tryAuthorizedSubmit()
#3 /srv/mediawiki/php-master/includes/specials/SpecialNewSection.php(59): HTMLForm->show()
#4 /srv/mediawiki/php-master/includes/specials/SpecialNewSection.php(46): SpecialNewSection->showForm()
#5 /srv/mediawiki/php-master/includes/specialpage/RedirectSpecialPage.php(52): SpecialNewSection->showNoRedirectPage()
#6 /srv/mediawiki/php-master/includes/specialpage/SpecialPage.php(571): RedirectSpecialPage->execute(string)
#7 /srv/mediawiki/php-master/includes/specialpage/SpecialPageFactory.php(582): SpecialPage->run(string)
#8 /srv/mediawiki/php-master/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#9 /srv/mediawiki/php-master/includes/MediaWiki.php(892): MediaWiki->performRequest()
#10 /srv/mediawiki/php-master/includes/MediaWiki.php(523): MediaWiki->main()
#11 /srv/mediawiki/php-master/index.php(42): MediaWiki->run()
#12 /srv/mediawiki/w/index.php(3): include(string)
#13 {main}

Change 529048 merged by jenkins-bot:
[mediawiki/core@master] Fix Special:NewSection showNoRedirectPage form handling (2)

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

The exception is not only for empty titles, also for invalid ones:
https://en.wikipedia.beta.wmflabs.org/wiki/Special:NewSection?page=This_is_<_invalid -> Go

[XU9XS6wQBHcAAB@x7PMAAABV] /wiki/Special:NewSection BadMethodCallException from line 67 of /srv/mediawiki/php-master/includes/specials/SpecialNewSection.php: Call to a member function getFullUrlForRedirect() on a non-object (null)
Backtrace:
#0 /srv/mediawiki/php-master/includes/htmlform/HTMLForm.php(689): SpecialNewSection->onFormSubmit(array, OOUIHTMLForm)
#1 /srv/mediawiki/php-master/includes/htmlform/HTMLForm.php(581): HTMLForm->trySubmit()
#2 /srv/mediawiki/php-master/includes/htmlform/HTMLForm.php(596): HTMLForm->tryAuthorizedSubmit()
#3 /srv/mediawiki/php-master/includes/specials/SpecialNewSection.php(60): HTMLForm->show()
#4 /srv/mediawiki/php-master/includes/specials/SpecialNewSection.php(46): SpecialNewSection->showForm()
#5 /srv/mediawiki/php-master/includes/specialpage/RedirectSpecialPage.php(52): SpecialNewSection->showNoRedirectPage()
#6 /srv/mediawiki/php-master/includes/specialpage/SpecialPage.php(571): RedirectSpecialPage->execute(NULL)
#7 /srv/mediawiki/php-master/includes/specialpage/SpecialPageFactory.php(582): SpecialPage->run(NULL)
#8 /srv/mediawiki/php-master/includes/MediaWiki.php(296): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#9 /srv/mediawiki/php-master/includes/MediaWiki.php(892): MediaWiki->performRequest()
#10 /srv/mediawiki/php-master/includes/MediaWiki.php(523): MediaWiki->main()
#11 /srv/mediawiki/php-master/index.php(42): MediaWiki->run()
#12 /srv/mediawiki/w/index.php(3): include(string)
#13 {main}

Change 529588 had a related patch set uploaded (by DannyS712; owner: DannyS712):
[mediawiki/core@master] Fix Special:NewSection showNoRedirectPage form handling (3)

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

The non-object (null) was due to using newFromText, which returns null on errors. I've switched it to using newFromTextThrow to catch errors.

Change 529588 merged by jenkins-bot:
[mediawiki/core@master] Fix Special:NewSection showNoRedirectPage form handling (3)

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