Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
On Fri, 23 Apr 2004 10:03:49 -0300, "Joao S. O. Bueno" <[EMAIL PROTECTED]> wrote: > On Friday 23 April 2004 08:10, Sven Neumann wrote: > > Raphaël Quinet <[EMAIL PROTECTED]> writes: > > > Currently, I think that having a look at the ChangeLog is the best way > > > (although cumbersome) to figure out who is working on what. > > > [...] Some time ago, I wrote a script that parses > > > the GIMP ChangeLog files and tries to figure out who are the most > > > active developers. Maybe I should try to hack it a bit more. > > > > That sounds like something that should be done using the CVS > > information, not by parsing the ChangeLog. Perhaps have a look at > > statcvs, a CVS Repository statistic analysis tool. > > Would not that turn up just those who have CVS access? > Maybe a mix of both. Yes, and that's why I wrote the program parse_gimp_changelogs.pl in 2002. It scans the ChangeLog file(s) and for each entry, checks if the text mentions the name and/or e-mail address of some other person or the name of a patch file (e.g. gimp--.patch.gz). In this case, the author of the patch is credited for the update more than the one who commited the patch. That script was not very clean, though: it made some bad assumptions about how to find user names in comments and map them to the corresponding person. But that's why I said that "maybe I should try to hack it a bit more"... > Maybe split contributors in developers and small contributors. That way, > one looking on the about dialog would not have to wait ages to see your name > and Mitch's, for example. Hmmm... But then we could have endless debates about where we draw the line between developers and small contributors. Do we include only Sven, Mitch and Yosh as the main developers? Or do we take the top 20 contributors as developers? Or the top 50? Or...? Anyway, I don't think that we were discussing how to rank the various GIMP contributors, but rather how we can present to the users or potential contributors a summary of who is working on what. That should probably be grouped by "what" rather than by "who". In other words, we should try to generate automatically a list of contributors to each "area" of the GIMP. These areas could follow the layout of the source tree (sub-dirs in app and other top-level dirs) or could be grouped in a slightly different way. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
On Friday 23 April 2004 08:10, Sven Neumann wrote: > Hi, > > Raphaël Quinet <[EMAIL PROTECTED]> writes: > > Currently, I think that having a look at the ChangeLog is the best way > > (although cumbersome) to figure out who is working on what. Maybe we > > could make this easier by processing the ChangeLog automatically, > > analyzing who is working on what and publishing a list of the top > > contributors to each part of the code in the last N months (e.g., > > stats per directory in the source tree). That would not be perfect, > > but maybe it would be better than what we have now because this would > > be updated automatically. Some time ago, I wrote a script that parses > > the GIMP ChangeLog files and tries to figure out who are the most > > active developers. Maybe I should try to hack it a bit more. > > That sounds like something that should be done using the CVS > information, not by parsing the ChangeLog. Perhaps have a look at > statcvs, a CVS Repository statistic analysis tool. Would not that turn up just those who have CVS access? Maybe a mix of both. Maybe split contributors in developers and small contributors. That way, one looking on the about dialog would not have to wait ages to see your name and Mitch's, for example. > > Sven > > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
Hi, Robert L Krawitz <[EMAIL PROTECTED]> writes: > I have a script that I use to auto-generate a change log from a CVS > repository that's used to generate the Gimp-Print change log. It > coalesces multiple commits close in time that have the same log > message and handles branches correctly (i. e. if the sandbox being > used is on a branch, it logs all versions leading up to the branch). > I can post it if anyone likes, or it can be extracted from the > Gimp-Print source as scripts/mkchlog. That script will probably not work well with the style of CVS log messages that we use. Also the information we need here is not in the CVS log message nor in the ChangeLog. All that's needed is information about who changed how many lines in which files at what time. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
From: Sven Neumann <[EMAIL PROTECTED]> Date: 23 Apr 2004 13:10:00 +0200 Raphaël Quinet <[EMAIL PROTECTED]> writes: > Currently, I think that having a look at the ChangeLog is the > best way (although cumbersome) to figure out who is working on > what. Maybe we could make this easier by processing the > ChangeLog automatically, analyzing who is working on what and > publishing a list of the top contributors to each part of the > code in the last N months (e.g., stats per directory in the > source tree). That would not be perfect, but maybe it would be > better than what we have now because this would be updated > automatically. Some time ago, I wrote a script that parses the > GIMP ChangeLog files and tries to figure out who are the most > active developers. Maybe I should try to hack it a bit more. That sounds like something that should be done using the CVS information, not by parsing the ChangeLog. Perhaps have a look at statcvs, a CVS Repository statistic analysis tool. I have a script that I use to auto-generate a change log from a CVS repository that's used to generate the Gimp-Print change log. It coalesces multiple commits close in time that have the same log message and handles branches correctly (i. e. if the sandbox being used is on a branch, it logs all versions leading up to the branch). I can post it if anyone likes, or it can be extracted from the Gimp-Print source as scripts/mkchlog. -- Robert Krawitz <[EMAIL PROTECTED]> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
Hi, Raphaël Quinet <[EMAIL PROTECTED]> writes: > Currently, I think that having a look at the ChangeLog is the best way > (although cumbersome) to figure out who is working on what. Maybe we > could make this easier by processing the ChangeLog automatically, > analyzing who is working on what and publishing a list of the top > contributors to each part of the code in the last N months (e.g., > stats per directory in the source tree). That would not be perfect, > but maybe it would be better than what we have now because this would > be updated automatically. Some time ago, I wrote a script that parses > the GIMP ChangeLog files and tries to figure out who are the most > active developers. Maybe I should try to hack it a bit more. That sounds like something that should be done using the CVS information, not by parsing the ChangeLog. Perhaps have a look at statcvs, a CVS Repository statistic analysis tool. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
On Thu, 22 Apr 2004 12:34:10 +0200, Dave Neary <[EMAIL PROTECTED]> wrote: > - A list of active developers would help, along with their domains of expertise. > The GIMP's been around for nearly 10 years now, and the full list of > contributors doesn't really emphasise who's doing the main body of the work. Well, this information is supposed to be in the files MAINTAINERS and PLUGIN_MAINTAINERS. However, both files are relatively out of date. But they also suffer from another problem: they are not dynamic enough and it is unlikely that they would ever accurately reflect who is working on what and who is responsible for what. The problem is that people come and go, and someone who was active on some part of the code three months ago may be gone now or may have shifted his/her focus to some other part of the code. Nobody dares removing someone else from the MAINTAINERS file even if they have not contributed anything in the last two or three years. These files are useful for historical reasons, but not very helpful for those who want to know who is currently responsible for what part of the code. On the other hand, we cannot say that there are no rules and everybody is free to hack on any part of the code without consulting anyone, because that would quickly lead to chaos. Currently, I think that having a look at the ChangeLog is the best way (although cumbersome) to figure out who is working on what. Maybe we could make this easier by processing the ChangeLog automatically, analyzing who is working on what and publishing a list of the top contributors to each part of the code in the last N months (e.g., stats per directory in the source tree). That would not be perfect, but maybe it would be better than what we have now because this would be updated automatically. Some time ago, I wrote a script that parses the GIMP ChangeLog files and tries to figure out who are the most active developers. Maybe I should try to hack it a bit more. > - The roadmaps (when they change) should be announced on the list, stored on > developer.gimp.org and linked to from www.gimp.org somehow. > > The roadmaps, IMHO, should be time based rather than feature based (as we have > discussed in the past), [...] I also agree with time-based roadmaps. Although it could be a bit frustrating to postpone some features if they are not ready in time, time-based roadmaps have the advantage that everybody knows when the deadlines are and (hopefully) what the criteria for inclusion are. Although feature-based roadmaps can be nice for the main developers, they can be frustrating for those who would like to join us and contribute something, but have to postpone their contribution over and over again during a feature freeze while they see other small features being added to the program. Maybe I am exagerating a bit, but I think that we should keep that in mind: feature-based roadmaps give more power to the main developers but may have a negative impact on potential contributors. That's one of the reasons why I think that time-based roadmaps would be better. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
On Thu, 22 Apr 2004 08:33:07 -0500, "Stephen J Baker" <[EMAIL PROTECTED]> wrote: > Sven Neumann wrote: > > Perhaps we should ask ourselves then why the same questions are asked > > over and over again. [... good points snipped ...] > This is ALWAYS going to happen and no amount of additional documentation > is going to make a significant dent in that. > > The problem is in how people react to those kinds of requests. Yes, I agree. We can try to change the "others" by providing better documentation, FAQs, clear roadmaps, etc. But maybe we should first check if we can change ourselves. > On most of the lists that I participate in, people groan, roll their > eyes and then answer the question politely. If you know the answer, > it takes about the same amount of typing to answer a simple question > as it does to flame the user and tell him to RTFM. It doesn't really > increase your workload, it makes the user happier, it keeps the list > as a friendly, helpful place and life is good. > > On this list, the reaction is invariably hostile. We should all try to make some efforts to follow a policy such as: "if you cannot reply to someone in a polite way, then don't reply at all". This means that some questions may be ignored and this list may be rather silent from time to time, but I think that it would be better to do that than to scare potential contributors. We are all used to the strong language and very direct communication used on this list. Most of us can handle it. But for someone who joins this list for the first time, this place does not look very friendly. This is not the first time that some people say that they do not like the gimp-developer list. By the way, we had a very similar discussion at GIMPCon2003. We can improve our image to the "outside" by providing better documentation, list archives, and generally better communication towards GIMP users and potential developers... But we should also think a bit more about how we discuss things on this list. Even when we are in a bad mood. ;-) > > So IMO the things we need to consider are: > > - how can we make gimp development more transparent? > > - how can we publish short and long term plans and roadmaps? > > - why is there no maintained user FAQ? > > - why is the mailing-list archive not working? > > I don't think any of those things are the issue. There is no such thing as _the_ issue. All of these are important factors, and we should try to improve them. But I agree that we should not forget about our own behavior on this list, which may make any of the improvements cited above irrelevant because people run away after reading a few messages. > - how can we be more friendly/tolerant on this list? > - why do so many threads descend so rapidly into hostility? Yes, there are definitely some things that we can improve... -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
Sven Neumann wrote: Perhaps we should ask ourselves then why the same questions are asked over and over again. "that has been planned for some time now" is an answer that shows that the question shouldn't have been asked in the first place. Now, why is it asked then? That's the point we should worry about. If questions that appear as badly researched turn up, this is a clear sign that the information isn't easily available. Every mailing list I subscribe to has this problem. People simply find it easier to ask a human expert on a mailing list than to search for answers in documentation. I'm not aware of any projects that don't have this problem. Sure it's not great - sure we'd prefer if people spent an hour researching a problem before they post - sure we'd like people to say more than "It crashed while I was using it" in their bug reports. However, it seems to be a part of human nature to prefer to reach out and ask someone than to do 'due diligance' before they do so. We are evolved to communicate - it's what makes us human. This is ALWAYS going to happen and no amount of additional documentation is going to make a significant dent in that. The problem is in how people react to those kinds of requests. On most of the lists that I participate in, people groan, roll their eyes and then answer the question politely. If you know the answer, it takes about the same amount of typing to answer a simple question as it does to flame the user and tell him to RTFM. It doesn't really increase your workload, it makes the user happier, it keeps the list as a friendly, helpful place and life is good. On this list, the reaction is invariably hostile. The only reason to give a hostile and non-helpful response is because you hope to change the behavior of the supplicant. You will do that - but it won't change him into someone who reads the manual next time. It'll change him into someone who thinks the GIMP developers are a bunch of anal primadonna's. Gimp-developer is a HORRIBLE place to hang out and talk about GIMP - and that's a VERY bad thing for attracting new developers. Now that's something that we can try to change. The fact that mailing-lists are a place for random flame-baits and sometimes harsh words on the other hand is probably not going to change ever. There are occasional harsh things happening on every mailing list - that's true - but this one (out of maybe a dozen I read) is by far the worst. So IMO the things we need to consider are: - how can we make gimp development more transparent? - how can we publish short and long term plans and roadmaps? - why is there no maintained user FAQ? - why is the mailing-list archive not working? I don't think any of those things are the issue. - how can we be more friendly/tolerant on this list? - why do so many threads descend so rapidly into hostility? --- The second law of Frisbee throwing states: "Never precede any maneuver by a comment more predictive than "Watch this!"...it turns out that this also applies to writing Fragment Shaders. --- Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation & Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's wrong about this list [was: Gimp 2.0]
Hi, Sven Neumann wrote: So IMO the things we need to consider are: - how can we make gimp development more transparent? - how can we publish short and long term plans and roadmaps? - why is there no maintained user FAQ? - why is the mailing-list archive not working? Good questions... - A list of active developers would help, along with their domains of expertise. The GIMP's been around for nearly 10 years now, and the full list of contributors doesn't really emphasise who's doing the main body of the work. - The roadmaps (when they change) should be announced on the list, stored on developer.gimp.org and linked to from www.gimp.org somehow. The roadmaps, IMHO, should be time based rather than feature based (as we have discussed in the past), and should aim for roughly 3 timescales 1) near-term: next 6 months 2) medium term: Next 12 to 18 months 3) Long term: major goals not covered in 1 or 2, with how to get there (a brief list of prerequisites). In our context, that would mean 1) Plans for 2.2 2) Plans after 2.2 (notably, gegl integration, and whether that's realistic for 3.0, and to what level) 3) Other stuff. I think we should also have "projects" which can proceed independently of these - things like the usability tests can have their own schedule, with perhaps a developer who agrees to blindly put in place agreed reccommendations. Also, we need to define a kind of general set of guiding principles - are we going for a minimalist GIMP with lots of stuff addable, but very little installed, or for a kind of all-encompassing GIMP? How are we going to finally handle the plug-in distribution problem? In the meantime, how do we handle requests for plug-ins to be added to the main distribution? Currently there is no way to handle them, which meansthat we get no requests, more or less. There are some really good plug-ins which could be added, I think. - I really have no idea why there is no maintained user FAQ. It seems like there is very much an idea that the users and developers are two distinct, disjoint groups. Perhaps we should be asking user groups to maintain a FAQ, and encouraging them to contact us if they have any problems. This kind of comes around to an older issue too. Years ago the GUG contacted someone (I don't know who) about having a user group space on www.gimp.org, and apparrently they came away from that with a bad taste in their mouth. Perhaps the time has come to try and re-build that bridge and see what we can give each other? - As to the mailing list archives, I guess yosh will have to answer that one. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] what's wrong about this list [was: Gimp 2.0]
Hi, David Neary <[EMAIL PROTECTED]> writes: > For my part, some of the things I don't like are the comments > like "Everybody knows that...", or "that has been planned for > some time now", or worse "don't waste your time doing that". I > think that we should try and avoid saying that things are easy or > planned until there has been some planning work done or someone > has claimed a task. Perhaps we should ask ourselves then why the same questions are asked over and over again. "that has been planned for some time now" is an answer that shows that the question shouldn't have been asked in the first place. Now, why is it asked then? That's the point we should worry about. If questions that appear as badly researched turn up, this is a clear sign that the information isn't easily available. Now that's something that we can try to change. The fact that mailing-lists are a place for random flame-baits and sometimes harsh words on the other hand is probably not going to change ever. So IMO the things we need to consider are: - how can we make gimp development more transparent? - how can we publish short and long term plans and roadmaps? - why is there no maintained user FAQ? - why is the mailing-list archive not working? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
