• Events

• LocalGroups

• Activities

• Teams

• KnowHow

• RecentChanges

This document tries to outline the requirements for a review of the FSFEs website, planned to happen in 2018. It outlines some of the thinking that has gone into this, but it also forms the outline for a tender which would be published to ask individuals or companies to make bids with proposals for how they would suggest to help the FSFE reach the vision of our website, and what this would cost the organisation.

Vision

The FSFEs website is our window to the world, a showcase of our activities and the entrypoint for anyone wanting to learn more about our activities, support us, or volunteer time to our cause. We do not expect everything to be published on our website: individual projects and activities may present their activities elsewhere (on the FSFE wiki, on a separate website, or other), but everything the FSFE does, from local activities to global actions, should be easily findable through the website.

Our website should be easy to translate, keep updated, and be available in as many languages as possible to allow people of different backgrounds to access information about our work in their local language. Being a translator is often the first volunteer job someone has in the FSFE, and supporting the translators in this work is important for our retention of volunteers.

We would prefer to build our website on tools which are readily available and which require little or no coding to implement for us. This makes maintenance easier and ensures the FSFE avoids lock-in to individual vendors. That whichever solution is used should be Free Software goes without saying.

Why we're doing this

Our website has been built, since our founding (with a rewrite in 2016-17), using an intricate build system relying on XSL transformations for website design and source documents in XML format. It is currently functional but relies on expert knowledge to maintain when it breaks. It only has limited tools in place to support our translators in their work, and it's become clear that it's also sometimes difficult for everyone to work with XML files, and we would favour other formats like Markdown for updating content.

We do not rule out the possibility that some of this work can be accomplished by rewriting, adapting or complementing our existing tool, but proposals which include building on our existing tool should take into account long term maintenance and provide reasonable indications the FSFE would be able to procure the necessary competency for maintaining the website from several different vendors in the future.

Tenders

To support this work, we may create three or more tenders, a rough indication of which follows.

• Tender 1: Website design and structure. Based on our identity document and graphical profile, we would ask for help with reviewing our current website structure, lead the organisation through the process of developing a new structure to meet our vision, and come up with a graphical design to match that structure.

• Tender 2: Develop our website according to the requirements outlined below; the technical solution which will support the layout and structure, implementing the design, and migrating existing content to it.

• Tender 3: (Possibly) Support services for website maintenance.

Requirements

These are our overall requirements for our website. Some of this would be managed separately of the tenders above, and would be work the organisation needs to do itself. These are marked with the tag (OWN).

Design requirements

• The website MUST NOT rely on the use of JavaScript. We COULD allow the use of JavaScript to facilitate some functions, but if someone has turned off JavaScript, it should degrade easily and the website MUST still be fully functional.

Technical requirements

We try to not include too many technical requirements, as we believe it must be up to those who actually know the technology to make the determination of what best meet our vision. However, there are a few topics which are particularly important to us.

• The website MUST be self-hosted on our own infrastructure.
• The website MUST be able to handle a huge amount of visits in a short time frame.
• To the extent the website design has external dependencies, such as on Bootstrap, jQuery or other libraries, these MUST be served from us too. We do not want to subject our visitors to downloading required dependencies from external CDNs or websites.
• The website MAY be implemented with a static website generator (such as Hugo, Jekyll) which we have some preference for.

• It SHOULD be easy and straight forward to add custom URLs and mappings, for instance fsfe.org/join -> https://my.fsfe.org/

• It MUST be possible to import information from secondary systems into the website, to build parts of it, and such imports should be possible to do automatically on a regular basis (hourly, daily, etc)

Legal requirements

• All software used for the implementation MUST be under a Free Software License
• The software repository MUST be REUSE compliant

Data format

• Website pages MUST be easy to author in Markdown format
• Website pages COULD be supported in our existing XML format too, if this simplifies migration.

Migrations

• We don't try to migrate every single document. We copy historical content to a separate archive, and do not aim to include it on a new website. (OWN)

• Newsletters, press releases and other news entries MUST be migrated to the new website.
• The TOP (most hits + most translations) XY articles and project pages MUST be migrated to the new website
• Our event section /events MUST be migrated to the new website.
• Current URLs MUST be retained for at least six months, even if content moves to different URLs

Translations

• It SHOULD be easy for volunteers to contribute translations to the website and this should not require expert knowledge (like using command line tools) and it SHOULD be possible to do translations without the need to install additional software on the translator's computer.
• The website MUST have status pages for translations which show clearly which translations are outdated, and which have not been translated yet.
  • There should be a way to manage outdated translations in a way that they are no more shown but visible to a possible translator. The goal that a user for example does not see a 2 year old Italian page instead of the totally rewritten and mulitple times updated English version. On the other hand, translators should be aware of the 2 year old existing translation to prevent them from translating same stuff again.
• The translation status page SHOULD allow some weighting and configuration, such that we can implement rules which say some pages have a higher priority to translate than others (for example, we would like to say that news items not yet published are very important to translate, but static project pages which haven't changed for two years probably less so).

• The website MUST support browser negotiation for language, such that links of the form https://fsfe.org/about/funds/funds serve webpages in the preferred language of the browser.

• The website MUST support the user to switch language, regardless of browser preferred language, and when the user switch to another language, further navigation on the website MUST keep to the same language until the user changes.

  • This is currently implemented in the way that if you view https://fsfe.org/about/funds/funds.sv.html, then all links on that website are automatically rewritten to lead to the .sv.html versions of the pages, but if you switch to funds.en.html, the links then instead lead to the en.html version of the pages, so you always stay in the language you've selected.

• The website MUST show the English version of a page by default if the (automatically) selected language version isn't available. However, all links still have to consider the chosen language (manually be the user, or by browser negotiation).

Integrations

• The website SHOULD be built and deployed from a Git repository in our own Gitea server

• It MAY use our Drone installation.

CGI Scripts (OWN)

The current website makes use of a number of CGI scripts to perform certain functions. Most notably this is the case for our Expense Request system, Event Submissions and our Webshop. We envision that in the process, we would have to migrate these to other services such that they are no longer part of the website itself.

For instance, our webshop might then move to a self-hosted, simple, e-commerce solution, which would mimic the style of the FSFE website, but for all intents and purposes be run separately.

Editing part

I did not know where to put that, but wanted to make sure we do not forget about them.

• It MUST be possible to time the publication of news items
• It MUST be possible to time the publication of articles
• It SHOULD be possible to define social media messages, which are automatically send to gnu social, twitter, ... when a news item is published
• It SHOULD scale images which are uploaded in high quality, so the high quality picture is linked, but in the article a scaled version is used.
• Easy way to make standardised captions for pictures

Misc Points to be transferred to relevant sections

• There MUST be easy ways to share news and other pages on the website.
• News items and Articles shared should use a picture present on this page to include in the social media post
• There MUST be a way to have a website wide campaign promotion, so defined campaigns / fundraisers are promoted on all pages.
• We should not forget about the feature to order items, and an easy way to keep the numbers of material up to date without expert knowledge (maybe even a way to import a spreadsheet of the material, and then it is updated on the website)
• CSS MUST work on devices with different screen sizes (mobile friendly)
• CSS should have a good print version, so it is easy for people to print out articles and distribute them
• The website should enable testing for how people become new contributors, new supporters, new donors.
• It needs to be possible to include progress bar for fundraising for certain projects, or the general one.
• There SHOULD be a unified way to build web forms and receive data from them
• here MAY be a unified way to display maps (world, europe, etc)