Closed Bug 676620 Opened 13 years ago Closed 11 years ago

[tracking] Make plans for what to do with Calendar pages after the mozilla.org/.com merge

Categories

(Calendar :: Website, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: davidwboswell, Unassigned)

References

()

Details

With the upcoming www.mozilla.org/.com merge there will need to be some changes to the Calendar pages. Possible options include: * Keeping them where they are and migrating them to the new Python-based platform. This will require additional maintenance effort related to increased security-requirements on the merged site. * Moving them into the mozilla.org/thunderbird pages if this is something that the Thunderbird team wants to promote. * Moving all of the pages to a new Calendar site that can be hosted by Mozilla. This is what happened with the SeaMonkey pages. * Redirect traffic to the AMO page and link to other content from there that can be moved to the wiki or Thunderbird support site. For instance, AMO would serve downloads and show screenshots and then there could be links to the FAQ that is hosted somewhere else.
As we'll be mark tasks blocking this bug, marking it as tracking bug.
Summary: Make plans for what to do with Calendar pages after the mozilla.org/.com merge → [tracking] Make plans for what to do with Calendar pages after the mozilla.org/.com merge
Depends on: 676640
Just wanted to follow up on this. Any thoughts about the plan for the Calendar pages? Would be good to have a plan set out by the end of the month.
Tobias, do you have time to put up a plan here during your work time? David, could you give us a short overview of what kind of security requirements we'd have to fulfill for option 1? Roland, how feasible do you think option 2 is? Personally I'd like to have in a way that mozilla.org theme changes also affect calendar, since we don't have the resources to update theming on the site. I guess this is closest to option 1.
> David, could you give us a short overview of what kind of security > requirements we'd have to fulfill for option 1? This page has information about the Secure Coding Guidelines the security team uses. https://wiki.mozilla.org/WebAppSec/Secure_Coding_Guidelines
(In reply to Philipp Kewisch [:Fallen] from comment #3) > Tobias, do you have time to put up a plan here during your work time? > > David, could you give us a short overview of what kind of security > requirements we'd have to fulfill for option 1? > > Roland, how feasible do you think option 2 is? > by option 2 you mean (please number options in the future :-) !): "* Moving them into the mozilla.org/thunderbird pages if this is something that the Thunderbird team wants to promote."i.e. support.mozilla.org/thunderbird is that what you mean? I have no problems with this if the pages are user facing docs and Lightning is going to be supported by Mozilla (i.e. JB and Standard8 approve) . More technical stuff belongs elsewhere e.g. developer stuff should be on MDN. Hope that helps.
(In reply to David Boswell from comment #4) > This page has information about the Secure Coding Guidelines the security > team uses. So iiuc then there is a python-based platform that takes care of most things (like setting the right headers, session cookies, etc) and we would only have to plug in our content and make sure our content complies to those security measures? In that case it should be fine, we don't have any login forms or fancy stuff. We don't even really care about sessions. We might have to check if our javascript is all in separate files to comply to the CSP stuff. (In reply to Roland Tanglao :rolandtanglao from comment #5) > by option 2 you mean (please number options in the future :-) !): "* Moving > them into the mozilla.org/thunderbird pages if this is something that the > Thunderbird team wants to promote."i.e. support.mozilla.org/thunderbird is Yes, I meant that option. But this is rather about the core calendar pages (i.e release notes, where to download, project description, team members, etc). Support stuff is mostly on gsfn/newsgroups/etc, outside of our main webpages. > that what you mean? I have no problems with this if the pages are user > facing docs and Lightning is going to be supported by Mozilla (i.e. JB and > Standard8 approve) . More technical stuff belongs elsewhere e.g. developer > stuff should be on MDN. Hope that helps. Adding Standard8 and jb to the loop, maybe one of you could let us know how tightly you'd like to integrate Lightning's pages into Thunderbird or if you'd rather see it on its own. Personally I think its ok to have it on its own (following option "python based platform") as long as there isn't a large increase on maintenance.
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
Component: General → Project Tracking
OS: Mac OS X → All
Hardware: x86 → All
Hi Sancus, Philipp, and Roland- Any additional thoughts on where the calendar pages should live now? We hope to finish this work by the end of June 2013. Thanks, Jen
/projects/calendar/ section of mozilla.org gets on average ~3,500 page views per day.
Ideally, the site will be overhauled and moved to bedrock in bug 723267. Feel free to dupe this bug against that one if you don't need this one for tracking. If there is anything you can do to bug 723267 to make it progress faster please do :-)
Depends on: 723267
Assignee: tobbi.bugs → nobody
Component: Project Tracking → Website
Product: www.mozilla.org → Calendar
Depends on: 952429
Depends on: 974168
The new page is now live in bedrock, and all old URLs are redirected to it.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.