https://annual.wikimedia.org/

placeholder page - content could be uploaded if available and it's just static pages, images, videos

do we know what the size of this will be?

P.S. still pending the naming discussion

The annual report is up since 8.30am PST yesterday, as agreed on with the communications team.
..and Heather just presented it at the Allhands event.

https://annual.wikimedia.org and https://annual.wikimedia.org/2014/

Change 199087 had a related patch set uploaded (by Chmarkine):
annual - Enable HSTS max-age=7 days

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

Change 199087 merged by Dzahn:
annual - Enable HSTS max-age=7 days

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

Change 206984 had a related patch set uploaded (by Chmarkine):
annual - Raise HSTS max-age to 1 year and add "always"

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

Change 206984 merged by BBlack:
annual - Raise HSTS max-age to 1 year and add "always"

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

Adding to the complexity this year, we are celebrating Wikipedia's 15th birthday with the annual report. We would prefer if the new site can live at 15.wikipedia.org or if necessary, something like wikipedia15.org

The annual report could redirect to that url.

So there was ten.wikipedia.org but now you want 15.wikipedia.org instead of fifteen.wikipedia.org?
Also, how is the annual report relevant to wikipedia turning 15?

In T599#1654736, @Krenair wrote:

So there was ten.wikipedia.org but now you want 15.wikipedia.org instead of fifteen.wikipedia.org?

"15" eliminates the need for translations.

Also, how is the annual report relevant to wikipedia turning 15?

Because the annual report is being used as an integral part of the Wikipedia 15 campaign; see also Wikipedia 15 on meta.

In T599#1654750, @jrbs wrote:

In T599#1654736, @Krenair wrote:

So there was ten.wikipedia.org but now you want 15.wikipedia.org instead of fifteen.wikipedia.org?

"15" eliminates the need for translations.

And eliminates any hope of consistency. I suggest ops decline this.

Also, how is the annual report relevant to wikipedia turning 15?

Because the annual report is being used as an integral part of the Wikipedia 15 campaign; see also Wikipedia 15 on meta.

That doesn't even make sense.

I don't want to drag this out too far (and I feel the tone here is pretty needlessly aggressive, imo), but to reply:

In T599#1654784, @Krenair wrote:

In T599#1654750, @jrbs wrote:

In T599#1654736, @Krenair wrote:

So there was ten.wikipedia.org but now you want 15.wikipedia.org instead of fifteen.wikipedia.org?

"15" eliminates the need for translations.

And eliminates any hope of consistency. I suggest ops decline this.

If that's your opinion. I would argue that ten.wikipedia was, and should remain, the incorrect decision and that 10.wikipedia would have made much more sense. (And surely you can see that "fifteen.wikipedia.org" is silly.)

Also, how is the annual report relevant to wikipedia turning 15?

Because the annual report is being used as an integral part of the Wikipedia 15 campaign; see also Wikipedia 15 on meta.

That doesn't even make sense.

Well, I apologise for that. @Heather knows more about that integration than I do, and I think right now we're at the early staging of working out this link.

Again, I'm not sure why you've taken this sort of tone on this task, but for the sake of people's inboxes I'm not going to continue this thread any further.

I would suggest to use the wikimedia.org domain and avoid adding special microsites into the .wikipedia.org domain that are not actual wikipedia wikis. I know there has been precedence in the past but they tend to just cause more issues than initially expected and/or need special workarounds in configuration.

For the annual report we should keep using annual.wikimedia.org. The change will just be that the redirect changes from ./2014 to ./2015. That was also the original plan when creating annual.wm and not something like annual2014.wm. Also this is not the Wikipedia Annual report but for the entire Foundation. Technically it would also make sense on wikimediafoundation.org because it really is the WMF report but we already have it on annual.wikimedia.org

For the Wikipedia birthday i would reconsider using it unless it's an actual wiki like ten.wp is. In that case, yes, it should be called "fifteen". I'm not even sure if just numbers won't cause us trouble in other places. For example the wiki name also becomes a database name and other things.

While RFC 1123 technically relaxed RFC 952 which did not allow host names to start with a number, RFC 1178 still suggests Don't use digits at the beginning of the name.

We set wildcard *.wikipedia.org CentralAuth cookies, so we should not be creating any new non-MediaWiki sites under that domain, as they should not have access to those cookies.

We intentionally do not do this for *.wikimedia.org, because of all the misc. sites that live under it.

In T599#1655058, @jrbs wrote:

I feel the tone here is pretty needlessly aggressive
I'm not sure why you've taken this sort of tone on this task

Please don't take this personally. I'm not trying to be aggressive, if that's how my messages have read then I'm sorry. I'm more frustrated with a wider issue that this is just another instance of.
The problem I have is that I am tired of most of Wikimedia's projects being undermined by organisational focus on Wikipedia only, as if we do nothing else, I guess because that is the most well known. To the point where we have seen software projects (minor tasks and real huge projects) focused on Wikipedia only. I'm not going to call out anyone else in particular for this right now.
Tying the Wikimedia Foundation's Annual Report to Wikipedia's birthday only (to the point of sending Annual Report traffic to a new site celebrating Wikipedia's birthday) is an occurrence of this same pattern I've seen from many people, not just the WMF. However, in my personal opinion as a volunteer (I shouldn't really need to clarify that part, *sigh*), all WMF staff should know (that it is not called the Wikipedia Foundation) better - Wikimedia Communications departments in particular should not have an excuse.

In T599#1655109, @Dzahn wrote:

Also this is not the Wikipedia Annual report but for the entire Foundation. Technically it would also make sense on wikimediafoundation.org because it really is the WMF report but we already have it on annual.wikimedia.org

Yeah, well, I agree, but that is not the worst aspect of all of this mess. For example, Foundation staff mail goes via @wikimedia.org even though it should obviously be @wikimediafoundation.org. I have a feeling these sorts of things would be difficult to reform now, sadly.

@Krenair

You make good points. There are a few reasons why focusing on only Wikipedia for the 15th anniversary could be confusing, or a bad idea. We’ve spent a lot of time thinking about this, because we want to be as inclusive of different communities and languages as possible. As a result, this year our intention is to celebrate the 15th anniversary of the birth of an amazing idea and community. It is not about English Wikipedia, or even about Wikipedia alone. 15 January 2001, is the start of this great movement and human accomplishment that we think should be celebrated.

At the same time, most of our users are most familiar with the name Wikipedia. It is the name and project they know best, of all of our projects. On the birthday, we want everyone to feel as though they can celebrate with us and get to know us better. Inviting them to do so via Wikipedia -- the project they know best -- is the natural place to start. And starting with Wikipedia is also authentic to our broader movement, which started with Wikipedia too.

And as far as how the annual report factors into this: the annual report is one of the ways that we show our appreciation for our supporters, and the place where we share their names. It is also a unique place to tell a visual, narrative story. It is a tool we use with everyone, not just donors, to explain our mission and passion to the world. In the year of our 15th birthday, it is natural that we would want to tell a story of our 15 years, and share with people why that matters.

We felt as though this created a special opportunity to do two things -- tell our story to more people than just our supporters and donors. And conserve resources by celebrating our birthday using something we already build every year. So we are putting these things together: the annual report will be a place that helps celebrate our movement, while serving a functional transparency and reporting purpose.

Regards,
Heather

Back to the actual site name. :)

RFC 1178 says...

Don't use digits at the beginning of the name.

Many programs accept a numerical internet address as well as a
name.  Unfortunately, some programs do not correctly
distinguish between the two and may be fooled, for example, by
a string beginning with a decimal digit.

Names consisting entirely of hexadecimal digits, such as
"beef", are also problematic, since they can be interpreted
entirely as hexadecimal numbers as well as alphabetic strings.

...and I copy it here because it also says "beef" is problematic -- and that is hilarious.

Last year I read this rather cool article about [[http://www.newrepublic.com/article/117608/chinese-number-websites-secret-meaning-urls | Chinese number URL]]s. I am not an expert in the topic, but number URLs seem not unheard of.

Unless it is an actual blocker, I would like to request that we use 15.wikipedia.org. "Fifteen" is too long (among other things), and "annual report" is not an appropriate destination for the celebration of the anniversary of the movement. Wikipedia is what people will recognize.

Thank you so much for your help!
Heather

In T599#1664950, @Heather wrote:

RFC 1178 says...

Don't use digits at the beginning of the name.

Names consisting entirely of hexadecimal digits, such as
"beef", are also problematic, since they can be interpreted
entirely as hexadecimal numbers

...and I copy it here because it also says "beef" is problematic -- and that is hilarious.

hehe, yes it is hilarious indeed. people often use 'dead beef' in IPv6 addresses because it can be written with just a-f

I am not an expert in the topic, but number URLs seem not unheard of.
Unless it is an actual blocker, I would like to request that we use 15.wikipedia.org. "Fifteen" is too long (among other things),

i would like to add @BBlack to the conversation here and hear his opinion

I wanted to let you know that URLs for annual reports in the past, before 2014,
for example if a user tries https://annual.wikimedia.org/2013 after seeing that we have 2014 and 2015,
are now redirected to the foundation wiki.

Reports from 2007 thru 2013 were in the form of PDF files and are all linked on that wiki page.

This was T113113 and change 240735

In T599#1664950, @Heather wrote:

Unless it is an actual blocker, I would like to request that we use 15.wikipedia.org. "Fifteen" is too long (among other things), and "annual report" is not an appropriate destination for the celebration of the anniversary of the movement. Wikipedia is what people will recognize.

I think you missed my comment above about why anything under wikipedia.org is not possible due to how we set SUL cookies:

In T599#1655201, @Legoktm wrote:

We set wildcard *.wikipedia.org CentralAuth cookies, so we should not be creating any new non-MediaWiki sites under that domain, as they should not have access to those cookies.

We intentionally do not do this for *.wikimedia.org, because of all the misc. sites that live under it.

I didn't miss your comment, I read that it said "should not". Since I don't know the ins and outs of the technology, I have no idea if should means absolutely can't, or if there are exceptions and work-arounds.

In T599#1673113, @Heather wrote:

I didn't miss your comment, I read that it said "should not". Since I don't know the ins and outs of the technology, I have no idea if should means absolutely can't, or if there are exceptions and work-arounds.

I don't think it's worth a potential compromise of user's login sessions so a static site can live at a prettier domain.

As I recall, 10.wikipedia.org couldn't be used because the DNS management interface disallowed it, and that was the end of that. There's a ticket about this somewhere in Phabricator Maniphest. You all should read up.

In T599#1655201, @Legoktm wrote:

We set wildcard *.wikipedia.org CentralAuth cookies, so we should not be creating any new non-MediaWiki sites under that domain, as they should not have access to those cookies.

I don't understand this argument. How is a non-MediaWiki site so dangerous, especially considering that arbitrary JavaScript, CSS, and HTML can be injected by local site administrators across *.wikipedia.org? Or perhaps put another way: why is a wiki considered safe and a micro-site isn't?

I don't think it's worth a potential compromise of user's login sessions so a static site can live at a prettier domain.

What is this assuming, exactly? I'm thinking any implementation here would be some version of a static HTML file on a server (which is essentially what happens with MediaWiki wikis behind a caching layer...). A potential compromise in what sense or in which scenarios are you talking about here? What's the actual threat or concern here?

Having fifteen.wikipedia.org or whatever is dumb and gimmicky and shouldn't be done. That said, the reasonable compromise from past arguments about these inane micro-sites is to require that the content gets saved to Meta-Wiki (which is basically captured by requiring a "wiki version for translation"). We must continue to do that.

In T599#1673465, @MZMcBride wrote:

In T599#1655201, @Legoktm wrote:

We set wildcard *.wikipedia.org CentralAuth cookies, so we should not be creating any new non-MediaWiki sites under that domain, as they should not have access to those cookies.

I don't understand this argument. How is a non-MediaWiki site so dangerous, especially considering that arbitrary JavaScript, CSS, and HTML can be injected by local site administrators across *.wikipedia.org? Or perhaps put another way: why is a wiki considered safe and a micro-site isn't?

I wouldn't consider a wiki to be safe, but we don't have any other choice, those cookies have to be read by MediaWiki. We shouldn't open new security issues just because there are already open holes.

I don't think it's worth a potential compromise of user's login sessions so a static site can live at a prettier domain.

What is this assuming, exactly? I'm thinking any implementation here would be some version of a static HTML file on a server (which is essentially what happens with MediaWiki wikis behind a caching layer...). A potential compromise in what sense or in which scenarios are you talking about here? What's the actual threat or concern here?

An attacker would need to find an XSS in the static site. Unfortunately it's not just a "static HTML file", there's also a bunch of JS being loaded, including a file from tool labs (which has been compromised in the past).

In T599#1673465, @MZMcBride wrote:

10.wikipedia.org couldn't be used because the DNS management interface disallowed it, and that was the end of that. There's a ticket about this somewhere in Phabricator Maniphest.

Couldn't find that, only T35185: Closure of ten.wikipedia.org

What is this assuming, exactly? I'm thinking any implementation here would be some version of a static HTML file on a server (which is essentially what happens with MediaWiki wikis behind a caching layer...). A potential compromise in what sense or in which scenarios are you talking about here? What's the actual threat or concern here?

An attacker would need to find an XSS in the static site. Unfortunately it's not just a "static HTML file", there's also a bunch of JS being loaded, including a file from tool labs (which has been compromised in the past).

The new site hasn't been designed yet, it will not be a copy of the last one.

In T599#1673711, @Aklapper wrote:

In T599#1673465, @MZMcBride wrote:

10.wikipedia.org couldn't be used because the DNS management interface disallowed it, and that was the end of that. There's a ticket about this somewhere in Phabricator Maniphest.

Couldn't find that, only T35185: Closure of ten.wikipedia.org

Google couldn't find anything either, but I did find https://ten.wikipedia.org/wiki/Talk:Main_Page#The_what_now.3F and https://ten.wikipedia.org/wiki/FAQ#Why_did_you_choose_this_domain.3F_Doesn.27t_it_conflict_with_a_regular_Wikipedia.3F

Like you just pointed out, in 2010 Stephen Walling said https://ten.wikipedia.org/wiki/Talk:Main_Page#The_what_now.3F

As ✓ pointed out, Tama (the one that ten is the code for) is an extinct language without a literate tradition. The Wikipedia that is a living language called Tama is represented by tam. The issue was brought up by langcom folks before the site was opened to editing, and they concurred that it is acceptable in this case even if it conflicts with ISO standards, since there is no conceivable way that a Tama Wikipedia will be requested. Our first choice was actually the more culturally-neutral 10.wikipedia.org, but MediaWiki is unable to handle having numerals at the beginning of a domain name at this point, so there was no way around it. There will be a more lengthy introduction to the wiki on the mailing list for tenth anniversary, and I'll be sure to link to the thread if you'd like. Steven Walling at work 01:15, 11 November 2010

Is that a blocker for what we are talking about now?

In T599#1675057, @Legoktm wrote:

[...] I did find https://ten.wikipedia.org/wiki/Talk:Main_Page#The_what_now.3F and https://ten.wikipedia.org/wiki/FAQ#Why_did_you_choose_this_domain.3F_Doesn.27t_it_conflict_with_a_regular_Wikipedia.3F

Right, that first link has the info I'm referencing:

I just talked to Rob H. from our operations team, and he explained to me that the PowerDNS server spit out an error when he tried to set it up, so it may be an issue with DNS routing rather than MediaWiki. Steven Walling at work 17:29, 23 November 2010 (UTC)

I thought the domain creation had been tracked in Bugzilla and imported into Phabricator Maniphest, but I guess not. My bad.

I dug up the relevant log file from #wikimedia-tech, 2010-10-26:

[17:21:05] <kibble> RobH, btw, if possible, it'd probably be better to create that new 10wiki at 10.wikipedia.org and not ten.wikipedia.org.  (I've seen both in the logs, so just wanted to throw in the comment about the better name :p)
[17:21:30] <RoanKattouw> kibble: He tried but it seemed something didn't like the numerical name
[17:21:40] <RoanKattouw> Although he did other stuff wrong too, so just maybe 10wiki *will* work
[17:22:02] <RoanKattouw> RobH: Out of curiosity, exactly what went wrong with 10wiki? Did you try to use 10wiki as a DB name too?
[17:22:17] <kibble> Maybe wiki10 or something, since we do have sep11wiki or something.
[17:22:24] <RobH> RoanKattouw: all kinds of issues
[17:22:30] <RobH> in ops meeting and dropped it until later today
[17:22:46] <kibble> (The reason "10" is better than "ten" is because the # is language neutral and it also doesn't conflict with ISO codes.)
[17:22:49] <RoanKattouw> kibble: For various reasons, the database name and the URL MUST match
[17:22:57] <RobH> kibble: 10 in urls is not ok
[17:23:06] <RobH> so its not an option, not my call, its a technical limitation.
[17:23:07] <RoanKattouw> So if the URL is 10.wikipedia.org , the DB name MUST be 10wiki
[17:24:23] <kibble> RoanKattouw, I wasn't saying otherwise. :-)
[17:24:39] <RoanKattouw> kibble: You suggested wiki10
[17:24:50] <kibble> RobH, what do you mean?
[17:24:53] <RoanKattouw> Or did you mean wiki10.wp.o and wiki10wiki ?
[17:25:11] <kibble> RobH, we have wikimania2011.wikimedia.org and similar stuff.
[17:25:14] <RobH> the url cannot be 10.wikipedia.org
[17:25:17] <RobH> powerdns hates it.
[17:25:26] <kibble> RoanKattouw, yeah, that.  Since it's like that day.
[17:25:49] <kibble> Er, year.
[17:25:50] <RobH> wikipedia10.wikimedia.org would be awesome, but i am not dealing with it much until post ops meeting.
[17:26:43] <kibble> That sounds like a good idea. :-)

There's also some discussion in #wikimedia-operations on the same day, but none of it is very interesting. The short version is basically:

• it's problematic when the domain name and database name don't align as a number of scripts and processes expect them to be roughly the same; and
• PowerDNS simply disallowed "10.wikipedia.org" to be created in 2010.

I don't know if PowerDNS is still being used and/or if this numeral restriction is still in place (though my guess to both would be yes). As far as I know, MediaWiki itself has no issue with a domain name similar to "15.wikipedia.org".

Thanks for the summary, @MZMcBride. Disappointing if this is still the case today, but understandable.

wikipedia15.wikimedia.org might not be a bad shout if we want to rule out wikipedia15.org, but fifteen.wikipedia.org is probably too messy.

We don't know if it is still the case, a lot has changed since 2010. Who can answer for sure?

I have brought this question up in the ops meeting on Monday, and the consensus was that we still can't offer number-only hostnames, so no 15.wikipedia.org, even when it doesn't use Mediawiki. Sorry.

TL;DR - From Ops' perspective, we don't recommend using a numeric hostname like 15.wikipedia.org. We can try it, but we may run into server or client -side issues which are unresolvable and require us to switch to a backup plan using a non-numeric hostname.

To recap the potential technical-level problems with 15.wikipedia.org (and similar hostnames), breaking it down into a few areas:

RFC Technicalities - Basically doesn't recommend it, but doesn't forbid it either:

• RFC 952 - As mentioned much earlier in this ticket, RFC 952 originally forbade hostname labels beginning with anything but an alphabetic letter in 1985
• RFC 1123 from 1989 relaxed this restriction and allows hostnames to begin with numbers. The wording in RFC 1123 indicates that all software dealing with hostnames should also accept a numeric address, and that it should first try to parse the string as a legal numeric address, and then only consider it as a hostname if numeric address parsing fails. In the case of now-legal (as of RFC 1123) hostnames which might be ambiguous (such as the hostname 192.0.2.1), the mitigating factor preventing the ambiguity is that no actual numeric TLDs exist (i.e. there is no .1 top-level domain in public DNS along side .com and such), but this is a somewhat weak argument, as it's possible to define arbitrary TLDs for private use, and then it's possible that software implementations have tried to do more advanced and/or silly things to make those work when people complained about the standard algorithm ("check for numeric address first") caused those to fail...
• RFC 1178 from 1990 recommends against using numbers at the start of hostnames, and also recommends against using hostnames which are legitimate hexidecimal numbers like beef, as hex is a valid numeric address format. The reasoning is that while 1123 is specific in how to deal with these cases, there are many independent software implementations out there which might be implemented poorly and naively check only for "does this string start with numeric stuff" to make the address vs hostname distinction. This is a classic application of the Robustness Principle - just because something is protocol-legal doesn't mean it's a great idea if it's a corner case that other implementations might be likely to fail at.

DNS Issues - probably a non-issue:

• The DNS itself doesn't care about this issue when it comes to domainname label data in the wire-format packets, which can contain arbitrary binary bytes if necessary. It's only the logical "hostname" meaning of the label that makes it a bad idea here, which we've covered above.
• However, some DNS implementations may fail to accept such a hostname. As indicated above, we've had that problem with PowerDNS in the past. Since then we've switched to a different DNS server implementation, and that implementation will serve numeric hostnames to the Internet just fine.

Other Server-side Issues - questionable, but probably ok:

• I really can't say one way or the other whether all of our software stack (critically, apache itself, and also anything at the application layer interpreting hostnames from Host: headers) will trip on this. It will probably be ok, but we'll have to actually try it to see whether any issues it causes can be addressed in configuration or not.

Client-Side Issues - questionable, but probably ok:

• Probably most major clients (major browsers on reasonable OS platforms) will be fine, but we really have no way to exhaustively investigate whether this will break with older and/or corner-case platforms like older feature phones, set-top box browsers, older OS releases with various browsers installed, etc.
• Google searches turn up hits like these, where Vista uses the old RFC 952 rules and doesn't work with all-numeric hostnames. However, I think even that link is about local hostnames that aren't fully qualified, and it probably wouldn't be an issue for a fully (alphabetic) qualified name like 15.wikipedia.org; it would only have been an issue for e.g. https://15 from a computer with wikipedia.org as the default domainname.

Thank you all for so much background and attention to this question, we really appreciate the time taken to uncover possible issues.

We would like to move forward on 15.wikipedia.org, with the understanding that something might come up, and we'll deal with it at that time.

This will mean we have to add "15" to the list of wikipedia languages. Since "15" isn't a language this will cause issues in several places, including that it will be become a data base name. The platform engineering team will also have to chime in on these issues.

This will also create the DNS entry "15" in all other projects, not just Wikipedia, because the templates are generated from lang list. Usually all language additions have to through an approval process on wiki.

@Heather Are you guys also expecting a mobile version of this? That would be "15.m.wikipedia.org" and require the mobile team to make changes as well and influence more things like redirect rules for mobile devices and tablets.

Change 248504 had a related patch set uploaded (by Dzahn):
add 15.wikipedia.org and 15.m.wikipedia.org

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

@Heather one more question. So are we still going to have static HTML or is this going to be a wiki?

Random notes:

• If there are technical problems with having a numeric-only domain, we'd better play safe.
• It would require fiddling with mobile redirects for this site, making exceptions, etc.
• With my MediaWiki developer and deployer hat on: having an exception under wikipedia.org that's not runnung MediaWiki is an eww. Having a Wikipedia in language "15" is eww no less.
• Please please please don't put this under .wikipedia.org - we've had problems with having to care about things that are not a Wikipedia in an X language, e.g. ten or sep11.

In T599#1749450, @Heather wrote:

We would like to move forward on 15.wikipedia.org, with the understanding that something might come up, and we'll deal with it at that time.

Just to be clear: while on the ops and dns front (which is separate from e.g. MaxSem's concerns above): while we can move forward with an attempt, as we deal with the issues that may come up, some of them may simply be unresolvable and require backing out of this plan.

@Dzahn it is not going to be a wiki.

@BBlack I totally understand that we might need to back out of the plan. Thank you for the clarity.

Honestly, I'd be more worried about code that assumes anything *.wikipedia.org/* is going to be MediaWiki.

https://gerrit.wikimedia.org/r/#/c/254168/

^ this is the initial change as uploaded by muledesign, but not the final version. a security review has been requested.

please see the comments on that gerrit link. the concerns raised have been:

• no license specified (i think GPL is fine as we talked about per mail)
• please use https:// links instead of http://
• please upload un-minified versions of the java script files for @csteipp to review

thanks!

Would you please update annual.wikimedia.org to redirect to 15.wikipedia.org?

Thank you!

Change 263562 had a related patch set uploaded (by Dzahn):
redirect annual.wm.org to 15.wikipedia.org

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

@Heather ok, that would be this change: https://gerrit.wikimedia.org/r/#/c/263562/1/index.html

currently https://annual.wikimedia.org/ redirects to https://annual.wikimedia.org/2014/

originally it was expected that this would just switch to /2015/

So instead of that it would mean https://annual.wikimedia.org/ redirects to https://15.wikipedia.org and that is the canonical URL for that.

The other option would be to redirect annual.wm and 15.wp both to annual.wikimedia.org/2015/ and have the content there.

In both cases all URLs would work, it's just the question which one is the end of the redirection.

Would you please update annual.wikimedia.org to redirect to 15.wikipedia.org?

This doesn't look like a compliant use of the redirect feature, the two things have nothing to do with each other.

The end of the redirect should be 15.wikipedia.org

The two things do have something to do with each other, this is our annual report for this year.

Thanks, everyone.

Change 263648 had a related patch set uploaded (by Dzahn):
varnish/misc-web: add 15.wp.org -> bromine backend

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

Change 263648 merged by Dzahn:
varnish/misc-web: add 15.wp.org -> bromine backend

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

Change 263652 had a related patch set uploaded (by Dzahn):
(WIP) - add Apache site for 15.wp.org

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

Change 263652 merged by Dzahn:
annualreport: add Apache site for 15.wp.org

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

Change 248504 merged by Dzahn:
add 15.wikipedia.org -> misc-addrs

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

https://15.wikipedia.org/ has been added now (DNS/Varnish/Apache/Puppet config)

and says "coming soon" while waiting for the content review / upload

https://gerrit.wikimedia.org/r/#/q/project:wikimedia/annualreport,n,z

From the redirect perspective, I'm not a hand of wikimedia -> wikipedia.

We shouldn't be crossing domains like that, If I visit a wikimedia domain, i expect to stay there not end up somewhere else (eg: wikipedia/wikispecies).

Also the annual report isn't wikipedia specific so it shouldn't in the wikipedia namespace. It will just end up yet another old outdated subdomain we will have to maintain in the future.

+1 on Peachey88. The WMF annual report has nothing to do with the wikipedia.org domain (or the 15. prefix, for that matter, as the fiscal year is only 50 % in that year).

Change 263562 merged by Dzahn:
redirect annual.wm.org to 15.wikipedia.org

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