Interaction design patch

From GIMP GUI Redesign
Revision as of 17:03, 3 June 2012 by Guiguru (talk)
Jump to: navigation, search

Before we get to the interaction design adaptation, here is the model we want to base it upon:

This is an objective description of an open source code contribution process, specifically for new, fresh contributors to the project. It is specific for the GIMP project.

  1. Process starts with the bug tracker. Either an existing bug is selected by the contributor, or one is specifically created by the contributor.
  2. Optionally, the contributor can already discuss the (prototype) contribution, or even just the path to make a contribution, with the maintainer(s) and other helpful developers via the usual channels (irc, mailing list, etc.).
  3. The contributor sets off the process by attaching the code contribution to the bug. There are quite a few (un)written requirements this contribution has to adhere to.
    The contribution,
    • has to be code, in patch form, that compiles in the GIMP build environment, in a (usually, head) branch of the repository;
    • has to solve the bug/problem/enhancement it is attached to, without creating more problems than it solves;
    • has to be complete, with no holes;
    • has to be sane, fit the technical architecture of GIMP, no breakage, no incompatibilities (libs, etc);
    • has to comply with coding standards and not weaken the code base (spaghetti code, etc);
    • cannot be platform (linux, windows, mac) specific, unless it addresses a platform specific problem;
    • has to be easy to review and apply by the maintainer(s);
    • does not have to be perfect; the maintainer(s) will help out with tips, guidance and instructions, and a tweak or two to the contribution (see below)—but to be clear: the contributor has to do the work to get the contribution into an acceptable state.
      (Some of these must look quite trivial to developers who are insiders to the project. But to new, fresh contributors who are outsiders, each one counts and could form a barrier of entry.)
  4. After the code contribution had been attached it can be publicly discussed, in the bug tracker, the developer mailing list and on irc.
  5. The next step is taken by the maintainer(s). Depending on how well the code contribution matches above requirements, the following happens:
    • if the patch simply matches the requirements, the maintainer(s) commit it to the code repository;
    • if the patch almost matches the requirements, the maintainer(s) may tweak it a bit, then commit it to the code repository;
    • if the patch does not match some of the requirements, the maintainer(s) communicate to the contributor which parts need improvement; it is up to the contributor to follow up on this and resubmit the patch (goto point 3);
    • if the patch nowhere near matches the requirements, the maintainer(s) reject it; they may comment the bug with some global direction that can guide potential contributors to submitting a more successful contribution.
  6. When the number of high quality contributions has become sufficiently high, the new contributor is granted access by the maintainer(s) to the code repository, to directly integrate contributions.