[Gimp-developer] contribution processes...

[Saul Goode <saul crazyauntgail com>]

I apologize for the double-post; my mail system barfed and apparently sent a draft version of my post. Here is a more refined version.

In my opinion the language of the draft is not very 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 a "centralized, distributed" approach akin to the following:

A separate 'gimp-contrib' repository be created in which development of larger enhancements and more involved bugfixes takes place. Smaller bugfixes and enhancements could still employ the process of submitting patches through Bugzilla. 

* 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 much interference with the main project.

* Contributors 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 expected to be less than the current method of contributors creating their own local branches and then submitting patches upon every changeset. 

Contributors are permitted to fail without interfering with mainline development (the amount of imposition allowed fully determined by the individual members of the GIMP team) while maintaining a historical record that will hopefully be more complete and easily examined than the current approach. The bar to being granted access to this 'gimp-contrib' repository can be rather low, and even "speculative" enhancements or bugfix approaches can be afforded their chance to flourish. 

Hopefully, there would eventually evolve greater participation in GIMP development amongst these contributors that would engender sharing of experiences and practices which, even if the end result is never fully incorporated, will prove educational and beneficial to the contributors, to the GIMP project, and to Free Software in general.