Interaction design patch
From GIMP GUI Redesign
Revision as of 15:53, 12 May 2012 by Guiguru (New page: This is a description of an open source code contribution process, specifically for new, fresh contributors to the project. It is specific for the GIMP project. # Process starts with the ...)
This is a description of an open source code contribution process, specifically for new, fresh contributors to the project. It is specific for the GIMP project.
- Process starts with the bug tracker. Either an existing bug is selected by the contributor, or one is specifically created by the contributor.
- 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.
- 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.
(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.)
- After the code contribution had been attached it can be publicly discussed, in the bug tracker, the developer mailing list and on irc.
- 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 2);
- 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.