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.
Gimp-developer mailing list