On Thu, 22 Apr 2004 12:34:10 +0200, Dave Neary <dneary@xxxxxxx> 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
