Congrats to gnome team for picking Plone.  Before they start down the road of a implementation -- I would like to put my 2c.  This is only one way to use the Plone CMS.  Many people do not follow this approach, i.e. plone.org.  But I believe if you have limited Plone expertise and you want people to change the public website very easily in the future it might make some sense.

    These suggestions revolve around open/free software that our company built -- the principles are what really matter -- and I dont have 1st hand experience with similiar Plone/Zope tools.  But all software is open and can easily be read/modified/abused to do whatever you want -- hooray FOSS.  This is certainly not the path of least resistance.  But it formalizes the use and expectations of the Plone CMS is a reasonable fashion.

    Seperate the content management and content delivery.  You can do this both logically (staging, skin switching, etc) and physically (cmfdeployment, entransit).  So lets stick with the simplest which is keeping everything inside of the Zope application server and database.

    All of the 'content editing' can happen in Plone with minimal customization, which is good.  The further you get away from 'out of the box' in the way of UI and editing environment.  You are bound to feel pain in the future as Plone UI templates change.  And the reason people pick Plone is the base authoring environment is decent.  We separate it out by having two containers: 'public and 'authoring'.  The 'public' container is where all the content is staged to and the 'authoring' container is where all content edits, workflow, and sophisticated collaboration occurs.

    There is a great tutorial that explains this technique written by Martin Aspelli (UK) titled,  Creating public websites with staging and custom skins NOTE: I can not say Martin would vouch for this approach he only wrote the doc.

    The 'public' user interface (gnome.org) will change much more frequently and can be changed indepedently of the 'authoring' user interface.  The public interface is where the gnome.org skin will be applied and where all the presentation logic can be isolated.  You want the 'public' site to have the least amount of logic and features as possible.  You *do not* want the Plone skin.  You want the 'gnome.org' skin to be displayed for the 'public' website.

    In my experience the website will evolve/change frequently over time while changes and enhancements to the CMS (Plone) will become less frequent. Also isolating your modifications into at least two sets of modules, 'authoring' enhancements and 'website' themes/views/etc.  Since the website software will be touched frequently and often -- use z3 views and have nothing complex in the templates.  Tres Seaver wrote something called 'PushPage' would sounds ideal -- only variables (functions, classes, values) explicitly exposed to the template can be used in presentation.  This guarantee's the templates remain as clean and explicit as possible.

    Also as a side effect you can adjust database/caching parameters better between authoring and public containers.  Oh and hardware: nothing less than 2GB of RAM and dual 3GHz.  Use LDAP.  If you want to use a external search engine it's easier to add it to the public interface -- I recommend Xapian.  Especially if your 'public' container gets notifications that content is being added its a snap to notify xapian or other systems of updates (deletes, edits, etc).

    Hope you guys have a good experience.  (Un)fortunately there are many ways to deploy a Plone CMS.  It really depends on the skill sets and isolating the complexities of the system so that future developers enhancing gnome.org can focus 100% on the 'public' website and minimize exposure to the 'authoring' environment.  Keep in touch.