Please add the following:

@Varnent I don't think we need to sacrifice redirects for "actions" and other not-legally-required redirects. I suspect this limitation was invented to reduce the amount of work in maintaining the redirect table, that's very understandable. But please note that virtually all redirect systems allow patterns to overlap, with a way to set simple priorities.

The original request was to redirect /wiki/ and /w/. Doing just that, would be much less damaging, given the 1000s of URL permutations now all resulting in a dead-end.

We can add the following two entries to the redirect table as a catch-all. The redirects have order 0 by default in WordPress (High priority), an order of 100 would set them to a low priority.

Adding these does not affect any of the existing redirects, including those that redirect within the new site.

For a majority of the pages - we want the end user to be sent to the main site - and the 404 page is fine as it conveys it’s changed. The reality is that a vast majority of the pages on Governance Wiki will not be staying there. There is no reason to maintain links to inactive pages replaced by the new site. Active policies are getting redirects.

In T200754#4466642, @Pcoombe wrote:

Please add the following:

/wiki/Matching_Gifts	https://donate.wikimedia.org/wiki/Matching_Gifts
/wiki/Matching_Gifts/*	https://donate.wikimedia.org/wiki/Matching_Gifts/*

{{Done}} :)

In T200754#4466794, @Varnent wrote:

For a majority of the pages - we want the end user to be sent to the main site - and the 404 page is fine as it conveys it’s changed. The reality is that a vast majority of the pages on Governance Wiki will not be staying there. There is no reason to maintain links to inactive pages replaced by the new site. Active policies are getting redirects.

If the goal is to route end-users that followed a plain link to an article by name on the wiki, to the new site's 404 page, then I suppose that's fine. I would prefer differently, but I can understand the intention and its value!

My main motivation here is namespaced titles, historical references, and wiki-specific interactions. No-one following such link would be interested in something other than the content uniquely identified by that URL. A handful of examples :

• https://wikimediafoundation.org/wiki/Special:AncientPages (and 123 others)
• https://wikimediafoundation.org/wiki/Resolution:MarkMonitor (and 437 other pages)
• https://wikimediafoundation.org/wiki/File:WMF_2009_2010_Form_990.pdf (and 1516 others)
• https://wikimediafoundation.org/w/index.php?title=Access_to_nonpublic_data_policy&oldid=47490 (and 74,784 other viewable revisions)
• https://wikimediafoundation.org/w/index.php?title=File:WMF_Ford_Multimedia_Participation_Project.pdf&page=20
• https://wikimediafoundation.org/w/api.php?action=query
• https://wikimediafoundation.org/w/index.php?title=Talk:Resolution:Personal_image_hiding_feature&diff=82788&oldid=82782 (and 74,784 other viewable edits)

These are taken from actual live references as referred to in citations in published articles (on Wikipedia, other websites, archived material, books), and referred to in past discussions on archived pages, mailing lists, etc.

Their use is large in scale and beyond our control to change on the Internet. These are wiki-specific and historical. Neither, I assume, is intended to be covered by the new site nor has value in being routed there. I'd suggest adding at least the following:

Some of those have already been added - I will look into adding 1-2 more.

With a couple of quick additions - I believe the examples you provided have been addressed. Thank you! :)

Sorry @Varnent, here's a few more to ensure that old fundraising links aren't broken.

In T200754#4469096, @Pcoombe wrote:

Sorry @Varnent, here's a few more to ensure that old fundraising links aren't broken.

/wiki/Thank_You	https://donate.wikimedia.org/wiki/Thank_You
/wiki/Thank_You/*	https://donate.wikimedia.org/wiki/Thank_You/*
/wiki/Ways_to_Give	https://donate.wikimedia.org/wiki/Ways_to_Give
/wiki/Ways_to_Give/*	https://donate.wikimedia.org/wiki/Ways_to_Give/*
/wiki/Problems_donating	https://donate.wikimedia.org/wiki/Problems_donating
/wiki/Problems_donating/*	https://donate.wikimedia.org/wiki/Problems_donating/*
/wiki/Cancel_or_change_recurring_payments	https://donate.wikimedia.org/wiki/Cancel_or_change_recurring_giving
/wiki/Cancel_or_change_recurring_payments/*	https://donate.wikimedia.org/wiki/Cancel_or_change_recurring_giving/*
/wiki/Tax_Deductibility	https://wikimediafoundation.org/support/tax-deductibility/
/wiki/Tax_Deductibility/*	https://wikimediafoundation.org/support/tax-deductibility/

{{done}} :)

In T200754#4466794, @Varnent wrote:

For a majority of the pages - we want the end user to be sent to the main site - and the 404 page is fine as it conveys it’s changed. The reality is that a vast majority of the pages on Governance Wiki will not be staying there. There is no reason to maintain links to inactive pages replaced by the new site. Active policies are getting redirects.

I'm not sure I understand this rationale. A 404 conveys that the content is no longer available; for conveying that it has simply moved to another location, there are other response codes.
Or are you saying that we plan to completely delete all other pages including documents like https://foundation.wikimedia.org/wiki/Notices_received_from_search_engines (original URL, now 404: https://wikimediafoundation.org/wiki/Notices_received_from_search_engines )?

In T200754#4471748, @Tbayer wrote:

In T200754#4466794, @Varnent wrote:

For a majority of the pages - we want the end user to be sent to the main site - and the 404 page is fine as it conveys it’s changed. The reality is that a vast majority of the pages on Governance Wiki will not be staying there. There is no reason to maintain links to inactive pages replaced by the new site. Active policies are getting redirects.

I'm not sure I understand this rationale. A 404 conveys that the content is no longer available; for conveying that it has simply moved to another location, there are other response codes.
Or are you saying that we plan to completely delete all other pages including documents like https://foundation.wikimedia.org/wiki/Notices_received_from_search_engines (original URL, now 404: https://wikimediafoundation.org/wiki/Notices_received_from_search_engines )?

There are over 12,000 pages on the old site right now. The number of pages being kept is far smaller than the number of pages being moved or deleted. There are of course examples of pages staying, and the active or highly trafficked ones are being redirected. This ticket is in part to help us with that effort.

@Varnent Can we get a couple more redirects to solve T203932?

In T200754#4467544, @Krinkle wrote:

[..] examples [..]

• https://wikimediafoundation.org/w/api.php?action=query

[..] I'd suggest [..]

/w/index.php*	https://foundation.wikimedia.org/w/index.php*
/w/api.php*	https://foundation.wikimedia.org/w/api.php*

In T200754#4467558, @Varnent wrote:

With a couple of quick additions - I believe the examples you provided have been addressed.

Thanks for adding those. There's one category of issues I still run into with various cross-wiki tools, which is the MediaWiki api.php end-point.

As example, its urls can look https://wikimediafoundation.org/w/api.php?action=query and https://wikimediafoundation.org/w/api.php?format=jsonfm&prop=pageviews&action=query&titles=Data%20retention%20policy.

Could you add the redirect for /w/api.php* as well?

In T200754#4571136, @Pcoombe wrote:

@Varnent Can we get a couple more redirects to solve T203932?

/wiki/Donate	https://donate.wikimedia.org
/wiki/Donate/*	https://donate.wikimedia.org

{{done}} :)

In T200754#4571449, @Krinkle wrote:

In T200754#4467544, @Krinkle wrote:

[..] examples [..]

• https://wikimediafoundation.org/w/api.php?action=query

[..] I'd suggest [..]

/w/index.php*	https://foundation.wikimedia.org/w/index.php*
/w/api.php*	https://foundation.wikimedia.org/w/api.php*

In T200754#4467558, @Varnent wrote:

With a couple of quick additions - I believe the examples you provided have been addressed.

Thanks for adding those. There's one category of issues I still run into with various cross-wiki tools, which is the MediaWiki api.php end-point.

As example, its urls can look https://wikimediafoundation.org/w/api.php?action=query and https://wikimediafoundation.org/w/api.php?format=jsonfm&prop=pageviews&action=query&titles=Data%20retention%20policy.

Could you add the redirect for /w/api.php* as well?

Yes - although I should note that we may remove it as we were previously advised against setting this one up as the actual home for what people are looking for when this is called is quickly being setup across multiple wikis (and sometimes actually is on the new site) - so a better outcome by far is updating the tool or perhaps leaving it broken for this wiki to encourage updates.

Please keep the redirect at least until T201890 is resolved and deployed. For most of these types of tools, they don't point to these urls themselves, the urls are automatically generated based on the replica registry, which identifies foundationwiki as wikimediafoundation.org/w/api.php. Once that one is updated, the rest should update automatically (maybe give it a week to propagate after that).

In T200754#4578110, @Krinkle wrote:

Please keep the redirect at least until T201890 is resolved and deployed. For most of these types of tools, they don't point to these urls themselves, the urls are automatically generated based on the replica registry, which identifies foundationwiki as wikimediafoundation.org/w/api.php. Once that one is updated, the rest should update automatically (maybe give it a week to propagate after that).

Sounds totally reasonable to me - I will post if I hear some super compelling reason not to - but at this moment I cannot imagine what that would be. :)

Please add a redirect from https://wikimediafoundation.org/wiki/Peering to https://foundation.wikimedia.org/wiki/Peering. This link is embedded in various technical documents and distributed databases that describe Internet traffic routing. Some of those are editable, but not all. It should redirect indefinitely.

In T200754#4613336, @Krinkle wrote:

Please add a redirect from https://wikimediafoundation.org/wiki/Peering to https://foundation.wikimedia.org/wiki/Peering. This link is embedded in various technical documents and distributed databases that describe Internet traffic routing. Some of those are editable, but not all. It should redirect indefinitely.

@Krinkle: That page does not look like it's within the scope of Governance wiki (unless it has some legal relevance I am missing). I could speed up its export to Meta-Wiki and setup the redirect to Meta-Wiki if that will work alright.

Or perhaps Wikitech would make more sense for that page?

@Varnent Good point regarding scope. If not foundationwiki, I think it would be actually be a better fit for Wikitech. The current contents are quite generic/information, but one of its use cases is/was for technical data such as https://wikitech.wikimedia.org/wiki/IP_and_AS_allocations. The operational information for Peering would probably go well alongside that.

Perfect! I will export the page to Wikitech in the next day or so and then setup the redirect. Thank you for pointing it out! :)

I don't think it fits well within Wikitech's scope -- this is actually our peering policy, and not documentation. As it's policy I'd say that it fits well within foundationwiki or our main website. I'd rather see it stay on the former so that we can keep the ability to edit it, but either could work.

I can update PeeringDB to point to the new location in any case.

In T200754#4614543, @faidon wrote:

I don't think it fits well within Wikitech's scope -- this is actually our peering policy, and not documentation. As it's policy I'd say that it fits well within foundationwiki or our main website. I'd rather see it stay on the former so that we can keep the ability to edit it, but either could work.

I can update PeeringDB to point to the new location in any case.

Interesting - I was not aware of this being a policy. I can work with Legal to add it to the policy list since it was not one previously identified by the On-wiki documentation working group (members).

There are no policies on the new main site (aside from the site's own privacy policy) - so can verify that would not be the best place. To be clear - the policies on Governance Wiki fall under the org's "Delegation of policy-making authority" policy - which means that any changes to it would require approval by either the Board or Executive Director. As a result, it will be a small group who could make the edits (once approved). It would also be good to make note of how and when the policy was adopted.

That work?

I'm honestly unsure if that makes sense -- it's a bit a too technical subject for the board/ED to be dealing with directly, and I doubt it'll be interesting to them. It is a technical policy ("we're open to peering") rather than
a legal one like ToS, but still commonly called a "policy", e.g. on PeeringDB (the rest of the text is a combination of documenting our ASN, and a donate pledge). What do you think?

Do we have a definition on what it means to be a "policy" that's in-scope for the "governance" wiki?

Also, I'm not familiar at all with that Board resolution, but it seems to suggest that the Executive Director, who may further delegate such authority to Wikimedia Foundation staff as they deem appropriate, so I'm not sure why it would need to be handled directly, even if it fits that definition. Am I missing something?

In T200754#4616443, @faidon wrote:

I'm honestly unsure if that makes sense -- it's a bit a too technical subject for the board/ED to be dealing with directly, and I doubt it'll be interesting to them. It is a technical policy ("we're open to peering") rather than
a legal one like ToS, but still commonly called a "policy", e.g. on PeeringDB (the rest of the text is a combination of documenting our ASN, and a donate pledge). What do you think?

Do you have some examples of other technical policies?

Do we have a definition on what it means to be a "policy" that's in-scope for the "governance" wiki?

We were unable to find any actual "policies" which were both official policies and fell outside the normal legal policy area. This is the first one I am aware of. So generally "policy" for this wiki has meant any official Foundation policies as approved by the Board or ED. To my knowledge, anything we call a "policy" in theory could be brought up in court as they are things we say in our bylaws govern how we operate, so to some extent they all involve Legal.

Also, I'm not familiar at all with that Board resolution, but it seems to suggest that the Executive Director, who may further delegate such authority to Wikimedia Foundation staff as they deem appropriate, so I'm not sure why it would need to be handled directly, even if it fits that definition. Am I missing something?

The power to approve new policies (according to our Bylaws) rests with the Board. Via this resolution they have delegated policy management to the Executive Director (ED) or people the ED delegates the authority to (I think currently just the General Counsel). We would want to check with Legal, but in theory the ED could delegate management of this policy to someone else, but my very non-legal understanding is that the only people who can update policies are the Board, ED, or someone the ED delegates.

Personally, if this is at all closer to documentation than an actual org approved policy - I would suggest that route as the related workload is much less. That said, if it needs to be a "policy" - we should probably make sure it follows official policy processes.

I think we may pushing things into a strange semantic corner hinging on the definition of the world Policy? Are we trying to say we can't use the word "Policy" publicly without it falling into this official scope with ED/Board direct oversight? There are a wide range of policies at various scopes that definitely don't rise to big-P "Policies" requiring legal review and/or direct ED/Board oversight (other than in the general sense of the chain of managerial command and responsibilities over things), yet definitely are little-p "policies", and some of which are for public reference as well.

Examples aside from our peering policy, all from wikitech (but arguably could be elsewhere), and all are public in the sense that they are intended to apply to at least some outside companies/parties we interact with:

• https://wikitech.wikimedia.org/wiki/Robot_policy
• https://wikitech.wikimedia.org/wiki/HTTPS#Current_Policies_and_Standards
• https://wikitech.wikimedia.org/wiki/Help:Toolforge/Right_to_fork_policy

https://www.mediawiki.org/wiki/Development_policy
https://www.mediawiki.org/wiki/+2

In T200754#4616974, @BBlack wrote:

I think we may pushing things into a strange semantic corner hinging on the definition of the world Policy? Are we trying to say we can't use the word "Policy" publicly without it falling into this official scope with ED/Board direct oversight? There are a wide range of policies at various scopes that definitely don't rise to big-P "Policies" requiring legal review and/or direct ED/Board oversight (other than in the general sense of the chain of managerial command and responsibilities over things), yet definitely are little-p "policies", and some of which are for public reference as well.

Examples aside from our peering policy, all from wikitech (but arguably could be elsewhere), and all are public in the sense that they are intended to apply to at least some outside companies/parties we interact with:

• https://wikitech.wikimedia.org/wiki/Robot_policy
• https://wikitech.wikimedia.org/wiki/HTTPS#Current_Policies_and_Standards
• https://wikitech.wikimedia.org/wiki/Help:Toolforge/Right_to_fork_policy

I think the difference is if it is housed on the official site for our legal policies or not. To my knowledge, this is the only policy of its nature on Governance Wiki. As you and Krenair pointed out, the others reside on channels which are not recognized as the official location of our primary org policies. I completely agree we do NOT want to complicate these things any more than they need to be (and it does not appear this requires complexity). Hence why I originally suggested moving it to Meta-Wiki or Wikitech. However, if it remains on Governance Wiki - I think it would be confusing for this to be the only "policy" which is not an official legally recognized policy (with its companion policies residing on Wikitech and Meta-Wiki). If it is a policy under that wiki's scope - it should be considered an official organization policy which we are intentionally trying to lock down and provide a space for people to comment. If it is not that kind of policy, it is probably not the best place for it. From what I can tell, this is probably not the best place for it. However, if I am wrong and this is an official organization policy (in the legal sense), than to my knowledge the above processes would apply (if for no other reason than it would be awkward to setup this one page with different edit permissions than the others on that wiki). Let me know which you prefer, I do not feel strongly either way and happy to help relocate it wherever or help set it up similar to the other policies on GovWiki. :)

Ignoring the policy vs. Policy bits and delegation of powers for a moment there, I think the problem distills to the following:

There is information that SRE (and others in Tech?) maintain for the purposes of communicating information to third-parties, that are not volunteers that want to work on our stuff, and perhaps not necessarily even technical people (e.g. network peering managers). MediaWiki.org is (supposedely) about MediaWiki and Wikitech is a combination of internal documentation for us and documentation for our technical staff/volunteer communities (WMCS/Toolforge etc.) so neither are good fits. This is perhaps similar to how other teams or departments communicate about their work like e.g. Research's research.wikimedia.org or Legal's transparency.wikimedia.org. We currently don't have a lot of that but we have at least this page, and I'd like to not regress but continue to have a venue for this, so that we can hopefully be able to improve on this further.

This is a use case that the old website accounted for, e.g. for that Peering page, but I'm unsure on how this use case is envisioned to be addressed in the new state of things (if at all!). I think setting up another wiki or static website for that kind of thing would be excessive and also a bit embarassing from an organizational perspective :) Do you have thoughts on what is supposed to be replacing this? Should we, for instance, get access to subpages on the main website? Or if that's not desired, what restricts us from using foundation.wikimedia.org not just for "governance" but also for "public information we want to communicate to third-parties"?

In T200754#4625233, @faidon wrote:

Ignoring the policy vs. Policy bits and delegation of powers for a moment there, I think the problem distills to the following:

There is information that SRE (and others in Tech?) maintain for the purposes of communicating information to third-parties, that are not volunteers that want to work on our stuff, and perhaps not necessarily even technical people (e.g. network peering managers). MediaWiki.org is (supposedely) about MediaWiki and Wikitech is a combination of internal documentation for us and documentation for our technical staff/volunteer communities (WMCS/Toolforge etc.) so neither are good fits. This is perhaps similar to how other teams or departments communicate about their work like e.g. Research's research.wikimedia.org or Legal's transparency.wikimedia.org. We currently don't have a lot of that but we have at least this page, and I'd like to not regress but continue to have a venue for this, so that we can hopefully be able to improve on this further.

This is a use case that the old website accounted for, e.g. for that Peering page, but I'm unsure on how this use case is envisioned to be addressed in the new state of things (if at all!). I think setting up another wiki or static website for that kind of thing would be excessive and also a bit embarassing from an organizational perspective :) Do you have thoughts on what is supposed to be replacing this? Should we, for instance, get access to subpages on the main website? Or if that's not desired, what restricts us from using foundation.wikimedia.org not just for "governance" but also for "public information we want to communicate to third-parties"?

Apologies if that was not made clearer before. The type of documentation you are describing are being migrated to Meta-Wiki (or other wikis if more appropriate). A proposal is being developed by On-wiki documentation group to help facilitate that on Meta-Wiki. Also, for clarity, that has been underway for a few years now and was originally unrelated to the new website and more related to discussions around making that documentation available on community-shared spaces. The only things being housed on Governance Wiki moving forward is content which we want to restrict edit access to as they have legal implications as we want to utilize community-shared spaces as much as possible. I agree setting up another site for this one page would be awkward. To my knowledge, I am not aware of any other pages on GovWiki which cannot be migrated to one of the existing wikis. If you are aware of others (the others mentioned above are already not on GovWiki), please let me know. If you think your team's needs are not being identified in this process, please let me know and also consider reaching out to your department's contacts (Deborah, Erika, and Joel) on the On-wiki documentation working group (which developed this plan) or possibly ask Victoria to be added as a rep from Tech to the group.

Is there a reason we do not want this page on a community-shared space (perhaps MediaWiki.org?)? If it needs to be restricted from community editing, then GovWiki might make sense - but as I mentioned above would then have a more complex editing process.

Are you suggesting that the only options now are a) content editable by everyone or b) content with legal implications and editable only by the Board/ED?

In search for similar examples, I noticed that you tagged the "Visual identity guidelines" page with Category:Pages to be exported to Meta-Wiki. How do you plan on handling this? Would these guidelines be up to the Meta community to decide, and if not, how will you handle access rights to that page? That may be a model we could follow perhaps.

In T200754#4626950, @faidon wrote:

Are you suggesting that the only options now are a) content editable by everyone or b) content with legal implications and editable only by the Board/ED?

In search for similar examples, I noticed that you tagged the "Visual identity guidelines" page with Category:Pages to be exported to Meta-Wiki. How do you plan on handling this? Would these guidelines be up to the Meta community to decide, and if not, how will you handle access rights to that page? That may be a model we could follow perhaps.

We will follow similar approaches as other wikis - revert unwanted edits, restrict when active vandalism occurs or on high-traffic pages, and monitor using watchlists and email notifications. Discussion on changes actually becomes easier than current GovWiki setup (although hopefully that will change in near future) as people can utilize the talk page. The amount of organization documentation on Meta-Wiki has continued to increase over the past few years (predating the new site) - sometimes at the request of Board or Leadership team and sometimes at request of community. The initial content audit of Foundation Wiki mentioned in the background of the new site project was in part done to help figure out the potential scope of doing so more intentionally (which is partially what eventually led to the On-wiki documentation working group).

Over the last several years, this approach has worked well for things like:

• Brand guidelines
• Board committees
• Fundraising principles
• Global Ban Policy
• User-Agent policy
• Affiliate policies (maintained by AffCom - but not always on Meta-Wiki in past as now)

That said, the On-wiki documentation working group is working on a proposal for some modifications to Meta-Wiki (and it will be up to the community to adopt - and we will modify our plans as necessary) - included in that proposal is a namespace specifically for Foundation materials - which may include (it's still being drafted) a proposal on restrictions around things like anonymous edits. Although we will continue to trust that the community will respect the documentation and may help with things like typos, link updates, etc. (as they do with the above mentioned pages from time to time).

Personally, I think many of the reasons why things were migrated from Internal Wiki and things are increasingly migrating from Office Wiki apply here. While there is a very natural and reasonable concern around tampering of important documentation, we have not seen that play out. Where there is a legal risk if that does ever occur, we have setup Governance Wiki.

Also, to clarify, the edits to policies are unlikely to be made by the ED or Board (Legal in general maintains the policies). Additionally, that site will have other content (such as certain Board materials and Legal documentation) - which are maintained by multiple people. So as a result, the number of people able to actively edit that content will become more limited than it is now - but not just ED and Board. Although we are hoping to open things like discussion pages to many more than are able to edit them now.

Regarding where to place this page if it is a community-shared space - the above examples were on MediaWiki.org and WikiTech. While those do not have the same setup as Meta-Wiki, I suspect it would still work well.

Super interesting -- I understand this plan much better now, thanks for the extensive explanation! I didn't mean to have you spend so much time on that -otherwise trivial- peering page, and apologies for doing so, but I was surprised and did not understand the full extent of your plans with regards to this kind of communication flow.

With regards to that page specifically... I guess Meta will do, given a number of other technical policies (e.g. the UA policy you listed) live there; I'm not sure if the Meta community will find it relevant and welcome it, but we can always find another solution if that isn't the case.

The following redirects were migrated from wikimediafoundation.org to foundation.wikimedia.org but are currently failing their expectations because they need to be configured at wikimediafoundation.org instead (source). Please restore the following urls for Internet compatibility:

• /bylaws.pdf => https://foundation.wikimedia.org/wiki/Bylaws
• /wiki/Wikimedia_Foundation_bylaws => https://foundation.wikimedia.org/wiki/Bylaws (already done)
• /fundraising => https://donate.wikimedia.org
• /fundraising.html => https://donate.wikimedia.org
• /wiki/Fundraising => https://donate.wikimedia.org
• /wiki/Donate => https://donate.wikimedia.org (already done)
• /GNU_FDL => https://foundation.wikimedia.org/wiki/GNU_Free_Documentation_License
• /GNU_FDL.html => https://foundation.wikimedia.org/wiki/GNU_Free_Documentation_License
• /wiki/GNU_Free_Documentation_License => https://foundation.wikimedia.org/wiki/GNU_Free_Documentation_License
• /index => https://wikimediafoundation.org
• /index.html => https://wikimediafoundation.org

In T200754#4630907, @Krinkle wrote:

The following redirects were migrated from wikimediafoundation.org to foundation.wikimedia.org but are currently failing their expectations because they need to be configured at wikimediafoundation.org instead (source). Please restore the following urls for Internet compatibility:

• /bylaws.pdf => https://foundation.wikimedia.org/wiki/Bylaws
• /wiki/Wikimedia_Foundation_bylaws => https://foundation.wikimedia.org/wiki/Bylaws (already done)
• /fundraising => https://donate.wikimedia.org
• /fundraising.html => https://donate.wikimedia.org
• /wiki/Fundraising => https://donate.wikimedia.org
• /wiki/Donate => https://donate.wikimedia.org (already done)
• /GNU_FDL => https://foundation.wikimedia.org/wiki/GNU_Free_Documentation_License
• /GNU_FDL.html => https://foundation.wikimedia.org/wiki/GNU_Free_Documentation_License
• /wiki/GNU_Free_Documentation_License => https://foundation.wikimedia.org/wiki/GNU_Free_Documentation_License
• /index => https://wikimediafoundation.org
• /index.html => https://wikimediafoundation.org

Do we know that these are actively in use somewhere? We are keeping an eye on incoming requests that are failing and getting 404 results. I do not see much evidence of these being requested since the new site launched. Some of these seem to date to the pre-wiki site - which would mean we have not actively used them in 14 years.

FWIW, the redirects are functioning correctly on GovWiki:

• https://foundation.wikimedia.org/bylaws.pdf
• https://foundation.wikimedia.org/fundraising
• https://foundation.wikimedia.org/fundraising.html
• https://foundation.wikimedia.org/wiki/Fundraising
• https://foundation.wikimedia.org/GNU_FDL
• https://foundation.wikimedia.org/GNU_FDL.html
• https://foundation.wikimedia.org/wiki/GNU_Free_Documentation_License
• https://foundation.wikimedia.org/index
• https://foundation.wikimedia.org/index.html

In T200754#4626984, @faidon wrote:

Super interesting -- I understand this plan much better now, thanks for the extensive explanation! I didn't mean to have you spend so much time on that -otherwise trivial- peering page, and apologies for doing so, but I was surprised and did not understand the full extent of your plans with regards to this kind of communication flow.

With regards to that page specifically... I guess Meta will do, given a number of other technical policies (e.g. the UA policy you listed) live there; I'm not sure if the Meta community will find it relevant and welcome it, but we can always find another solution if that isn't the case.

Awesome! I have setup the page on Meta-Wiki and setup the redirect as well.

In T200754#4631027, @Varnent wrote:

In T200754#4630907, @Krinkle wrote:

The following redirects were migrated from wikimediafoundation.org to foundation.wikimedia.org but are currently failing their expectations because they need to be configured at wikimediafoundation.org instead (source). [..]

Do we know that these are actively in use somewhere?

Per https://meta.wikimedia.org/wiki/Don%27t_delete_redirects, internal use within our pages is not the use case. The use case is the rest of the Internet, including semi-online venues that are accessible online but not current per-se. E.g. mailing lists, blog posts, social media. They aren't trending and hot right now, but they exist and will inevitably be followed. Rather than spend energy on every single case, the default should be to unbreak, unless we specifically know it was a temporary thing that wasn't published or mentioned anywhere for a prolonged period of time. None of the above fall in that category, though.

In T200754#4631027, @Varnent wrote:

FWIW, the redirects are functioning correctly on GovWiki:

• https://foundation.wikimedia.org/bylaws.pdf [..]

Yes, they work there, because we kept them as part of the site migration. However, they don't work because our server configuration only applies to foundation.wikimedia.org, not wikimediafoundation.org. They were meant to the new "wikimediafoundation.org", not the new "foundationwiki. Once this is done, I'll remove this code from foundation.wikimedia.org given that is a new domain without history.

In addition to the above, there's another fairly high profile policy link that is currently broken without redirect:

https://wikimediafoundation.org/wiki/General_disclaimer. This should redirect to https://foundation.wikimedia.org/wiki/General_disclaimer.

To avoid a continuing long tail of this, it might be a lot simpler to use /wiki/* wildcard redirect. The WordPress redirection system has support for order significance, which means the custom redirects you have that point to within the new site or elsewhere can be honoured first, and as fallback the plain redirect. That would cut the amount of redirect configuration by ~90%. (Depending on the version that Automatic uses, the high priority redirects should either be atop the list or at the bottom.)

In T200754#4632063, @Krinkle wrote:

In T200754#4631027, @Varnent wrote:

In T200754#4630907, @Krinkle wrote:

The following redirects were migrated from wikimediafoundation.org to foundation.wikimedia.org but are currently failing their expectations because they need to be configured at wikimediafoundation.org instead (source). [..]

Do we know that these are actively in use somewhere?

Per https://meta.wikimedia.org/wiki/Don%27t_delete_redirects, internal use within our pages is not the use case. The use case is the rest of the Internet, including semi-online venues that are accessible online but not current per-se. E.g. mailing lists, blog posts, social media. They aren't trending and hot right now, but they exist and will inevitably be followed. Rather than spend energy on every single case, the default should be to unbreak, unless we specifically know it was a temporary thing that wasn't published or mentioned anywhere for a prolonged period of time. None of the above fall in that category, though.

In T200754#4631027, @Varnent wrote:

FWIW, the redirects are functioning correctly on GovWiki:

• https://foundation.wikimedia.org/bylaws.pdf [..]

Yes, they work there, because we kept them as part of the site migration. However, they don't work because our server configuration only applies to foundation.wikimedia.org, not wikimediafoundation.org. They were meant to the new "wikimediafoundation.org", not the new "foundationwiki. Once this is done, I'll remove this code from foundation.wikimedia.org given that is a new domain without history.

I have not been able to find much evidence of these links being active (as I mentioned, most appear to be 14+ years old). I do not plan to add for now until we have a more robust redirect system in place for the site. The page you mentioned is an essay on wiki redirects and not a policy or best practice for general URL redirects. I spoke with a few engineers this week and they indicated the current method of going off logs on actively requested pages is best practice as keeping every version of a site's URL structure in place forever is not practical. However, if I was misinformed, please let me know.

In T200754#4640328, @Krinkle wrote:

In addition to the above, there's another fairly high profile policy link that is currently broken without redirect:

https://wikimediafoundation.org/wiki/General_disclaimer. This should redirect to https://foundation.wikimedia.org/wiki/General_disclaimer.

This has been setup.

To avoid a continuing long tail of this, it might be a lot simpler to use /wiki/* wildcard redirect. The WordPress redirection system has support for order significance, which means the custom redirects you have that point to within the new site or elsewhere can be honoured first, and as fallback the plain redirect. That would cut the amount of redirect configuration by ~90%. (Depending on the version that Automatic uses, the high priority redirects should either be atop the list or at the bottom.)

This idea has been discussed a few times already in this thread. See above for info.

In T200754#4640364, @Varnent wrote:

I have not been able to find much evidence of these pages being active.[..] engineers, [they] indicated the current method of going off logs on actively requested pages is best practice.

That guideline and this best practice produce the same outcome. The difference in the effort required.

If your company acquired a domain from a former competitor, it makes sense to tail logs for old urls people are hitting. You should pick the most popular ones and redirect them to similar content and services your new company offers. In a commercially driven context, where the original isn't around anymore, that makes a ton of sense. The alternative of proactive prevention, there, would be to dig through an archive of urls (or to list every 404 you ever get) and try to guess a new url for each one. That's not remotely profitable or useful. I would make the same recommendation as your engineer there. But, this does not seem relevant to us. Would you agree?

The proactive approach in our case, on the other hand, is quick, simple, and directly resolves and prevents all errors from the wiki.

The current approach being followed is waiting for each potential url to show up in WordPress' logs as broken, then we'll wait for an arbitrary of number users we deem unacceptable to not serve the page that we know they're looking for? And then you'll manually add a redirect? What's the cut off there? Will this become our job going forward, so that when there's a spike in 404s sometime next year, we'll keep monitoring and adding them?

In T200754#4640364, @Varnent wrote:

This idea has been discussed a few times already in this thread. See above for info.

I did check. I found two concerns, summarised below:

1. We have some specific urls under /wiki that we'd like to keep within the new site.

This is compatible. The Automatic redirection system supports precedence, by default.

2. We want want users that are looking for a page we personally don't find popular or interesting, to instead see our new 404 page design - instead of the page they were actually and explicitly looking for and we know still exists.

Why?

In T200754#4640510, @Krinkle wrote:

In T200754#4640364, @Varnent wrote:

I have not been able to find much evidence of these pages being active.[..] engineers, [they] indicated the current method of going off logs on actively requested pages is best practice.

That guideline and this best practice produce the same outcome. The difference in the effort required.

If your company acquired a domain from a former competitor, it makes sense to tail logs for old urls people are hitting. You should pick the most popular ones and redirect them to similar content and services your new company offers. In a commercially driven context, where the original isn't around anymore, that makes a ton of sense. The alternative of proactive prevention, there, would be to dig through an archive of urls (or to list every 404 you ever get) and try to guess a new url for each one. That's not remotely profitable or useful. I would make the same recommendation as your engineer there. But, this does not seem relevant to us. Would you agree?

The proactive approach in our case, on the other hand, is quick, simple, and directly resolves and prevents all errors from the wiki.

The current approach being followed is waiting for each potential url to show up in WordPress' logs as broken, then we'll wait for an arbitrary of number users we deem unacceptable to not serve the page that we know they're looking for? And then you'll manually add a redirect? What's the cut off there? Will this become our job going forward, so that when there's a spike in 404s sometime next year, we'll keep monitoring and adding them?

In T200754#4640364, @Varnent wrote:

This idea has been discussed a few times already in this thread. See above for info.

I did check. I found two concerns, summarised below:

1. We have some specific urls under /wiki that we'd like to keep within the new site.

This is compatible. The Automatic redirection system supports precedence, by default.

2. We want want users that are looking for a page we personally don't find popular or interesting, to instead see our new 404 page design - instead of the page they were actually and explicitly looking for and we know still exists.

Why?

I am not sure which Automatic redirection system you are referring to, but the one which has been setup for us is not as robust (unfortunately) as you are describing. It does not, for example, allow us to set priorities. Hence why we would like to move to a more robust system at some point.

One additional reason to consider is that the two sites in question (Governance Wiki and the main site) have different audiences. So if someone for the new site happens to click on an outdated link, we would rather they go to the new site than Governance Wiki. Especially as the amount of content on GovWiki will be considerably less than it was when the new site went up - so odds are what they are looking for while not be on that site anyway (although in theory should be a redirect telling them where - but sometimes that may be the new site we just redirected them away from).

So far, I am not aware of actual problems with the approach we are using now (I am familiar with the abstract problems - but none have actually surfaced). We will certainly review that if things change, but so far it does not appear to be, so this would be creating a lot more work for us (given the redirect system is not very robust and so much of GovWiki is moving around) without clear gains for the audiences of the main website. The link you found, for example, had not been actively used in links for some time (we moved it to Wikimedia:General disclaimer a few years ago). If people are coming from a place with a link that outdated (especially if it's a link to our 14 year old site), there is a reasonable chance we want them to see the new site and not be directed to a governance documentation site (which has far less chances of containing what they are looking for, unless it is a policy, but that represents a small percentage of incoming links, and most have been resolved with redirects).

The link I referred is actually in current use, at https://wikitech-static.wikimedia.org.

Regarding the redirect system, knowing Automatic, I'm entirely sure that their system will not crash when multiple redirect paths overlap, and that there is most certainly a consistent processing order among the redirect. Whether there is a user-interface feature to say "This goes first" is a secondary question, but I'm sure that if asked they'd kindly show you how to do it, or do it for you.

Regarding the audience. Two points:

1. Let's not pretend that this is a big deal with gains to have for ourselves. We're talking about the <0.1% of visitors who have found a link to a url that is both uncommon (not already redirected by you) and matches the pattern of wikimediafoundation.org/wiki/%. This is not the place where we're going to "make a difference". This is a tiny edge case that won't affect the success of the site in any way. The only thing we have to gain/lose is whether a rare visitor looking for a page that is now on GovWiki will find it, or not.
2. If we what we want is for visitors following a url to the old site for a title that doesn't exist anymore on GovWiki, to instead see our home page on the new site - just say so. That's a very reasonable ask, and while conceptually it may sound complex to you, it is a super easy thing to implement.

For example, on the end of foundation.wikimedia.org we could trivially redirect visitors automatically our brand new WMF Home page if they come from wikimediafoundation.org and the page doesn't exist at the time they visit it. Would you like that? I'd be happy to implement that tomorrow.

In T200754#4640574, @Krinkle wrote:

1. Let's not pretend that this is a big deal with gains to have for ourselves. We're talking about the <0.1% of visitors who have found a link to an url that is both uncommon (not already redirected by you) and matches the pattern of wikimediafoundation.org/wiki/%. This is not the place where we're going to "make a difference". This is a tiny edge case that won't affect the success of the site in any way.

I agree - hence why I am not planning to put more time into this right now and instead focusing on more impactful requests. :)

In T200754#4640574, @Krinkle wrote:

The link I referred is actually in current use, at https://wikitech-static.wikimedia.org.

Interesting - I will let the engineers know that site is not following the typical setup for the links as it should have been updated years ago.

Regarding the redirect system, knowing Automatic, I'm entirely sure that their system will not crash when multiple redirect paths overlap, and that there is most certainly a consistent processing order among the redirect. Whether there is a user-interface feature to say "This goes first" is a secondary question, but I'm sure that if asked they'd kindly show you how to do it, or do it for you.

We have indeed spoken to them about these. They are actually some of the folks who advised us on the setup we are using. I am not sure it's a matter of the system crashing so much as the redirect system we are using (which is database driven) being able to do what you want in a way that consistently works (the system we are using just got an order setup in it's most recent update - but it does not work the way one would expect and has not been consistent in tests - it appears the developer is building that functionality out - but it is not production site ready yet).

In T200754#4640574, @Krinkle wrote:

For example, on the end of foundation.wikimedia.org we could trivially redirect visitors automatically our brand new WMF Home page if they come from wikimediafoundation.org and the page doesn't exist at the time they visit it. Would you like that? I'd be happy to implement that tomorrow.

I would need to check with a few teams working on those sites before I could sign off on any suggestion like this (sending users back and forth between sites and servers would require a review by security if nothing else). However, as you mentioned, the impact would be very small, so I am not sure it makes sense to spend the time doing that right now. That said, if you would like to begin the work so it is ready for when we do get around to the redirect system, I am certainly not opposed to the overall idea. :)

(sending users back and forth between sites and servers would require a review by security if nothing else).

I can assert from a security perspective, this is fine. In fact we use these type of redirect chains on Wikimedia sites already. (As with all things, it is of course possible to implement it insecurely, but I don't think there's any more risk of that then there is with any other thing. The only real potential risks are redirect loops and open redirect, both seem unlikely in this scenario).

If you're asking from a privacy perspective, that's a question for legal not security. However given that the above suggestion is to only redirect people from govwiki->wmf.org if they have a wikimediafoundation.org referrer, I have trouble imagining that it would be problematic.

I've got a proof-of-concept working locally that, when incoming browser referrer is a certain origin, redirects page views of MediaWiki urls that don't exist to a specified external url. I'll refine it a bit more, but once finished, we can deploy that to foundation.wikimedia.org to automatically bounce to the wikimediafoundation.org Home page for wikimediafoundation.org/wiki redirects that don't have a page on foundation.wikimedia.org.

@Varnent Can you check with Automatic on the difficulty and timeline of setting up a simple /wiki/* redirect from wikimediafoundation.org to foundation.wikimedia.org in a way that doesn't affect your existing redirects?

In T200754#4705317, @Krinkle wrote:

I've got a proof-of-concept working locally that, when incoming browser referrer is a certain origin, redirects page views of MediaWiki urls that don't exist to a specified external url. I'll refine it a bit more, but once finished, we can deploy that to foundation.wikimedia.org

This is needed more and more. I just found fundraising links from Wikimedia UK to wikimediafoundation.org which are completely broken.

https://boards.greenhouse.io/wikimedia links https://wikimediafoundation.org/wiki/Frequently_asked_questions which is a 404. Is someone monitoring incoming 404? If not, it's necessary to instate redirects for everything left over.

In T200754#5415514, @Nemo_bis wrote:

https://boards.greenhouse.io/wikimedia links https://wikimediafoundation.org/wiki/Frequently_asked_questions which is a 404. Is someone monitoring incoming 404? If not, it's necessary to instate redirects for everything left over.

Still is. Just got another complaint about a 404.

In T200754#5594348, @Nemo_bis wrote:

In T200754#5415514, @Nemo_bis wrote:

https://boards.greenhouse.io/wikimedia links https://wikimediafoundation.org/wiki/Frequently_asked_questions which is a 404. Is someone monitoring incoming 404? If not, it's necessary to instate redirects for everything left over.

Still is. Just got another complaint about a 404.

Can you direct the person with the complaint to me (gvarnum@wikimedia.org)? I would be interested in asking them a few followup questions. Thank you!