Re: [Gimp-developer] contribution processes...

[peter sikking <peter mmiworks net>]

gfxuser wrote:

> 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?

as it says at the top of that page:

“Before we get to the interaction design adaptation, here is the
model we want to base it upon:
“This is a description of an open source code contribution process,
specifically for new, fresh contributors to the project.”

so it is all about code for this moment.

it is an objective observation how code contribution works in open source,
for about 2 decades now.

> 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.

again, it is just my observation. a lot of these requirements cannot
be found in the HACKING file, but are simply in play in the process.

> 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?

yes, to contribute code one has to be able to write decent code.
that is the summary of the requirements.

how hard this is scales with the number of lines of code that
the patch contains. one-liners are easier.

> 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'.

it does not have to be perfect. that is why that line is there.
maintainer(s) help fresh contributors to get to the point where
a patch is a contribution.

but they help only to a point. the contributor has to do the work,
not just give an impulse in the form of an idea and hope maintainer(s)
or core contributors take over and finish the patch.

> 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.

I would need confirmation from maintainer(s) or core contributors
that there is such an opportunity (for new, fresh contributors) before
a patch is attached in bugzilla.

I cannot write the rules for code, only observe them.

> 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.

I think Alexandre was planning on just that (see his mail).

> 4. What will happen to the GIMP UI brainstorm? Will it be replaced by this process?

the brainstorm will not be replaced. a brainstorm is a brainstorm.
there is no right or wrong (works vs not works) in a brainstorm,
only more and more ideas. these ideas are used as input in
interaction design processes (when the related area gets worked on).

everybody can contribute to a brainstorm, because the requirement of
decent interaction design (very similar to decent code, see above) is
not there. the wilder and more far-from-reality the idea, the better,
because this triggers innovation jumps that get us into the future
of GIMP UI, instead of tinkering with the status quo.

> 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.


the team reviews (which need a shot in the arm to get moving again) are
a way to highlight things were learned and found remarkable in the
brainstorming ideas.

there is no such thing as ‘accepted or not’ for brainstorming,
because that would be again reductive analysis (as done in a
certain phase of interaction design) and that would
destroy the ‘anything goes’ spirit of brainstorming.

    --ps

        founder + principal interaction architect
            man + machine interface works

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