Re: [Gimp-developer] Project structure
On Mar 9, 2004, at 10:46 pm, Roman Joost wrote: If the gimp-help-2 team has nothing against this, it'll be okey for me to be published on the site. Certainly fine with me. Servus, Daniel PGP.sig Description: This is a digitally signed message part
[Gimp-developer] Project structure
Hi all, I sent this yesterday to gimp-devel but I used the scam.xcf.berkeley.org server, which seems to be still having problems. Re-sending it. I'm also eaving gegldev in the CC, just to keep a common thread for cross-posts. === The major problem that this project has at the moment is its lack of structure. There are no bosses, no maintainers, no active developers (this is a point where I agree with Robin Rowe). I'd like to propose that the following roles be defined and published on the site (if it ever gets updated). Maintainer: Sven Neumann Module owners: Vectors: Simon Budig Core: Sven or Mitch perl bindings: Seth Burgess Python bindings: ? PDB/libgimp: ? Plug-ins: ? (stick with plugin-maintainers?) GAP: Wolfgang Hofer Help: Roman Joost GEGL nodes: Calvin Williamson GEGL data: Dan Rogers I've deliberately left out some obvious modules (web, because it seems that this is now dead, for example). 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. It puts names and faces on the organisation for magazines, articles, interviews, presentations. It also obliges people who already have a certain amount of authority and responsibility in the project to assume that responsibility, rather than shirking it by saying that everyone's voice has the same weight. This is clearly not true. I don't expect any of the names to be particularly controversial. This is a request for comments, though - so comment away. Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Project structure
Hi, Dave Neary [EMAIL PROTECTED] 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. I for one do generally not accepct any private GIMP-related mails. This doesn't mean that I ignore them but in most cases I ask people to use the public channels. I believe that this policy is a good thing. 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 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. 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. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Project structure
Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] 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 1 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.
Re: [Gimp-developer] Project structure
Hi, Sven Neumann wrote: It is a very common policy for a lot of projects that all bugs must be reported in Bugzilla. Some projects even go so far that you must not commit anything w/o refering to a bug-report. I don't think we need to go that far but I think that it is important that bugs are entered in Bugzilla. If someone reports a bug and the bug is confirmed on the mailing list, it's a 30 second job to enter it into Bugzilla if you know bugzilla and have an account. I think that it would be nice for us to accept bug reports via that channel, and then create the bug in bugzilla when it's been confirmed (for example). So far every bug reporter who was asked to use Bugzilla has managed to create a bugzilla account and has entered his/her bug there. A couple of times I have had to nurse people through a bugzilla account creation and how to create a bug. Bugzilla's interface sucks (at least the version we use), so I imagine that lots of other potential contributers don't bother getting over that barrier. If bugs are mentioned on a mailing-list or (worse) in private email it is very likely that they will be forgotten. Not if we put them in bugzilla. 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, That is simply not true. If you file a bug-report against GIMP, you usually get a respone in less than a day. The problem is entered into a database for later reference and a bunch of people immidiately get to know about it and can comment on it. While some people spend a lot of time on bugzilla, and every report gets commented on, it's hardly a formalised process for getting code into CVS. I stand by the point that when you send mail to a mailing list or attach an attachment to a bug in bugzilla, no-one is responsible for it. I haven't yet seen anyone who didn't subscribe to the lists and asked there. What you get is another happy user of the mailing list that might soon start to answer questions of other users or become otherwise involved. I've seen quite a few people who haven't gone on to the lists. I think that you're being idealistic to think that everyone you direct towards the lists will sign up and join in. Usually there is a certain amount of benefit you have to get back to first sign up to the lists. Once you're signed up, sure, you might end up an active contributor. 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. Do you have an example to keep up this argument? From my experience it is void. There have been several occasions when people on the user list, or on IRC, or on the devel list, have said that they resented having to sign up to bugzilla to report a bug. There have been several occasions similarly that people have been a bit annoyed on IRC at being asked/told to sign up to mailing lists. That's probably the worst thing that could happen. I can live with the idea of people discussing development in private emails but patches hiding in private inboxes instead of being attached to Bugzilla is what can kill an open source project. The patches shouldn't rest there, but they should arrive at the person best able to handle them. If needs be, they should be attached to a bugzilla report afterwards. Again, I'm not saying that we insist that things happen this way, just saying that we shouldn't forbid people from getting into the project via a kind of mentor relationship. But I don't think we should encourage people to address developers directly. The web-site should have clear and easy instructions on how to get in contact with the GIMP developers, not how to get in contact with individual module owners. Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better. Also, we have tried every so often to keep a list of module owners. All you get is a list of names that is outdated before you finished to put it on online. Have a look at PLUGIN_MAINTAINERS. Do you really want to publish this? The responsibilities and interest of GIMP developers are changing, new people coming, other people retiring. Any attempt to track is futile. It's hard to keep track of things like the owner of the gif plug-in, say - sure. But there needs to be some hierarchy. There needs to be someone in charge to co-ordinate things. That someone should know at any given moment who's best able to handle a particular problem, or who's the best person to bounce ideas off about some functionality or other. Only because the German football team does it, we don't have to do it that way, do we? No, but we should. If every team in existence has a leader, it's because that's a decent way to get the team working well together. I
Re: [Gimp-developer] Project structure
Hi, Dave Neary [EMAIL PROTECTED] writes: If someone reports a bug and the bug is confirmed on the mailing list, it's a 30 second job to enter it into Bugzilla if you know bugzilla and have an account. I think that it would be nice for us to accept bug reports via that channel, and then create the bug in bugzilla when it's been confirmed (for example). Now this turns into something we can easily aggree on. Simply because that's how it is handled already. So we will continue to encourage people to use Bugzilla and if they don't do it themselves, we put the bug into Bugzilla for them. This is good since over the last year we put a lot of work into establishing a reasonably well-working way of handling bug-reports. We cut our response-time to bug-reports down to a few hours and we cut the number of bugs down to about a third of what we had a year ago. This is definitely a success and I don't see a reason to change anything about that. A couple of times I have had to nurse people through a bugzilla account creation and how to create a bug. Bugzilla's interface sucks (at least the version we use), so I imagine that lots of other potential contributers don't bother getting over that barrier. Face it, if someone is not even willing to create a bugzilla account, he/she is hardly a potential contributor. So please continue to put other people's bug-reports into bugzilla (although this is a bad thing in general since it makes it impossible to get in contact with the bug reporter and ask for more details). Preferably though, nurse people through creating a bugzilla account. That is a very much appreciated effort and noone said you shouldn't do that. If bugs are mentioned on a mailing-list or (worse) in private email it is very likely that they will be forgotten. Not if we put them in bugzilla. See my comment above. It is important to have the bug reporter create the bug-report herself. Of course if you can reproduce the problem, it is less of an issue but in general it is important. While some people spend a lot of time on bugzilla, and every report gets commented on, it's hardly a formalised process for getting code into CVS. I stand by the point that when you send mail to a mailing list or attach an attachment to a bug in bugzilla, no-one is responsible for it. I don't see why it should be that way. What's wrong about using bugzilla for patches? It seems to work extraordinary well. If you want to see the mess that resulted from how it was handled earlier, please have a look at ftp://ftp.gimp.org/pub/gimp/patches/. Believe me or not, but I think getting patches into The GIMP has never been easier than today. That doesn't mean that it could not be improved but IMO bugzilla is the way to go. The patches shouldn't rest there, but they should arrive at the person best able to handle them. If needs be, they should be attached to a bugzilla report afterwards. Again, I'm not saying that we insist that things happen this way, just saying that we shouldn't forbid people from getting into the project via a kind of mentor relationship. I completely aggree with the last sentence. We have never forbidden this and we should certainly not do that. But I would still like to encourage people to put their patches into bugzilla. We have lost substantial work on disk crashes. This wouldn't have happened if people had put their work into Bugzilla (or CVS for that matter). But I don't think we should encourage people to address developers directly. The web-site should have clear and easy instructions on how to get in contact with the GIMP developers, not how to get in contact with individual module owners. Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better. If you want to go through the hassle of maintaining such a list, so shall it be. It would probably not hurt as much as I am afraid it would. there's no plan. We need a plan. There is no plan? I think we have a very decent plan. What is it? I published a set of dates, and a set of funtionalities, for 2.2 recently, and it was out of the question that we use dates (even though we ended up using rough dates anyway), and the list of functionality doesn't exactly constitute a plan. Our plan is 1. Release GIMP 2.0 2. Release GIMP 2.2 3. Get gegl ready 4. ... 5. Profit!!! OK, if the goal of all this is Profit, then I am leaving you here. But I take it that you are kidding... Anyway, we have made a plan on last GimpCon. This rough roadmap is published on developer.gimp.org. It is a rough outline w/o much technical details but I think we all have an idea where we want to go and how to get there. I agree that someone could write this stuff down and I would certainly be willing to help with that. On the other hand, experience has shown that it is very difficult to make detailed plans for the distant
Re: [Gimp-developer] Project structure
Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: I don't see why it should be that way. What's wrong about using bugzilla for patches? Nothing wrong with it, but bugzilla sucks for bigger patches or features, where CVS directly is better. But then CVS sucks for co-ordinating work (by which I mean, making sure that people communicate effectively while working on some job), whereas mail works nicely for that. It seems to work extraordinary well. If you want to see the mess that resulted from how it was handled earlier, please have a look at ftp://ftp.gimp.org/pub/gimp/patches/. I'm not advocating going back to an upload directory... I completely aggree with the last sentence. We have never forbidden this and we should certainly not do that. But I would still like to encourage people to put their patches into bugzilla. We have lost substantial work on disk crashes. This wouldn't have happened if people had put their work into Bugzilla (or CVS for that matter). The encouraging needs to be done the right way. Something along the lines of thanks for your contribution. This time, I'll create a bugzilla bug for you and attach your work so that it gets looked at. Next time, you might like to try this yourself - if you have any problems don't hesitate to mail me is good. Something like Patches are handled through bugzilla. You should create a bug related to your patch, and attach it there is bad. I'm just saying we need to be flexible, and hand-hold new contributers. There are an awful lot of communication channels in the GIMP (this was talked about last Summer) - it can be daunting for a new contributor even if all of them do a job, and are very good at that job. Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better. If you want to go through the hassle of maintaining such a list, so shall it be. It would probably not hurt as much as I am afraid it would. I don't think it would be a hassle once the modules are sufficiently grained. The problem is the names to put on the modules. I'll maintain this if I know who to send it to for the website. Our plan is 1. Release GIMP 2.0 2. Release GIMP 2.2 3. Get gegl ready 4. ... 5. Profit!!! OK, if the goal of all this is Profit, then I am leaving you here. But I take it that you are kidding... I take it you've never heard about the underpants gnomes. Anyway, we have made a plan on last GimpCon. This rough roadmap is published on developer.gimp.org. It is a rough outline w/o much technical details but I think we all have an idea where we want to go and how to get there. OK - the roadmap we laid out for ourselves last GIMPCon is somewhat out of date now, but it had 3 main points - 2.0 before Christmas, 6 month cycle to 2.2, integrate gegl between 2.2 and 3.0, with 3.0 in the first half of 2005. The problem is we've overshot the first part by 3 months (no-one's to blame for this, but it's a fact), mainly because we let the feature freeze slip by over 2 months. We have had a 3 month pre-release cycle, which is what was anticipated at the time. That means that the entire plan needs to be revised. Not only that, but the discussion we started on the gegl list about how we go about getting gegl into the GIMP, as well as what needs to be done on gegl between now and next Summer, needs to finish. It will finish when there's a decision about what we do. We should have this discussion over the next couple of weeks, as soon as 2.0 is out. I agree that someone could write this stuff down and I would certainly be willing to help with that. On the other hand, experience has shown that it is very difficult to make detailed plans for the distant future. Technical decisions need to be made when the time has come to go into the technical details. We're not talking about the distant future, though. In about a week we're going to start development on 2.2 without really having a clear plan about what's going into it. There were a couple of mails a few weeks ago, and there is a fairly long list of features in that list, but we don't really have a 2.2 target feature list, prioritized sop that we can cut features if they don't get started or finished in time. And then in the meantime gegl needs to get to a state where we can use it. So we need to figure out now how we're going to use it so that the gegl guys can work towards that. That means planning now how we're going to integrate gegl in 6 months time, and what features we get from that, and what we need to add in terms of interface to use those features. Let me give an example. You cannot sit here and attempt to decide what CMS we should use until someone sits down, evaluates them and starts to hack on CMS integration for GIMP. Of course we could decide today that it needs to be lcms. But what would that yield? By the time that someone wants
Re: [Gimp-developer] Project structure
I would be willing to maintain the module maintainers list as well as any other lists relating to who to contact about this or that. On Tue, 2004-03-09 at 14:23, David Neary wrote: Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: I don't see why it should be that way. What's wrong about using bugzilla for patches? Nothing wrong with it, but bugzilla sucks for bigger patches or features, where CVS directly is better. But then CVS sucks for co-ordinating work (by which I mean, making sure that people communicate effectively while working on some job), whereas mail works nicely for that. It seems to work extraordinary well. If you want to see the mess that resulted from how it was handled earlier, please have a look at ftp://ftp.gimp.org/pub/gimp/patches/. I'm not advocating going back to an upload directory... I completely aggree with the last sentence. We have never forbidden this and we should certainly not do that. But I would still like to encourage people to put their patches into bugzilla. We have lost substantial work on disk crashes. This wouldn't have happened if people had put their work into Bugzilla (or CVS for that matter). The encouraging needs to be done the right way. Something along the lines of thanks for your contribution. This time, I'll create a bugzilla bug for you and attach your work so that it gets looked at. Next time, you might like to try this yourself - if you have any problems don't hesitate to mail me is good. Something like Patches are handled through bugzilla. You should create a bug related to your patch, and attach it there is bad. I'm just saying we need to be flexible, and hand-hold new contributers. There are an awful lot of communication channels in the GIMP (this was talked about last Summer) - it can be daunting for a new contributor even if all of them do a job, and are very good at that job. Fair enough - but the web site should have a list of module owners - if only so that the developers know who they need to convince, or who can help them make their code better. If you want to go through the hassle of maintaining such a list, so shall it be. It would probably not hurt as much as I am afraid it would. I don't think it would be a hassle once the modules are sufficiently grained. The problem is the names to put on the modules. I'll maintain this if I know who to send it to for the website. Our plan is 1. Release GIMP 2.0 2. Release GIMP 2.2 3. Get gegl ready 4. ... 5. Profit!!! OK, if the goal of all this is Profit, then I am leaving you here. But I take it that you are kidding... I take it you've never heard about the underpants gnomes. Anyway, we have made a plan on last GimpCon. This rough roadmap is published on developer.gimp.org. It is a rough outline w/o much technical details but I think we all have an idea where we want to go and how to get there. OK - the roadmap we laid out for ourselves last GIMPCon is somewhat out of date now, but it had 3 main points - 2.0 before Christmas, 6 month cycle to 2.2, integrate gegl between 2.2 and 3.0, with 3.0 in the first half of 2005. The problem is we've overshot the first part by 3 months (no-one's to blame for this, but it's a fact), mainly because we let the feature freeze slip by over 2 months. We have had a 3 month pre-release cycle, which is what was anticipated at the time. That means that the entire plan needs to be revised. Not only that, but the discussion we started on the gegl list about how we go about getting gegl into the GIMP, as well as what needs to be done on gegl between now and next Summer, needs to finish. It will finish when there's a decision about what we do. We should have this discussion over the next couple of weeks, as soon as 2.0 is out. I agree that someone could write this stuff down and I would certainly be willing to help with that. On the other hand, experience has shown that it is very difficult to make detailed plans for the distant future. Technical decisions need to be made when the time has come to go into the technical details. We're not talking about the distant future, though. In about a week we're going to start development on 2.2 without really having a clear plan about what's going into it. There were a couple of mails a few weeks ago, and there is a fairly long list of features in that list, but we don't really have a 2.2 target feature list, prioritized sop that we can cut features if they don't get started or finished in time. And then in the meantime gegl needs to get to a state where we can use it. So we need to figure out now how we're going to use it so that the gegl guys can work towards that. That means planning now how we're going to integrate gegl in 6 months time, and what features we get from that, and what we need to add in terms of interface to use those features. Let me give an example. You cannot sit here and attempt to decide what CMS we should use until someone sits
Re: [Gimp-developer] Project structure
On Tue, Mar 09, 2004 at 09:29:02AM +0100, Dave Neary wrote: I'd like to propose that the following roles be defined and published on the site (if it ever gets updated). Help: Roman Joost If the gimp-help-2 team has nothing against this, it'll be okey for me to be published on the site. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
