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.
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.
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.
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).
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.
- 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)
- All software used for the implementation MUST be under a Free Software License
- The software repository MUST be REUSE compliant
- 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.
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.
- 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
- 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).
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.