Skip to content
Core Development
Setting up your developer environment
Contributing to the main website: www.gimp.org (and others)

Contributing to the main website: www.gimp.org (and others)

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 following the principles below.

This page is about the main website, often abbreviated WGO, which is the central point to get information about GIMP, but also applies to other websites.

Base website principles

The following four principles are universal to the GIMP project on the web:

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.

The simple content is usually written under prosodic, linear and segmented writting, which means that new contributions should respect the following rules by “osmosis” from start:

  1. Each sentence should be structured by coordinated or subbordinated clauses as much as possible, instead of quick sentences scattered over the paragraphs or the page. The less prose the sentences have, the more the chances of being too direct or obscure.

  2. Paragraphs should be linear in a way the reading flows over each paragraph while perceiving the connection between them. Hyperlinks to pages of the website are welcome. The less connection the paragraphs have, the more the chances of being redundant.

  3. The page should be segmented by hierarquical sections, which is a natural consequence of following the two rules above (take a look at this website, almost all pages have sections).

In other words, context matters. Do not just copy paste your personal local annotations into GIMP websites. Take a time reading the existing simple content to understand the grammar used and to confirm if what is already online really needs to be modified or expanded with your new content.

For WGO, 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

Other GIMP websites have other proeminent links. developer.gimp.org, for instance (as per original discussion between Robin Swift and Patdavid during the Hugo migration), takes into consideration:

  • How do I develop to GIMP? (Core Development)
  • How do I develop from GIMP? (Resource Development)
  • How to engage with the team? (Developer Conferences)

Basically, anyone landing on the main page should have no doubt what they are looking at and what they want.

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 WGO

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

Contributing to gimp-web-devel

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.

Last updated on
Building GIMP documentationGIMP Coding Style