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

[Bruce <speakwithbruce gmail com>]

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 <peter mmiworks net> 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