Closed Bug 495800 Opened 16 years ago Closed 15 years ago

Have *.mozilla.org domains resolve to *.mozilla.com sites and vice versa with some exceptions

Categories

(mozilla.org :: Governance, task)

Product:
mozilla.org
Component:
Governance
Platform:
All
Other
Type:
task
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: davidwboswell, Assigned: davidwboswell)

Details

If there is a foo.mozilla.com site, the associated foo.mozilla.org address should send people to the site and vice versa (if there is a bar.mozilla.org site, the bar.mozilla.com address should work). For example, if someone goes to prism.mozilla.org they get an error page instead of the Prism information and there's no reason to lose that traffic. Same goes for air.mozilla.org and many other sites. There are some exceptions to this rule we'll obviously need to deal with (such as www.mozilla.com and www.mozilla.org being two separate sites) but the default for any site should be that you can get to it using either mozilla.com or mozilla.org.
Some of the other exceptions are staging sites for various production sites, but mostly everything should redirect to the relevant .org/.com site.
This is a dupe to a WONTFIX'd bug. Just need to find the bug #...
Assignee: server-ops → reed
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WONTFIX
You ain't gonna WONTFIX without a reason...
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Not worth the effort involved. Things differentiate between *.mozilla.com and *.mozilla.org all the time. MoCo vs. MoFo stuff.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → WONTFIX
(In reply to comment #4) > Not worth the effort involved. I disagree. I think it's definitely worth the effort from a product-point-of-view. > Things differentiate between *.mozilla.com and *.mozilla.org all the time. > MoCo vs. MoFo stuff. That's not the distinction that should be made. It's "product" vs "project". In this case, there are several projects that are general Mozilla projects and there's no reason they shouldn't be .org, but they were made .com. This bug isn't necessarily about *all* subdomains being both, just about *most* of them. Corporation-only things should clearly be .com-only (www.mozilla.com, kubla, staging sites, etc). Projects should be both.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
What _projects_ are you thinking of?
(In reply to comment #6) > What _projects_ are you thinking of? AirMozilla, Bespin, crash-stats, LizardFeeder, Headrush, Prism, for example. There's also no reason IRC, MDC, and other .orgs shouldn't work when using .com. They should forward to the applicable tld.
Assignee: reed → mrz
A couple of those you mentioned are Mozilla Labs which is clearly run by Mozilla Corporation. The plan there is to move them to mozillalabs.com too. Anyways, I feel like this discussion needs to happen at some larger level, not within this bug.
(In reply to comment #8) > A couple of those you mentioned are Mozilla Labs which is clearly run by > Mozilla Corporation. Sure, but that doesn't make them not part of the project at large, regardless of what party actually wrote them. Ubiquity, for example, has a bunch of outside contributors. Does it matter that "Mozilla Labs, a part of the Mozilla Corporation" made them? Why? And when you figure out why, how does that relate to the TLD we choose? > The plan there is to move them to mozillalabs.com too. Sure, that's fine. That's kind of unrelated though.
We've made a very deliberate distinction between the two, and I'd like to keep it - here is some of the background: * Mozilla.com - corporate or moco-only stuff. some examples are mpt-vpn.mozilla.com, blog.mozilla.com * Mozilla.org - anything public, project or otherwise related The reason the split is useful is a) to ensure each time we stand up a moco specific service, we think about if there is anyway we can make it public or project based b) remind people/admins that mozilla.com sites are corporate and usually internal. It's worked very well for us thus far and I don't see much reason to duplicate a bunch of host names. The segregation has been quite useful, and I think the benefits outweigh the minor annoyances a few users might have in changing .com to .org, or vice versa.
I think the circumstances that led to the decision mentioned in #10 have changed since this was last discussed. For instance, keeping a clear split between MoCo and MoFo is not the priority it once was and there's more of a drive now to present all of our efforts under a One Mozilla umbrella. Even with the criteria mentioned of keeping things separate between MoCo-only sites and public sites, the current application of this only leads to confusion. How can someone who doesn't know all of the intricate details of our organizational structure parse why our community support site is a .com but the community wiki site is a .org? It's certainly fine to move this discussion to another forum and bring more people in, but I don't think this bug should be wontfixed just because of the level of effort involved or because this has been discussed in the past.
> How can someone who doesn't know all of the intricate details of > our organizational structure parse why our community support site is a .com but > the community wiki site is a .org? Do they need to have that understanding to use the site? Why they also need to understand why Thunderbird support is under a wholly different domain? Do you have sites that -should- be under both mozilla.com and mozilla.org? This bug started as as a wholesale "make everything work" and I'm not convinced that's the right direction.
(In reply to comment #12) > Do you have sites that -should- be under both mozilla.com and mozilla.org? > This bug started as as a wholesale "make everything work" and I'm not convinced > that's the right direction. I agree here - it's worked quite well so far, so if there are some specific sites you think should be in both tld's, let's do that.
I think there are two things that are important: * How are we presenting ourselves to the world and telling our story? The names and URLs of our sites are part of that. * How can we avoid confusing people who just want to download Prism, for example? The bug started as a way to address that second item. There were reports that people were going to prism.mozilla.org trying to find Prism information. I think trying to go to that URL is an understandable action. I don't think the answer is to educate people about the fact that Prism falls under a corporate domain versus a community domain. I think the answer is to make sure that our sites are discoverable. For the first issue about how we present ourselves to the world, that is definitely a bigger issue than just this bug. The two are wrapped up though, so it's probably unavoidable to talk about both issues when trying to fix this specific issue.
(In reply to comment #10) > * Mozilla.com - corporate or moco-only stuff. some examples are > mpt-vpn.mozilla.com, blog.mozilla.com > * Mozilla.org - anything public, project or otherwise related This is all fine and dandy, but it's not what we're doing. At all. * Mozilla.com - Air Mozilla, Bespin, crash-stats, LizardFeeder, Labs, Prism, Support, Ubiquity. All "community" sites, all on mozilla.com (and yes, I know some of these are moving). * Mozilla.org - Icecast (only used for Mozilla Corp broadcasts). (All I could think of off the top of my head...) Even if it was what we're doing, I'm not sure it's the Right Thing for our large community. I shouldn't be expected to know that IRC resides on mozilla.org when Firefox is on mozilla.com. Or the community wiki. Or Air Mozilla broadcasts. We've blurred the line so much, in so many instances, that now it makes sense, from the perspective of our community, to make these things even more blurry so that people can easily find sites they're looking for. We've already done this for sites like AMO, Devmo, and People. Why not for others? To be clear: This bug isn't about internal sites that don't matter. Those can be "blah.pw" for all I care. If I can give a list of all sites we think should have both TLDs, is that reasonable?
(In reply to comment #15) > This is all fine and dandy, but it's not what we're doing. At all. Actually we are (or mean to): > * Mozilla.com - > Air Mozilla Probably a hack to get this up quickly - should be moved, I agree. > Bespin, LizardFeeder, Labs, Prism, Ubiquity All labs sites which were all in mozilla.com, but are moving to mozilla labs domain for just this reason. > Support Probably an oversight - should be moved. > * Mozilla.org - Icecast (only used for Mozilla Corp broadcasts). (All I could > think of off the top of my head...) This is used for not just corp stuff, but sure, could be moved. > Even if it was what we're doing, I'm not sure it's the Right Thing for our > large community. I shouldn't be expected to know that IRC resides on > mozilla.org when Firefox is on mozilla.com. Or the community wiki. Or Air > Mozilla broadcasts. Why? Should you not be expected to know that google is at google.com not google.org? They are separate for a reason, just as ours are. Furthermore, we want mozilla.net, which again would be for a totally different use. > We've blurred the line so much, in so many instances, that now it makes sense, > from the perspective of our community, to make these things even more blurry so > that people can easily find sites they're looking for. First I've ever heard of this complaint, so I don't know that it's a big issue. I agree we may not have stuck to this as rigidly as maybe we should have, but we can fix that going forward. > We've already done this for sites like AMO, Devmo, and People. Why not for > others? For specific sites, I think we are all in agreement we can. (btw, people should really be mozilla.com only, just as blog.m.c) > If I can give a list of all sites we think should have both TLDs, is that > reasonable? Sure, let's start there and work it down to something we can all agree on.
(In reply to comment #16) > > Support > > Probably an oversight - should be moved. Not an oversight. Purposely done, as SUMO is Firefox-only. Bug was filed for this already and was WONTFIX'd (in the sense that what was requested was not done but an alternative was done instead). http://support.mozilla.org now redirects to http://www.mozilla.org/support/, which is more appropriate.
It's worth noting that there's a difference between redirecting a domain and duplicating content under two domains. Having prism.mozilla.org display the Prism website might have incorrect and unwanted implications about what kind of project it is and who is responsible for it. Having that redirect to prism.mozilla.com just means "Hey, you made an understandable mistake typing the domain, let me help you." I really think the latter makes sense, at least for Prism and similar cases.
> Why? Should you not be expected to know that google is at google.com not > google.org? They are separate for a reason, just as ours are. Furthermore, > we want mozilla.net, which again would be for a totally different use. As Sam said in comment #5, the important distinction to make is not about organizations. See for example, the following posts that talk about why we should be focusing on community goals instead of on organizations. http://blog.lizardwrangler.com/2008/11/30/mozilla-foundation-and-2010-goals/ http://commonspace.wordpress.com/2008/12/07/one-mozilla/ The organizational structure should be transparent for people and we shouldn't require that people understand the complexities of our legal setup--which is a lot more complicated than just having one .org and one .com. For example, see the nine different community organizations listed at: http://www.mozilla.org/about/organizations.html
Re comment #17, SUMO is an interesting case because they've stated that they'd like to use their site for more than just Firefox support. When/if they start supporting other Mozilla projects that would clearly blur the line between things even more. Like AMO today which hosts add-ons for the Firefox and Thunderbird products as well as other community projects.
Did anyone come up with a list of sites that should resolve both ways (or 302 to the correct site)?
Component: Server Operations → Server Operations: Projects
We don't have a list yet, but we haven't forgotten about this so we'll try to get a list together soon.
For starters, here's a very short list of sites that should resolve both ways: prism.mozilla.* air.mozilla.* Sam and I will work on pulling together a bigger list.
Here's a longer list of sites that should work for both .com and .org addresses: air.mozilla.* bespin.mozilla.* crash-reports.mozilla.* crash-stats.mozilla.* creative.mozilla.* design-challenge.mozilla.* download-stats.mozilla.* feeds.mozilla.* jetpack.mozillalabs.* impactmozilla.* mozillalabs.* prism.mozilla.* ubiquity.mozilla.* I could make the list longer, but I think it will be easier to instead say which public facing Mozilla sites shouldn't have the .com and .org versions in sync.
> jetpack.mozillalabs.* > impactmozilla.* > mozillalabs.* Are you suggesting that we get mozillalabs.org and impactmozilla.org?
If we don't have those domains now, then it's fine to not worry about it at this point. I'd like to come up with a domain name policy though where any public facing site that uses 'Mozilla' works with a .org address.
What are the next steps for fixing the domain names mentioned in comment #24 (minus the mozillalabs and impactmozilla domains)?
Let's hit these: (we'll skip crash-reports.mozilla.com - it's only defined in-product) air.mozilla.* bespin.mozilla.* crash-stats.mozilla.* creative.mozilla.* design-challenge.mozilla.* download-stats.mozilla.* feeds.mozilla.* prism.mozilla.* ubiquity.mozilla.* Arzhel - these should be setup as redirects (not CNAMEs).
Assignee: mrz → ayounsi
Component: Server Operations: Projects → Server Operations
done for : air.mozilla.* bespin.mozilla.* crash-stats.mozilla.* creative.mozilla.* feeds.mozilla.* downloadstats.mozilla.* design-challenge.mozilla.* => already redirect to http://design-challenge.mozillalabs.com/ prism.mozilla.* => Shouldn't redirect to something.mozillalabs.com ? ubiquity.mozilla.* => same?
Calling done.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → FIXED
Reopening since this bug is about more than just those domains covered in comment #29. If this is more about a general policy discussion maybe it makes more sense in a different component, like governance?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Yes, I agree (as I did in comment #8).
Assignee: ayounsi → david
Moving this to Governance for now. We're going to be posting to mozilla.governance this week.
Component: Server Operations → Governance
QA Contact: mrz → governance
As an update, there is a thread in governance now about a proposal for a One Mozilla domain name strategy that is relevant to earlier discussions in this bug. http://groups.google.com/group/mozilla.governance/browse_thread/thread/7065e39ca7eb07dd# If that proposal is approved, I'll follow up here with next steps.
(planet.mozilla.com should redirect to planet.mozilla.org, not sure how we missed that before.)
Closing as wontfix. The original goal of this bug was to have foo.mozilla.com redirect to foo.mozilla.org and vice versa, but a new domain name strategy was just approved that has a different goal. The goal now is to move sites to sub-domains of mozilla.org (and set up redirects as needed). Since these are two different goals (although related) I thought it made sense to handle them in separate bugs. The new bug is bug 606278.
Status: REOPENED → RESOLVED
Closed: 16 years ago → 15 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.