Contributing to the main website: www.gimp.org

Table of Contents

GIMP community does not only need developers. We welcome all sorts of contributions: design, testing, bug triaging, translatorsā€¦ and of course website improvements!

Even the website you are reading right now can be contributed to, for instance to propose new developer tutorials or improving existing ones.

This page is about the main website, often abbreviated WGO, which is the central point to get information about GIMP.

Base website principles

Static content

As all GIMP websites, WGO is static-only, or to be more accurate server-side static. Indeed we don’t use any server-side dynamic language such as PHP or Python; our web server only serves pre-built HTML, CSS and Javascript files. This has the following advantages:

  • The website is much faster as our web server hosts and directly serves existing files. No on-the-fly compilation (or cache system), no database, no interpreter running.
  • The website is much safer. We can’t have any SQL injection (or any kind of code injection), private data leaking (nothing is private on our website).
  • Our website is saner and doesn’t require GDPR handling or cookie warnings: we don’t gather anyone’s private data, nor do we want to. There is simply nothing to warn about with a static website.

The only dynamic part of the website can be for Javascript, which we keep to a minimum. In particular, a very important rule is that the website should perfectly work without Javascript! For instance, we use JavaScript to redirect to a “thank you” page with some info and links after the “Download” button was clicked. With JS disabled, the download button would still work (only the redirection would not happen, that’s all).

Simple content format and separated from style

The content for the website is decoupled from the presentation layer. One method of doing this is to house all of the content in an easy-to-use plain text format such as Markdown (or some combination of Markdown + html).

A benefit of separating the content from the presentation layer is portability of the content. It becomes easier later on to re-adapt the content layer to a new presentation layer as needed. This also helps to lower the barrier to entry, as any given piece of content is a self-contained folder of plain-text markdown (or html), as well as the associated assets needed.

See more info at: https://gitlab.gnome.org/Infrastructure/gimp-web/-/blob/testing/README.md?ref_type=heads#content

Robust and direct main page

Here are a list of things that are the most important to users visiting the page (as per original discussion between Schumaml and Patdavid during the Pelican redesign):

  • The project name. Main branding: GIMP - The GNU Image Manipulation Program
  • How do I get it (Download)?
  • What is it (The Free & Open Source Image Editor)?
  • How do I use it (official docs and community tutorials)?
  • News
  • Get Involved
  • Donate

Basically, anyone landing on the main page should have no doubt what they are looking at, what the program is for, and how to get it.

Cool URIs don’t change

Try to keep the existing URL structure intact as much as possible. šŸ˜Ž Cool URIs don’t change!

  • The only way it might not be the same going forward could be due to removal of some pages that could be considered extraneous. For examplle, if we need to consolidate page information onto a single page as appropriate.
  • Even then, the pages should probably still exist to not break anything (just soft-remove them by no longer linking to them from anywhere). So, redirects should be used in that case.

All these principles are still true to this day.

Contributing to the website

Building the website to test locally

The README.md file in the repository is pretty clear on the process to quickly build it for local view, which makes it extra easy to contribute.

Technical improvements

Here are some technical concepts: https://gitlab.gnome.org/Infrastructure/gimp-web/-/blob/testing/devel-docs/to-do.md?ref_type=heads