[Gimp-developer] contribution processes...

["Crazy Aunt Gail's, LLC" <gail crazyauntgail com>]

In my opinion the language of the draft is not inviting to contribution. At minimum, each of the "has to"s should be changed to either "should"s or "should strive to"s. Also, it is unclear whether the final "does not have to be perfect" trumps any or all of the previous seven bullet points -- if it does not then the requirements are indeed exceedingly stringent.

Especially problematic is the sixth bullet. A contributor should not be expected to learn or have access to other platforms just so he can submit code; he should write his code to work on his development system and those with access to and familiarity with alternative deployments should be able to submit patches or propose changes to accommodate their systems. This suggests that the infrastructure to support contributor participation should be hierarchical in nature; i.e., each enhancement/bugfix should be treated as an openly developed "subproject" in which all are welcome to participate. 

I would propose something akin to the following:

A separate 'gimp-contrib' repository be created in which development of patches takes place. 

* A potential contributor submits a Bugzilla report outlining his issue and indicating that he/she is willing to work towards its resolution.

* Upon approval of the endeavor by the GIMP developers, the contributor is granted branching and commit privileges to the 'gimp-contrib' repository (if not already granted previously). This does NOT offer push privileges to the Gnome-hosted 'gimp' repository.

* The contributor solicits whatever support and aid for his project he/she can, through whatever channels he/she wishes. More significant aspects of the development should be inclusive of the official GIMP channels (mailing list, IRC, and the corresponding Bugzilla report), but smaller issues can be handled without interfering with the main project.

* They are responsible for keeping their branch in synch with the GNOME 'gimp' module (or 'gimp-help-2', 'gimp-web', 'gimp-data-extras', etc) and following the feedback provided by the GIMP developers and the input of GIMP UI design team. 

* Notably, contributors neither produce or submit patches; they focus on producing their code, incorporating suggestions, and persuading people to test it.

* When the contributor feels his project is in suitable shape for inclusion in GIMP, he/she requests that the GIMP developers merge his branch.


The process outlined above provides a solution that allows for distributed development that avails itself of the capabilities of GIT and scales to both the smallest and largest of 'subprojects'. 

Contributors' abilities to get their code incorporated would ultimately depend upon their ability to attract the support of the GIMP developers but, importantly, they are initially welcomed to participate in the project and can learn incrementally the process of contributing to a large, community-run codebase. 

The demand placed on GIMP developers to support this infrastructure should be less than the current method. Contributors are permitted to fail without interfering with mainline developme