Hi,
Sven Neumann wrote:
Dave Neary <dneary@xxxxxxx> writes:What does the structure buy us? It gives people a point of access to contact if they have suggestions, bugs, questions. It allows people who want to get code included to contact someone directly for code review.
I think our policy is to encourage people to use bugzilla and the
mailing-lists, and not to contact developers directly.
Do you mean is, or should be? I agree that that is the current policy, but disagree that things should be like that. Mailing lists and bugzilla are for the most parts an excessively high barrier to entry for people not already in the community. The quantity of mail we're talking about is not huge either - just because a name is on a website somewhere does not mean that all of a sudden they're going to get slashdotted by 10000 mails a day.
... in most cases I ask people to use the public channels. I believe that this policy is a good thing.
I believe we should be much more flexible about how we use those public channels, too... for example, someone recently reported a bug on a mailing list. The bug was confirmed on the mailing list, and the fix was trivial. In spite of that he was asked to create the bug on bugzilla so that it would be fixed in the next release, which probably meant taking 5 more minutes than he had already taken to create a bugzilla account. That was, imho, unnecessary.
Similarly, someone complained about the interface to another feature in bugzilla, claiming that there was no way to do task X, and that this was a bug. He was asked to contact the user list if he didn't know how to do task X. Again, this was IMHO excessive - especially given that the feature in question is pretty well hidden, and currently undocumented.
In the same way, private e-mails are often a lot less intimidating than mailing to a public list which is often not very welcoming (there are countless examples of people understandably not knowing about stuff getting told off for not doing their homework on the lists). For example, the person who is currently the most active contributor to gimp-help-2 has never sent a mail to the list, because he's not particularly technical, and he doesn't feel comfortable mailing the list.
Private e-mail is a much nicer way to get involved, particularly if you manage to talk to someone who listens to you and encourages you. I sent my first patches to Daniel Egger, because his name appeared pretty often in the changelog at the time. Daniel was very nice, pointed out where I could improve my patches, committed them for me, and at a certain point pointed me towards the lists and towards mitch when the patches got a bit bigger. In short, Daniel made it easier for me to contribute.
If I send a patch to the list, it's actually sending it to no-one. Same thing with a bugzilla report. No-one is responsible, no-one says "I can't help you with this - but person X might". There is no way to know whether a patch will get applied, acknowledged or whatever. Plus, I need to sign up for a list where I might get another 100 mails a month to add on top of the 2 or 300 I already get if I'm a free software developer.
I'm not saying that we should actively encourage people to send mail directly to developers, I'm saying that we shouldn't actively *discourage* avenues of communication. If someone contacts me personally with a question (which happens more and more frequently), I reply to the question as best I can. I'm reasonably pleasant, polite and friendly. If I can't help them personally, I might add someone better placed to help as a CC. Or I might reccommend that they ask the list. But if I can help, I do. Sure, there might be some gem of wisdom lost to the mail archives, but the chances are that the GIMP has made a new friend, someone who'll go away and say that the GIMP guys are really nice and approachable.
If instead I say "I can answer your question, but first you have to sign up to a mailing list and ask your question there", they're more likely to go away thinking that the GIMP guys are kind of uptight, maybe they'd consider that rude, perhaps they might even go away saying that the GIMP developers are arseholes. Bear in mind that this has very little to do with the fact that you're being polite or impolite. They're asking for help, and you're insisting that they conform to an artificial structure which makes them go out of their way to get help.
If we ask people to contact developers directly, we rely on these developers being responsive at all times (which they cannot be, they might be busy or on vacation).
We wouldn't be asking people to contact developers directly. We'd be not asking them not to. And no-one expects an individual to be any more responsive to personal mail than normal. It's not a duty call, there is no-one holding a gun to anyone's head. You're simply opening up the possibility of another, friendlier way of getting involved in the GIMP.
We would encourage off-list discussions and those bear the risk that imporant ideas are lost because the right people don't hear about them. It also means that these discussions are not archived and generally not accessible by the rest of the crew.
Most of the discussions that would happen off list would be patches sent to people "in charge" of modules, for comments and/or committal. Those get into CVS, so everyone sees them. Other than that, it's likely to be requests for clarification on stuff, or general help questions. Those should probably be in a FAQ for easy access, but they're certainly not going to take away from the archives.
Of course, if you're talking about design decisions, those should eventually happen on-list. But there's a certain value in 2 or 3 people getting together to flesh out ideas and come up with a coherent proposition before going to the list. In fact, often times, starting technical discussions on the list can be a disaster because you invariably end up getting stuck in the nitty-gritty of the detail.
That said, I agree with you in large part. As it is, a large number of important decisions get made excusively on IRC (which was designed to be a very friendly way for people to get real-time advice - unfortunately, we've lost that reputation). This isn't particularly healthy, and probably needs to change. When the first thing people hear about important stuff is a mail saying "we have decided" or "everyone knew about this for ages..." then that's not an open decision process. We need to make sure that all strategic and design decisions pass through the list for comments before being definitive.
It puts names and faces on the organisation for magazines, articles, interviews, presentations.Is that desirable? Wouldn't it be nicer if we could show the world that GIMP is a collaborative effort?
I agree that we need to communicate better and that in particular the web-site should be improved. But I would rather like to emphasize the team aspect than to put names on the official GIMP site.
Teams need leaders and roles. The German football team doesn't walk out on the pitch wondering who the captain is, who decides where people are playing, or who goes in goal. Even when people play sport for pleasure, there are captains, positions, goalies, subs - teams work better when people know where they fit in the team. And why shouldn't we celebrate some of the individual contributions to the GIMP?
Generally, people get more pleasure out of something where they have a sense of purpose, a sense of having a job to do. I'm not saying that we carve up the project and set things in stone, I'm suggesting that we have a number of figureheads who decide what happens for part of a project, so that the project as a whole can have some structure. As things are, we're like a bunch of headless chickens, and there are certain parts of the code that no-one touches because they're considered the property of others (for example, the text tool, pygimp, anything to do with tools, anything to do with GimpImage) - the problem is that the others don't identify themselves as the owners of the code, so nothing gets done, since there's no plan. We need a plan.
I can draw up a plan, but since I'm far from the best coder in the project, and I don't have any more time than I'm currently spending, the plan would be meaningless unless 3 or 4 key people agree with it. So we need structure, we need a plan, and we need someone who supports the plan to help make it a reality and organise what people do in the project according to priorities, talents, schedules and so on. If we don't do something like that, we're doomed to continue developing in all directions like headless chickens without ever getting closer to the goal (colorspaces + profiles + bitdepth + DAGs + everything else).
Cheers, Dave.
-- Dave Neary bolsh@xxxxxxxx
