El 12/05/12 13:46, peter sikking escribi:

I have given it a first stab:

I like to discuss it here on this mailing list and get it in a shape that is beyond reasonable doubt. after that the next steps can be taken.

Makes sense to me. With the spanish-speaking libre graphics community (graficalibre.org) we tried to figure out how to move the existing FLOSS development model to graphic design (specifically brand and identity) and we also found that a completely open and decentralized model wasn't up to the task, just as a completely closed and controlled wasn't either. So we refined the procedures until we got to a process which is pretty close to the one you're describing.
There has to be an "authority role" that has the final word about what's in and what's out, and that person (or a small team coordinated by that person) will define the guidelines of what is needed and the quality expected from contributions.
Contributors can assign themselves pending "tasks" and provide solutions following those guidelines and procedures, and the mantainer will evaluate the result, provide feedback and finally accept/reject the contribution.
So far it worked fine, and having someone saying what to do worked better than total freedom, because it's almost impossible to get direction from a large group of contributors without a leading role. Also it's easier to contributors to choose what to work on: they can just pick a task and focus on it without worrying too much about the big picture.
Some people might see this as something less "democratic", but if we choose the leading role based on previous track record and merit, we'll be chosing democratically our representative, and we can still have freedom to discuss decisions with people in charge, so there's no problem. Personally I think your work (and your team's) has proven the importance of having UI experts among our devs and I'll be happy to see you leading this new process, and I expect to see great things coming from it.

Gez.

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Sat, May 12, 2012 at 8:46 PM, peter sikking wrote:

guys,

lately I have been thinking about introducing a new process.

this thinking has been accelerated by the GIMP bof at the lgm, where GIMP project members expressed concern about lack of openness and transparency in the current UI redesign work, and I expressed concern about lack of valuation and respect for the field of interaction design.

the discussion at lgm was constructive, and I think that everybody should just act to address all of the concerns.

I think that the new process that I am thinking about can contribute to that.

this process is an interaction design patch/contribution for new, fresh contributors, that I want to model it one-to-one on the established code patch/contribution process (for new, fresh contributors).

so first we need a good description of this code contribution process, before adapting it.

I have given it a first stab:

I like to discuss it here on this mailing list and get it in a shape that is beyond reasonable doubt. after that the next steps can be taken.

"has to be easy to review and apply by the maintainer(s);" -- let's just call it Git formatted and made against a rebased clone of the master branch, shall we?

On the whole, I agree with this first stab and would like to move this description (once finished) to wiki.gimp.org :)

Let's see how interaction design part evolves.

Alexandre Prokoudine http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Hi,

I also read your stab. First of all, I'm a friend of acting ordered and high code quality, too.
Some thoughts of mine:
1. Yet I haven't found out whether this draft is for 'interaction design patches' (whatever this could mean) or for code patches at all. What exactly do you mean?
2. The sentence ' There are quite a few (un)written requirements this contribution has to adhere to.' is not necessary. Either the requirements count and thus are written or not. 3. I read 'for new contributors', so I feel addressed. But then there is a list of few requirements a newbie can hardly fulfill. In fact, they are important as they try to achieve high quality software. If I was in the shoes of the experienced GIMPs team I would have written the same. But really, as you noticed yourse lf: 'Each one counts and could form a barrier of entry'. IIRC GIMP development has a severe lack of developers. Why then build the barriers higher? Softening the aforementioned requirements with the line 'It has not to be perfect' is IMHO too less. However, after reading the stab my first thought was 'They expect perfect patches'. I suggest to add a line, that, where and when contributors can post and discuss their code for review, before it's finally contributed as a patch. There are many possibilities (mailing lists, IRC, wiki, mail, Bugzilla ...) - to the GIMP team these informations are clear, but not to new people. And of course, contributors questions wait for answers. Lately I tried to learn from the GSoC students questions and asked for answers in the mailing list (see
https://mail.gnome.org/archives/gimp-developer-list/2012-March/msg00193.html). I've got no answer yet for two months. So I went to IRC and tried to learn from the discussions there. The guys there are friendly, but yet I picked up some little pieces, which have yet to be merged to the big picture. This may take a while. I don't know whether everybody has enough patience.
Another dawn of hope is the GEGL porting matrix. AFAIK most of GIMP is ported to GEGL, but there are still some open 'easy to do' tasks - the best start for beginners. The matrix starts with the chapter 'How to port' - which is empty. How is a beginner supposed to port anything? It would also be helpful if somebody regularly concludes some discussions of general interest on IRC or the devlist and maintains an up-to-date list in the wiki.
Don't get me wrong: my lines may sound like beefing, but I'm meaning them constructive. What I'm trying to say is: for newbies it's hard to get grips. GIMP team, please, add some words in Peters stab where they find all necessary information to contribute on a single point (the wiki) and keep these sources complete and up-to-date. 4. What will happen to the GIMP UI brainstorm? Will it be replaced by this process? If not, how will a contributor there ever know whether his/her proposal is accepted or not? AFAIK proposals end in team reviews - and then? Getting this information lets him/her start to implement this proposal or avoid needless efforts.

Many lines for a Sunday morning... Grab a properly chilled beverage and enjoy ;-) and keep on your good work.

Best regards,

grafxuser

On 05/13/12 08:40, gfxuser wrote:

Hi,

I also read your stab. First of all, I'm a friend of acting ordered and high code quality, too.
Some thoughts of mine:
1. Yet I haven't found out whether this draft is for 'interaction design patches' (whatever this could mean) or for code patches at all. What exactly do you mean?
2. The sentence ' There are quite a few (un)written requirements this contribution has to adhere to.' is not necessary. Either the requirements count and thus are written or not. 3. I read 'for new contributors', so I feel addressed. But then there is a list of few requirements a newbie can hardly fulfill. In fact, they are important as they try to achieve high quality software. If I was in the shoes of the experienced GIMPs team I would have written the same. But really, as you noticed yourse lf: 'Each one counts and could form a barrier of entry'. IIRC GIMP development has a severe lack of developers. Why then build the barriers higher? Softening the aforementioned requirements with the line 'It has not to be perfect' is IMHO too less. However, after reading the stab my first thought was 'They expect perfect patches'. I suggest to add a line, that, where and when contributors can post and discuss their code for review, before it's finally contributed as a patch. There are many possibilities (mailing lists, IRC, wiki, mail, Bugzilla ...) - to the GIMP team these informations are clear, but not to new people. And of course, contributors questions wait for answers. Lately I tried to learn from the GSoC students questions and asked for answers in the mailing list (see
https://mail.gnome.org/archives/gimp-developer-list/2012-March/msg00193.html). I've got no answer yet for two months. So I went to IRC and tried to learn from the discussions there. The guys there are friendly, but yet I picked up some little pieces, which have yet to be merged to the big picture. This may take a while. I don't know whether everybody has enough patience.
Another dawn of hope is the GEGL porting matrix. AFAIK most of GIMP is ported to GEGL, but there are still some open 'easy to do' tasks - the best start for beginners. The matrix starts with the chapter 'How to port' - which is empty. How is a beginner supposed to port anything? It would also be helpful if somebody regularly concludes some discussions of general interest on IRC or the devlist and maintains an up-to-date list in the wiki.
Don't get me wrong: my lines may sound like beefing, but I'm meaning them constructive. What I'm trying to say is: for newbies it's hard to get grips. GIMP team, please, add some words in Peters stab where they find all necessary information to contribute on a single point (the wiki) and keep these sources complete and up-to-date. 4. What will happen to the GIMP UI brainstorm? Will it be replaced by this process? If not, how will a contributor there ever know whether his/her proposal is accepted or not? AFAIK proposals end in team reviews - and then? Getting this information lets him/her start to implement this proposal or avoid needless efforts.

Many lines for a Sunday morning... Grab a properly chilled beverage and enjoy ;-) and keep on your good work.

Best regards,

grafxuser

I agree with a lot of this. My impression on reading the 'first stab' was that is was more an attempt to stop people "interfering" than to encourage potential contributors to get involved in Gimp.

Indeed I found 'brainstorm' to be similar. It made it a lot of work to make a suggestion and , while a mockup can be a good means of presenting something in some cases, the requirement that the visual be the only acceptable form of submission and no verbal description was possible, again seems like raising barriers.

/gg

I agree with a lot of this. My impression on reading the 'first stab' was that is was more an attempt to stop people "interfering" than to encourage potential contributors to get involved in Gimp.

Indeed I found 'brainstorm' to be similar. It made it a lot of work to make a suggestion and , while a mockup can be a good means of presenting something in some cases, the requirement that the visual be the only acceptable form of submission and no verbal description was possible, again seems like raising barriers.

/gg

Hey there,

I'm working with Peter - and everyone else involved - more and more. Greetings to those who I met last week in Vienna! And to those I didn't.

Actually, I think the intention is the opposite. We want to set up a system that makes it easier for contribution and collaboration in the design part of GIMP work. We really don't want to be a closed shop. What Peter wrote is his attempt at looking at how the system for developers works, so we can see what we can learn from it. There is no prescribed process proposed as yet.

What we absolutely have to do is differentiate between user requests and design contributions, and one of the ways in which you can do that is by getting people to submit some sort of visual- even if it is a doodle and nowhere near a "mock-up". Anyone, even someone just starting out, or trying out designing, should be able to do that if they want to get properly involved. It's kind of the key tool of the trade...

(s)kate

On Sun, May 13, 2012 at 10:40 AM, gfxuser wrote:

Another dawn of hope is the GEGL porting matrix. AFAIK most of GIMP is ported to GEGL, but there are still some open 'easy to do' tasks - the best start for beginners. The matrix starts with the chapter 'How to port' - which is empty. How is a beginner supposed to port anything?

Empty? No, it says "Missing info. You can help filling it :)" Which means that...

It would also
be helpful if somebody regularly concludes some discussions of general interest on IRC or the devlist and maintains an up-to-date list in the wiki.

...is entirely possible, but requires someone to be around at all times. I will, of course, do my best, but cannot guarantee either 24/7/365 presence, or full understanding of all technical discussions.

Alexandre Prokoudine http://libregraphicsworld.org

Am 12.05.2012 18:46, schrieb peter sikking:

lately I have been thinking about introducing a new process.

Dear all,

some food for thought from the mozilla folks who have a proud track record of successful open design:

bugzilla keywords like 'uiwanted' may be useful. Complete list available here: https://bugzilla.mozilla.org/describekeywords.cgi

Open Design: Five Lessons http://www.azarask.in/blog/post/open-design-four-lessons/

Contributing to the Mozilla codebase: https://developer.mozilla.org/en/Introduction

best regards, yahvuu

Hi Alexandre,

On Sun, May 13, 2012 at 10:40 AM, gfxuser wrote:

Another dawn of hope is the GEGL porting matrix. AFAIK most of GIMP is ported to GEGL, but there are still some open 'easy to do' tasks - the best start for beginners. The matrix starts with the chapter 'How to port' - which is empty. How is a beginner supposed to port anything?

Empty? No, it says "Missing info. You can help filling it :)" Which means that...

This is the point. From a beginners point of view these two sentences mean just the same like an empty space. Is nobody there who knows more about porting to GEGL? Did all the code suddenly appear from nowhere?

It would also
be helpful if somebody regularly concludes some discussions of general interest on IRC or the devlist and maintains an up-to-date list in the wiki.

...is entirely possible, but requires someone to be around at all times. I will, of course, do my best, but cannot guarantee either 24/7/365 presence, or full understanding of all technical discussions.

I appreciate your efforts and wouldn't expect you to be around everywhere all the time. I thought of two things anybody can do: IRC: AFAIK discussions in IRC happen in the evening time (CET). If sometimes discussions about certain topics of general interest come up (like repeating questions, repeated pain with used libs, maybe some GSoC students questions, upcoming release dates) it would be useful if someone from the discussion could drop a short, meaningful note about the results in the wiki. If all these questions have already been answered in the wiki, then it's ok.
Devlist: as we currently see with your 'Wilber in the toolbar' thread, discussions can become very long. That's ok. As results grow within the discussion, it's later hard to find out a specific information quickly, if it's hidden underneath lots of postings. That's why a short summary at the end was useful. BTW this clarifies some questions for those who later implement something based upon this discussion.

Best regards,

grafxuser

I completed the "How to port" section in the wiki.

I have a suggestion, what about using a Git based wiki like Gollum ( https://github.com/github/gollum) to host the UI specifications ? This is the wiki system used on Github. It works the same as a classic wiki, but all the data are stored in a Git repository. It would allow: - Still easily usable by non-developers - Facilitate the interaction with the developer team, by having change on the wiki reported in real time in the IRC channel. - People can propose patch for the spec without need to have an account. - Gollum understand the Mediawiki syntax, so the migration should not be too difficult (I never used Gollum though) - UI designer can use website like http://www.ohloh.net/ to track their work and get a more visible recognition.

My 2 cents.

2012/5/13 peter sikking

yahvuu wrote:

some food for thought from the mozilla folks who have a proud track

record of successful open design:

I am not that familiar with the mozilla processes (although do I know the guys from the agency Silver Orange who are/were simply contracted to design mozilla software, all of it).

‘proud track record of successful open design’

that is quite a claim. anywhere visible on the net how that works?

I looked carefully at the 3 links you sent.

bugzilla keywords like 'uiwanted' may be useful. Complete list available

here:

https://bugzilla.mozilla.org/describekeywords.cgi

yes, already thinking how the new process will integrate with bugzilla is useful. however I want to avoid that things needing UI design become a blocking state in bugzilla.

Open Design: Five Lessons
http://www.azarask.in/blog/post/open-design-four-lessons/

I can only call this open design in this way: Sebastiaan de With designed a new logo for Ubiquity. he did this in the open. they got a lot of ideas and feedback. then Sebastiaan did all the heavy design work.

this is how interaction has been designed up to now in GIMP. for instance: save + export. in the open, loads of feedback (that made it significantly better) and I did all the heavy design work.

what I am trying now is to get beyond that. new, fresh contributors that can contribute a snippet (or more) of interaction design without demanding that they are actually interaction designers, or follow established interaction design processes.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

Michael

On 12.05.12 at 5:45 pm Michael Mur wrote:

I completed the "How to port" section in the wiki.

Great! Now it should be even easier.

Best regards,

grafxuser

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 05/13/2012 06:15 AM, peter sikking wrote:

yes, already thinking how the new process will integrate with bugzilla is useful. however I want to avoid that things needing UI design become a blocking state in bugzilla.

And if it's really a blocking issue it should show up where?

On Sun, May 13, 2012 at 7:45 PM, Michael Mur wrote:

I completed the "How to port" section in the wiki

Thanks a ton! :) I think we'll still need more technical info, but that's probably for another page.

The matrix also has to be enhanced, but I'll take care of that in a while.

I have a suggestion, what about using a Git based wiki like Gollum (https://github.com/github/gollum) to host the UI specifications ? This is the wiki system used on Github. It works the same as a classic wiki, but all the data are stored in a Git repository. It would allow: - Still easily usable by non-developers - Facilitate the interaction with the developer team, by having change on the wiki reported in real time in the IRC channel. - People can propose patch for the spec without need to have an account. - Gollum understand the Mediawiki syntax, so the migration should not be too difficult (I never used Gollumthough) - UI designer can use website likehttp://www.ohloh.net/ to track their work and get a more visible recognition.

I really have no special opinion on that. I am, however, concerned about "People can propose patch for the spec without need to have an account." -- that smells like a welcome sign to spammers. And that's, as far as I can tell, the only reason we have user registration by request at wiki.gimp.org and gui.gimp.org.

Alexandre Prokoudine http://libregraphicsworld.org

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

I really have no special opinion on that. I am, however, concerned about "People can propose patch for the spec without need to have an account." -- that smells like a welcome sign to spammers. And that's, as far as I can tell, the only reason we have user registration by request at wiki.gimp.org and gui.gimp.org.

No, that mean that since the wiki IS a Git repository, an alternate way of editing it is to clone this repository and do some commits. That way, people without registration can still work on it and propose a patch. No risk of spam because someone with a valid access still need to accept the changes.

Am 13.05.2012 15:15, schrieb peter sikking:

yahvuu wrote:

some food for thought from the mozilla folks who have a proud track record of successful open design:

I am not that familiar with the mozilla processes (although do I know the guys from the agency Silver Orange who are/were simply contracted to design mozilla software, all of it).

next time you meet these folks give them a good talking-to about the use of vertical space in thunderbird :->>

proud track record of successful open design

that is quite a claim. anywhere visible on the net how that works?

i'm mostly referring to the blogs of Alex Faaborg and Aza Raskin [1][2], plus some linked discussion strewn throughout the mozilla wikis. These two are not working for mozilla anymore, though.

I looked carefully at the 3 links you sent.

bugzilla keywords like 'uiwanted' may be useful. Complete list available here: https://bugzilla.mozilla.org/describekeywords.cgi

yes, already thinking how the new process will integrate with bugzilla is useful. however I want to avoid that things needing UI design become a blocking state in bugzilla.

to avoid blocking, the UI issues could be addressed by dedicated, additional bugs. If in turn some specific UI question is indeed blocking, it is probably a good thing to have that visible in bugzilla.

Open Design: Five Lessons
http://www.azarask.in/blog/post/open-design-four-lessons/

I can only call this open design in this way: Sebastiaan de With designed a new logo for Ubiquity. he did this in the open. they got a lot of ideas and feedback. then Sebastiaan did all the heavy design work.

this is how interaction has been designed up to now in GIMP. for instance: save + export. in the open, loads of feedback (that made it significantly better) and I did all the heavy design work.

IMHO the benevolent dictator (team) working in the open is just about the right approach for an open project. At least, community design has proven to be less successful for GIMP.

In that context, i'd like to highlight one particular challenge: How to embrace new developers whose contributions do not match the product vision? It is hard to bear for an open project that the traditional scratch-your-own-itch approach cannot be allowed in the UI domain.

The project has to cope with the fact that technical people generally are not aware of the value of interaction design, at least as of 2012. Moreover, it takes an eye-opener like "About Face 3" by Cooper to get a grasp that this is actually a field of its own. Personal intuition und common-sense reasoning is simply not enough to design proper interaction for GIMP.

The only constructive solution i can see for such conflict-prone contributions is to let them live and evolve as plugins/add-ons. If a capable coder is really burning to get the feedback from all of GIMP's huge user community, she might even be tricked into creating the required APIs.

what I am trying now is to get beyond that. new, fresh contributors that can contribute a snippet (or more) of interaction design without demanding that they are actually interaction designers, or follow established interaction design processes.

sounds fun! Something like Gnome-love bugs with guidance by the UI team?!?

best regards, yahvuu

[1] http://blog.mozilla.org/faaborg/ [2] http://www.azarask.in/blog/

gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

On Sat, May 12, 2012 at 6:46 PM, peter sikking wrote:

I have given it a first stab:

I like to discuss it here on this mailing list and get it in a shape that is beyond reasonable doubt. after that the next steps can be taken.

A final step that is missing in your list is: When the number of high quality easy to integrate contributions becomes sufficiently high, the new contirbutor should gain access to directly integrate contribution. With git and summer of code we very early ask for the students to get git access; that is to be able to have their own branch though; directly touching master without permission; though possible; is not encouraged.

/

The future is already here. It's just not very evenly distributed
                        -- William Gibson
_______________________________________________
gimp-developer-list mailing list
gimp-developer-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gimp-developer-list

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

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.

On Mon, Jun 4, 2012 at 3:33 AM, peter sikking said:

maybe this exactly demonstrates the sizeable gap there is between

the people that can, and do, contribute, and users and other observers. the points listed there are about minimum decent software engineering, thus to software engineers it is logical that they _have to_ be met, or else the codebase goes to hell.
to users and other observers, each one of these is a barrier of entry, and I find it good that that becomes clear to all parties. but to be able to contribute, one has to be able to meet the requirements, i.e. one has to be able to do the _work_ of software engineering. note that the shorter (less ambitious) the patch, the easier it is to meet the requirements.

I think it's fine to have requirements so long as they're clear and people know where to go when they want to contribute something.

People who are willing to go to the extent of contributing something probably care about Gimp or rely on it for something they do, so I think that if you have high requirements for this new contribution process we're discussing, perhaps have some sort of page that explains the requirements, and mention that if they don't meet it, they can always post their idea to the GUI brainstorm.

From a development standpoint, this helps keep the feedback channels open (and explaining contribution requirements for those channels keeps things constructive).

From a users perspective, when it comes to something they care about (such as Gimp), I feel they mostly want to:

- have some sense that they're being heard (things like a product vision, project updates, and lists of know issues or things that are being worked on can help with that)
- have an opportunity to contribute in some way if they have a good idea, and
- have a sense that their contributions are appreciated

Even if the specific ideas people share aren't that useful, I feel such contributions serve as helpful feedback--it's just a matter of that feedback going to the right place in the right format given the amount of people you have to process such feedback, and how desirous they are of wanting to process it.

If the scale of feedback you're getting is too much, you can always tweak the requirements and submission guidelines (regardless of whether they're submitting things to the contribution process, or to the UI brainstorm).

* * *

In terms of what a requirements page may look like, here's my version of a very basic draft:

If you have an idea for how the Gimp interface can be improved or , there are two ways you can contribute.

*Option 1* So long as you've read X, Y, and Z pages, you can create an entry via the contribution process web page [link].

*Option 2* If you don't want to do all of that, that's okay; you can still still mock-up your idea in the form of an image and submit it to the Gimp UI brainstorm. The instructions for how you can do it are in the right sidebar of all pages on the UI brainstorm. [link to UI brainstorm]

If you'd just like to talk to someone about your idea, you can visit the IRC channel [link] or send an email to the Gimp mailing list [link].

Or anther version:

*Do you have ideas for how the Gimp interface can be improved? * If so, you can create a mock-up of your idea in the form of an image and submit it to the Gimp UI brainstorm.

Once you do that the team that helps design Gimp's UI and works with the developers to help implement that design will review your (and other) submissions as a way to gather ideas and get insight into how people use Gimp and what features people would like.

For further instructions, visit the UI brainstorm website and read the instructions in the right sidebar. [link to UI brainstorm]

*Want to get more involved?* Gimp uses a Bugzilla process to keep track of UI projects that are currently in the process of being designed and discussed by the UI team and the Gimp community.

That said, in order to keep that process constructive and productive, you have to be familiar with some things before you can contribute in this way.

If you'd like to proceed, take a look at X, Y, and Z page.

Once you've done that, create an account over at Bugzilla [link] and then go to [link to the process for the UI development].

From there you can take a look at the list of current projects and contribute feedback and alternative designs to them, and you can also create a new project. [Note from Bruce: I'm not sure what criteria you'll have for new projects, so I was vague in that last part.]

Those are just some examples.

On Mon, Jun 4, 2012 at 3:33 AM, peter sikking wrote:

let's pick up this discussion again, sorry for the delay.

Saul Goode wrote:

In my opinion the language of the draft is not very inviting to

contribution.

the draft is a _description_ of the current code process, not a manual/invitation page for new contributors. it describes how things are in the code world, so I can derive an interaction design process from it, that is just as open as the code process.

At minimum, each of the "has to"s should be changed to either "should"s

or "should strive to"s.

maybe this exactly demonstrates the sizeable gap there is between the people that can, and do, contribute, and users and other observers. the points listed there are about minimum decent software engineering, thus to software engineers it is logical that they _have to_ be met, or else the codebase goes to hell.

to users and other observers, each one of these is a barrier of entry, and I find it good that that becomes clear to all parties. but to be able to contribute, one has to be able to meet the requirements, i.e. one has to be able to do the _work_ of software engineering.

note that the shorter (less ambitious) the patch, the easier it is to meet the requirements.

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.

I have refined that point now in the wiki.

Especially problematic is the sixth bullet.

just sticking with the libs that GIMP normally uses and not start using platform-specific ones, and not use platform-specific compiler features goes a long way towards writing non-platform-specific patches.

it is again about simply decent software engineering.

[I snipped the rest because it was about changing the code patch workflow, which is not what I intent to achive.]

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list