[Board] Barn raising: osgeo.org web site

[Jeff McKenna]

Hi Ian,

Thanks for proposing this.  I agree, we need a "not invented here"
approach, to make this possible.  It is sure time for this upgrade.  I
have added your proposal to the next board meeting agenda, Ian could you
also attend that IRC meeting, to help guide this topic?  See the exact
time at the top of this page:
https://wiki.osgeo.org/wiki/Board_Meeting_2015-12-10

I would also like to see this plan (including the nodes transferred) on
the OSGeo wiki.  Could you also start drafting these plans on the OSGeo
wiki, and share that link with everyone?

One big part of this upgrade is the Service Providers page
(http://www.osgeo.org/search_profile), which I believe is made up on
custom PHP.  Please include your plans for this in the wiki (or a section
on the wiki for this so we can get proposals/ideas for how to improve this
search tool.

We will of course need to work closely with the SAC committee on this, and
we can share these wiki plans with them, for their approval.

Thanks again for pushing this.

-jeff


> Hi All,
>
> With the recent release of Drupal 8, I'd like to suggest we hold a barn
> raising event for recreating and re-hosting the main osgeo.org website.
>
> Why continue with Drupal?
>
> - We need a proven CMS that is easy for all users and doesn't require lots
> of work to maintain.
> -Drupal 8 was developed to put multilingual capabilities first, a core
> requirement for OSGeo.
> - v8 includes responsive themes designed for mobiles and tablets and is
> engineered to be fast by default.
> - Unlike the OSGeo projects, we need a "not invented here" approach to the
> website where we aim to write little or no code ourselves.
>
> How?
>
> - The current site has around 1600 nodes.  If, for example, 16 people took
> responsibility for 100 nodes each we could manually copy content without
> worrying about automating the migration... therefore no risk of
> transferring anything that's not public, or of copying across old embedded
> PHP code.
> - A shared google spreadsheet would record which nodes had been
> transferred. We'd transfer newer nodes first and *create the correct links
> among the translated content*.
> - The sponsor pages could be created as a custom content type and
> displayed
> using built-in drupal views, allowing sorting, searching etc without any
> custom PHP.
> - SAC could install a vanilla Drupal 8 on a new server and get inital LDAP
> support working. Webcom would take responsibility for content, theming
> etc.
> and discussions via the webcom mailing list.
> - The board would decide when to transfer to new site.
>
> Principals
> - Avoid writing any custom code (which has prevented upgrades in the past)
> - Install minimal contributor modules, ensure any that are used are likely
> to be maintained long term, e.g. ldap
> <https://www.drupal.org/project/ldap>
> module.
>
> Is this something that could be discussed at the next board meeting?
>
> Ian
>
> P.S. The following link provides a good summary of features in Drupal 8:
>
> https://www.acquia.com/sites/default/files/library/attachment/ultimate-guide-drupal-8v3.pdf