Talk:Website:Planning For Transition

Ian

• Sounds great to me, Max. For moving support, development, and community to the wiki, do you propose that we keep the same tree and do a more or less literal port, or that we restructure the information in those documents as we move it to the wiki? Froodian 00:23, 25 July 2006 (PDT)
  • We'll probably want to restructure it a bit. But those are merely details. We'll have to slowly work on a restructuring plan as we go forward. Maxr 11:56, 25 July 2006 (PDT)

Smokey

• Some concerns:
  • We need to keep Support (and at least part of Development & Community) unified in appearance with the "rest" of cb.o; that's one of the strong points of the current system (and the visuals are great)
    • This will be possible with the new theme design for the overall site. It will have an overall unified look. Maxr 11:56, 25 July 2006 (PDT)
  • We use a lot of sophisticated HTML+CSS in Support, some of which is not possible to replicate with MediaWiki easily, and some of which is not possible to replicate at all
    • I'm less concerned with this. The overall design of those pages should be changed a bit to fit a more unified look. We'll also be using quite a few MediaWiki "templates" which will allow more efficient editing (no more editing the style attribute). Maxr 11:56, 25 July 2006 (PDT)
  • We have a massive number of user accounts on the wiki, and we don't want *all* of them to be able to update Support or parts of Development; not having to go through cvs/Sam/Max to get pages updated will be great, but we also have problem contributors on the wiki who should not be able to update public-facing pages
    • This isn't a concern at all. We'll create a few groups, such as "support" and "development", put only "trusted" users into them, and allow those users to edit the pages. MediaWiki allows this. Maxr 11:56, 25 July 2006 (PDT)
  • Most of the content on the wiki currently doesn't need to be public-facing; it's a planning/discussion area (with the exceptions of some dev-related stuff we do want to make public-facing once we get it cleaned up/stabilized); we need some way to keep people from happening into the less-polished pages where we do real work/planning/etc.
    • I don't have a solid answer for this, except to say that the "Development" stuff should be public anyway. As the path of Camino is being decided, there's no reason others can't join in with comments. It shouldn't be very prominent, but it should be visible somewhere. Release notes and the like are the same way, I think (there's no reason people can't know what's landed). Maxr 11:56, 25 July 2006 (PDT)
• Questions:
  • How easy/hard does tracking the changes to the English site become for l10n teams in this new system?
    • It should be fairly easy, if not a *lot* easier given the ability to see the History of any page. Maxr 11:56, 25 July 2006 (PDT)
  • What about staging before going live in the new system?
    • We'll still stage the main content, which will still be handled by CVS, just not content on the wiki. This is really just moving to a more "Devmo" style of site. Maxr 11:56, 25 July 2006 (PDT)

ATM, I really think I'd prefer moving a more limited set of content to the wiki than envisioned in this plan. --sardisson 05:27, 25 July 2006 (PDT)

We basically decided on irc the other night to scale back the move; Support will be staying on cb.o —sardisson 00:44, 4 August 2006 (PDT)

• Plan for moving Development to the wiki (content-wise) is (roughly) Website:Development, with some initial work taking place in Development:Contributor Overview and Development:Building.

• New question for maxr: can we get something like devmo/wikimo has where bug links automatically change state when the bug is fixed (querying bugzilla somehow)? It'd make updating some of our internal pages easier.

Ludo

• Why get a new domain for the planet stuff Why not jut implement planet.caminobrowser.org ? --Ludo Jul 28 18:32:58 CEST 2006
  • It's more logical to have a new domain so that the style of the site can differ. It can make sense to have it as a subdomain, but ideally subdomains will maintain the same look, feel, and style of the main site. Moving the planet offsite allows us to change it. Maxr 19:46, 28 July 2006 (PDT)
    • It's not because you need to maintain that new domain - I don't mind having a different style for a subdomain. But maintaining a new domain just for a an aggregator is too much. You need to renew the domain. Specially if you have new themes for each component (as stated in the last entry of the discussion) --Ludo jul 29 07:54:18 CEST 2006
      • Renewing domains is hardly an issue. The last item on the non-talk page says that there will be a new "theme" for all Camino Project-controlled sites. That theme should be as exact as possible on all subdomains but can differ for other domains. I'm not completely sure what you're saying, but all "components" will have the same look and feel, with the exception of planet. Planets hardly ever look the same as their parent websites. Maxr 18:44, 30 July 2006 (PDT)
        • Renewing a domain is a issue when the person who registered it drops out of the project. Since there is no formal association behind Camino this is bad. I wouldn't object for domains if the domain issues would be handeled not by an individual but say the Mozilla Foundation. Since you are saying that most planets are not consistant with the sites associated with them why should we be different and have a specail domain. --Ludo Jul 31 12:37:49 DFT 2006
          • Renewing domains will be as much of an issue as hosting is now. So you're not objecting to a new domain, you're objecting to cb.o being hosted by an individual instead of by MoFo. This is another conversation and is off-topic for this proposal. Maxr 13:06, 31 July 2006 (PDT)

• Blogging software ? Which one do you intend to use ? What backend database would you like to use ? --Ludo jul 29 08:03:34 CEST 2006
  • This is really irrelevant and hasn't even been decided. We'll probably use whichever blogging software themes easiest and whichever backend database works best with said blogging software (I'd guess MySQL since that's what's used for the wiki). But again, this is a detail not relevant to the overall plan. Maxr 18:44, 30 July 2006 (PDT)

• Translated websites issues you did not state. I think having nl.cbo, jp.cbo just plainly sucks, the user does not need to know the URLs it needs to get content based on the header it's web browser sends. So I say we should use Apache's language feature (if the hosting is going to be done through Apache), which works easily, have index.html and index.html.jp for japanese in the same directory, Apache will serve the .jp file when the browser says it prefers japanese over say english. This would make the site a lot more maintainable - it would not get rid of issues like translations being completely out of date, but I think user wise it would be a lot better. --Ludo jul 29 08:07:54 CEST 2006
  • It would actually make the site a lot _less_ maintainable. We discussed this and considered it, but it's not reasonable to give CVS access to the root directory for each localizer. Giving them access to their own subdomain allows them to treat their pages separate. (For example: Maybe the jp team needs to explain what "Download" in Japanese means but no other language does.) Having verbatim localizations, which is what index.LC.html should be (where LC = language code), isn't the best idea for our teams. It's much better for them to have their own "playgrounds", so to speak, giving them the ability to take the main site where they need to go. I also dislike using the accept-languages stuff since it can get fubared and requires manually fixing. Maxr 18:44, 30 July 2006 (PDT)
    • I disagree on that one. Camino's goal is to serve the users. Camino's website is there to serves the users as well. Hence users should not need to know about subdomains just to have content delivered in their languages - just because it's easiers to maintian for sysadmins. Sysadmins are here to serve - not the contrary. I agree on the playground, but stage should be the playground. I do agree that localizing means adapting, but adaptaing can be done in the same canvas - no need to have special pages depending on languages. --Ludo Mon Jul 31 12:42:37 DFT 2006
      • Either way, there will be "special pages" depending on languages. If a l10n team were to "disappear", we can easily redirect a subdomain to the main, English domain. If we use the Apache accept-language idea, we'd have to remove that file from CVS so users won't be redirected there. That's less than ideal. In addition, I know of very few large sites that employ this technique. Most use subdomains or subdirectories (such as, Mozilla Europe). Maxr 13:06, 31 July 2006 (PDT)