Documentation:RoadmapIdeas

From GIMP Developer Wiki
Jump to: navigation, search

Current Roadmap Ideas

The ideas were collaboratively gathered on: https://gimphelp.etherpad.mozilla.org/1?


Future Opportunities

Content

  • Improve the Git branching model:

Currently documenters, who want to document a bugfix or feature of the next minor or major version only can commit to master. This has either the disadvantage to interfere with bugfix commits for the current release or to wait for the next release. If we're unlucky and the contributor isn't there or can't remember anymore at time of the next release, somebody else will have to find out everything with much effort or the help stays uncomplete. This would GIMP code contributors enable to write documentation as long as their knowledge about it is wet and let them do their work decoupled from other activities. Thus the documentation could be more complete and up-to-date.

  • Add a public glossary for UI, documentation and translation to ensure the same things/activities are titled with the same words and translations.
  • Add a common image repository for samples to make the documentation consistent.
  • Separate contents for various target audiences (photographers, web designers, digital artists, scientists etc.) to better address their needs. This could for instance be
    1. subchapters for each audience in each chapter (i.e. 'Edge detection filter' -> General information: this filter detects edges ... For photographers: use parameters x,y to achieve satisfying results. For scientists: description of the underlying algorithms) or
    2. one chapter per audience ("GIMP for Photographers') and subchapters with specialized activities ('Adjusting tonal values', 'Cropping', etc.)

System

  • We could move to a wiki based solution. The opportunities here are:
    • lower the barrier for new contributors
    • we don't need to create releases and continous update of the work in progress state on docs.gimp.org
    • would allow us to documentation our process better as we had with wiki.gimp.org
    • move documentation currently maintained on http://www.gimp.org into the wiki as well so we can keep them consistent
  • The solution need to be carefully evaluated. It needs to provide all technicallities I've described above. Furthermore a seemless import of the current content needs to be possible.
  • Move the GIMP help browser to a faster browser engine, i.e. Blink, to address the performance goal of the product vision.


  • In GIMP use *.ui files for as much as possible UI and generate or update the documentation from it (by XSLT). This way we'd ensure that always all widgets in dialogs etc. are documented or known to be documented (mark new widgets with TODO in the documentation).
  • Add possibilities to rate topics, easily contribute little improvements and micro-donate to well written documentation (Flattr, etc.)


Contributor Impact

  • Move the manual to github.com in order to leverage the better integration with fork/merge to get more contributors.
  • Alternatively add a CI system (Jenkins) + Code review (for instance Gerrit etc.) This probably has to happen on a bigger scale (e.g. the whole GIMP project or GNOME). With this, reviewing patches is still technical, but much easier than what we currently have.