[gimp-web-devel/hugo] content: fix GIMPCon 2003 pages.

[Jehan <jehanp src gnome org>]

commit 9d4519516929f65a47ca5baf1b2cb0fc2ec4136c
Author: Jehan <jehan girinstud io>
Date:   Tue Aug 9 15:23:47 2022 +0200

    content: fix GIMPCon 2003 pages.
    
    * Split back the minutes into dedicated pages. Maybe it is unecessary to
      get a page dedicated to the minutes summary, but one page per detailed
      minutes is not too much. Otherwise it makes for far too much
      information on the main GIMPCon 2003 page.
    * Rename index.md to _index.md. Apparently hugo needs "section" pages
      otherwise the `minutes-*.md` pages are not even generated. It is
      actually extremely confusing and frustrating.
    * Set this _index.md in "single" layout, otherwise it tries to list
      every sub-page (i.e. every minutes as a list) in the end.
    * Fix various html to markdown formatting.

 content/conferences/gimpcon/2003/_index.md    |  81 +++
 content/conferences/gimpcon/2003/index.md     | 727 --------------------------
 content/conferences/gimpcon/2003/minutes-1.md | 186 +++++++
 content/conferences/gimpcon/2003/minutes-2.md | 240 +++++++++
 content/conferences/gimpcon/2003/minutes-3.md | 158 ++++++
 5 files changed, 665 insertions(+), 727 deletions(-)
---
diff --git a/content/conferences/gimpcon/2003/_index.md b/content/conferences/gimpcon/2003/_index.md
new file mode 100644
index 0000000..928b84f
--- /dev/null
+++ b/content/conferences/gimpcon/2003/_index.md
@@ -0,0 +1,81 @@
++++
+title = "GIMP Developers Conference 2003"
+abbrev = "GIMPCon 2003"
+description = "Chaos Communication Camp, Berlin, Germany"
+summary = "Chaos Communication Camp, Berlin, Germany"
+date = "2003-08-07"
+weight = -2
+layout = "single"
++++
+
+## GIMPCon 2003
+Chaos Communication Camp, near Berlin
+
+The second GIMP developers conference took place the
+*7/8/9/10th August 2003* at the [Chaos Communication
+Camp](http://www.ccc.de/camp/2003/). The Camp was an international,
+four-day open-air event for hackers and associated life-forms on a field
+near Berlin, Germany.
+
+{{< figure src="people-small.png" link="people.png" caption="The People at GimpCon 2003" >}}
+
+The GIMP developers joined this event and set up a GIMP tent to
+get together and discuss the future of GIMP development.
+Summaries of some of the discussions held there are available
+[below](#minutes-of-the-gimp-developers-conference-2003).
+
+We'd like to thank the
+<a href="http://www.fsf.org/";>Free Software Foundation</a>,
+<a href="http://www.oreilly.de/";>O'Reilly Germany</a>,
+<a href="http://www.macgimp.org/";>MacGIMP</a>,
+<a href="http://www.flamingtext.com/";>FlamingText</a> and
+the <a href="https://www.ccc.de/";>Chaos Computer Club</a>.
+Without their support this meeting wouldn't have been possible.
+
+## Minutes of The GIMP Developers Conference 2003
+
+Three big meetings were held at GIMPCon 2003. The topics of these
+meetings are listed below along with links to the minutes of the
+meetings.
+
+### The First Big Serious Meeting
+
+This meeting was held in the evening of August 7th, 2003. The main
+issues discussed were:
+
+* [The GIMP foundation](minutes-1#the-gimp-foundation)
+* [Release manager](minutes-1#release-manager)
+* [Decision making (or lack of it)](minutes-1#decision-making-or-lack-of-it)
+* [General stuff about CVS, Bugzilla](minutes-1#general-stuff-about-bugzilla-and-cvs)
+* [Communication](minutes-1#communication)
+
+The minutes from this meeting can be found [here]({{< ref "minutes-1.md" >}}).
+
+### The Second Big Serious Meeting
+
+This meeting was held in the evening of August 8th, 2003. The
+main issues discussed were:
+
+* [Features required for 2.0](minutes-2#features-required-for-20)
+* [Documentation](minutes-2#documentation)
+* [Web-site](minutes-2#web-site)
+* [Roadmap](minutes-2#roadmap)
+* [Bugs](minutes-2#bugs)
+* [Task List](minutes-2#task-list)
+* [GIMP Foundation](minutes-2#gimp-foundation)
+* [Release manager](minutes-2#release-manager)
+
+The minutes from this meeting can be found [here]({{< ref "minutes-2.md" >}}).
+
+### The Third Big Serious Meeting
+
+This meeting was held in the afternoon of August 9th, 2003. The
+main issues discussed were:
+
+* [How to get new developers?](minutes-3#how-to-get-new-developers)
+* [De we need binary distributions?](minutes-3#do-we-need-binary-distributions)
+* [Is Bugzilla too hard to use for new users?](minutes-3#is-bugzilla-too-hard-to-use-for-new-users)
+* [List of open tasks](minutes-3#list-of-open-tasks)
+* [Mailing lists](minutes-3#mailing-lists)
+
+The minutes from this meeting can be found [here]({{< ref "minutes-3.md" >}}).
diff --git a/content/conferences/gimpcon/2003/minutes-1.md b/content/conferences/gimpcon/2003/minutes-1.md
new file mode 100644
index 0000000..1b098f2
--- /dev/null
+++ b/content/conferences/gimpcon/2003/minutes-1.md
@@ -0,0 +1,186 @@
+---
+title: "The First Big Serious Meeting of GIMPCon 2003"
+date: "2003-08-07T20:00:00+0200"
+author: "Dave Neary"
+---
+
+August 7th 2003, around 8pm
+
+Discussion was led by Daniel Rogers (dsrogers) but stuff said is
+for the most part anonymous. Partly because there shouldn't be any
+ad hominem attacks that way, and partly because I didn't take down
+any names.
+
+Present: Daniel Rogers (dsrogers), Raphaël Quinet, Dave Neary
+(bolsh), Sven Neumann (Sven), Michael Natterer (mitch), Henrik
+Brix Andersen (brix), Jakub Steiner (jimmac), Simon Budig (nomis),
+Marc Lehmann, Ville Pätsi (drc), Øyvind Kolås (pippin), Calvin
+Williamson (calvin), Roman Joost (romanofski).
+
+Absent but at camp: Maurits Rijk (Maurits), Branko Collin (bbc).
+
+Topic discussion, in approximate chronological order:
+
+* [The GIMP foundation](#the-gimp-foundation)
+* [Release manager](#release-manager)
+* [Decision making (or lack of it)](#decision-making-or-lack-of-it)
+* [General stuff about CVS, Bugzilla](#general-stuff-about-bugzilla-and-cvs)
+* [Communication](#communication)
+
+#### The GIMP Foundation
+
+The idea of a foundation was proposed. Lots of ideas were thrown
+about as to what kind of remit it would have. If created, the
+foundation would certainly have 2 things we don't have at the
+moment - a bank account people could donate to, and a focus on
+"marketing" in the broadest sense of the word.
+
+Some of the issues were whether the foundation would be set up
+in Europe or in the US (in the US it might make it easier to get
+donations from US companies, but in Europe we're not as
+litigious, so setting up would certainly cost less, but then we
+probably wouldn't have NPO status in the US), whether it would
+have any technical aspect (that is, would the foundation act as
+a kind of steering committee for the general direction of the
+GIMP?), and how, if the issue came up, we might pay someone.
+
+This led onto a discussion of whether the foundation would be
+responsible for setting release dates, or whether we would have
+a separate...
+
+#### Release Manager
+
+The general consensus (more on that later) was that a release
+manager is a good thing. There do seem to be a few different
+ideas of what the role would entail. The general idea would be
+that the release manager would be responsible for following CVS
+and know at what stage a given feature is at, follow bugzilla
+making sure that bugs got milestoned for some release in order
+of their priority, would annoy people to get commits in before
+feature freeze dates or postpone mercilessly features which are
+not finished.
+
+It was agreed that a release schedule would be helpful to define
+the perimeters of responsibility of the release manager -
+basically, some way to set up large milestones to aim for with
+things to go into those milestones. This release schedule would
+be subject to revision, and would be no more realistic than any
+other release schedule, but it would serve as a guide for
+development. Dan agreed to draw up a first draft of this, and
+we'll have something more concrete before the end of the
+weekend.
+
+The questions that came up about the release manager were things
+like where his authority comes from, how does he decide which
+bugs are important and which features can be postponed and so
+on. In other words, how do decisions get made. Is the release
+manager a benevolent dictator, or does he answer to the larger
+developer and user community? If so, to what extent? Is backing
+out CVS commits OK, for example?
+
+So we started talking about how to get contentious decisions
+made.
+
+#### Decision making (or lack of it)
+
+Currently, there are two ways to get something done in the
+GIMP. First, you can write decent code and patches for a while,
+until you get CVS commit access, then you write whatever feature
+you're interested in, and commit it. If no-one backs it out,
+then it's in.
+
+Second, you can bring it up on the mailing list, or in bugzilla,
+or in IRC (more on communication later), and discuss it until
+there is a consensus. However, we tend to be pretty bad at
+reaching consensus on anything even slightly contentious. The
+important questions to be answered any time a discussion like
+this comes up are what's going to be done, and who's going to do
+it.
+
+It was agreed that beyond a certain point, there is generally
+very little technical merit to these types of discussions. It
+was felt that about 5 days was enough for everyone with an
+opinion on a given matter to make that opinion known, and that
+after that point, it would be an idea to have a summary of the
+salient points and close the discussion. That means, the people
+here would stop posting to the discussion. Of course, if other
+people want to keep on flaming, they're free to do so, but
+people will just ignore the thread.
+
+At this point, the summary should sum up the various points, and
+finish with an answer to those two questions - what gets done,
+and who's doing it.
+
+We may even have a bake-off system. If there are two competing
+ideas for the way something should be done, currently no-one
+tends to do it. Ideally, both people would do it and we pick the
+best one.
+
+This brings up another point, though - in general, what is
+authority? And in particular, at what point has someone gained
+enough standing and authority to post one of these thread-ending
+summaries? Some discussion is going to be had on that over the
+weekend.
+
+#### General stuff, about Bugzilla and CVS
+
+We talked about various ways of improving the way we use these
+tools. First is whether it makes sense for us to have module
+owners, and if so, who should they be? Should we use the system
+of bug owners to track who is responsible for a bug at any given
+time, or is the current scheme of bugs gimp org sufficient? Do
+we need to change bugs gimp org to something else to avoid
+confusion with the old bug reporting address? There were a few
+open points in here.
+
+Second, we talked about pre-release branches, and whether it
+would be worthwhile having a mozilla style release cycle with
+feature-freezes, followed by concurrent bug-fixing before
+unstable releases, freeing up the branch for bigger stuff that
+people want to start committing. In general, it was felt that
+there was very little to be gained from that, and the current
+system of a long-lived devel branch with self-imposed feature
+freezes every few weeks was a better way to go.
+
+We also expressed a desire to have more redundancy in the
+non-technical aspects of The GIMP, things like the mailing lists
+and ftp mirror lists should have more than one person with the
+ability to change them so that if there's a problem, and that
+person has no time to take care of it, then someone
+will. Perhaps using a Debian or GNU style ticket system might
+help here fro these particular tasks? In any case, everyone in a
+given group should know everyone else in the group, and know
+more or less that when an issue gets in, it will be handled by
+at least one person.
+
+#### Communication
+
+It was agreed that we need to communicate better (that's a
+no-brainer, really). For a start, every developer should be
+subscribed to the userlist. gimp-devel (if it doesn't disappear
+altogether) would only be used for technical discussions of
+implementation details - all the philosophical level discussions
+of new features, ui changes, release mechanisms and so on should
+be discussed on the user list.
+
+Basically, we're going to talk a lot more about how the
+developers can interface better with the users.
+
+#### Decisions
+
+Not too many of these... we will have a release manager, but we
+need to define exactly what his/her remit will be. And who it
+will be. We agreed that the "5 days and it's dead" rule for threads
+makes sense, so that will be done.
+
+#### Future
+
+1. Roadmap - rough release schedule, we will have a first draft today.
+2. GIMP Foundation - we need to define its responsibilities, set up election rules, and get this set up. The 
principle of the foundation is more or less agreed.
+3. Communication
+4. Release Manager - what'll he do, who'll he be. This should be short once we have discussed communication 
channels a bit.
+5. Technie stuff - Sven and mitch are going to talk to us about the re-organisation of the code, 
GObjectification of everything, and other stuff. Daniel and Calvin are going to talk to us about GEGL and how 
they feel The GIMP could use it. This will probably be a two-way discussion about what kind of things we 
expect GEGL to furnish as well.
+6. GIMP tutorials - jimmac and nomis are going to do some presentations for people, which should be good.
+7. Plug-in distribution - 3 years ago this was discussion, yosh has been working on something as a 
proof-of-concept, it would be nice to address this and get something in place soon.
+
+Written by Dave Neary
diff --git a/content/conferences/gimpcon/2003/minutes-2.md b/content/conferences/gimpcon/2003/minutes-2.md
new file mode 100644
index 0000000..5b1806a
--- /dev/null
+++ b/content/conferences/gimpcon/2003/minutes-2.md
@@ -0,0 +1,240 @@
+---
+title: "The Second Big Serious Meeting of GIMPCon 2003"
+date: "2003-08-08T20:00:00+0200"
+author: "Dave Neary"
+---
+
+August 8th 2003, around 8pm
+
+Discussion was led by Daniel Rogers (dsrogers) but stuff said is
+for the most part anonymous. Partly because there shouldn't be any
+ad hominem attacks that way, and partly because I didn't take down
+any names.
+
+Present: Daniel Rogers (dsrogers), Raphaël Quinet, Dave Neary
+(bolsh), Sven Neumann (Sven), Michael Natterer (mitch), Henrik
+Brix Andersen (brix), Jakub Steiner (jimmac), Simon Budig (nomis),
+Marc Lehmann, Ville Pätsi (drc), Øyvind Kolås (pippin), Calvin
+Williamson (calvin), Roman Joost (romanofski), Maurits Rijk
+(Maurits), Branko Collin (bbc).
+
+Topic discussion, in approximate chronological order:
+
+* [Features required for 2.0](#features-required-for-20)
+* [Documentation](#documentation)
+* [Web-site](#web-site)
+* [Roadmap](#roadmap)
+* [Bugs](#bugs)
+* [Task List](#task-list)
+* [GIMP Foundation](#gimp-foundation)
+* [Release manager](#release-manager)
+
+#### Features required for 2.0
+
+There was quite a lot of talk on what was required for a 2.0
+release. It was agreed that a pre-release should have feature
+complete versions of everything going into 2.0, for obvious
+reasons. These can be somewhat buggy, but they should at least
+support what is supported in the 1.2 equivalents.
+
+The major features or API changes which it was agreed are
+necessary are:
+
+1. Complete path tool (nomis)
+1. Remove libgck (Sven and mitch)
+1. Finish the text tool (Sven)
+1. Documentation (more on this later)
+1. Web-site (again, more on this later)
+1. Some libgimp changes which need to be made now so that we can havebinary compatibility across a 2.2 
release
+
+#### Documentation
+
+We felt that with pre-releases, the documentation will become
+more complete. There should, however, be an effort to actively
+get people writing docs. The main requirement, then, for 2.0
+pre-releases will be to have a working help framework, so that
+when people hit F1 for help, they at least get a message saying
+"This help item does not exist yet.If you would like to
+help write it, contact docs gimp org" or some such.
+
+*Note: that email address doesn't exist (yet). People interested in
+helping with the documentation should have a look at the
+[Wiki](http://wiki.gimp.org/gimp/GimpDocs).*
+
+If documentation is going to be released as a separate package,
+as now seems likely, then we will need to define the interface
+between the core and the help pages reasonably quickly. The
+general idea is to more or less hard-code tagnames for a
+particular help topic, and get the core and help using the same
+tags, and agreeing on how they be communicated. This will
+presumably require a considerable amount of communication with
+the help team.
+
+We also need to have the docs browsable online so that if people
+want to browse them they can.
+
+#### Web-site
+
+The new site should switch over to www.gimp.org soon. There will
+obviously be quite a bit of pain involved as content gets added
+and we get lots of "your website sucks" type
+feedback, but this will only befor the short term. We should
+switch to mmaybe as the main site before 2.0pre1. It was
+suggested to do it even earlier than that, in the region of 2 to
+3 weeks time.
+
+It was also discussed whether it was a good idea to have a
+separate coordinator for the website.
+
+#### Roadmap
+
+As an approximate set of ideals, it was agreed that we want
+this: 2.0pre1 very soon, 2.0 soon, 2.2 next year, and GEGL
+integration the end of next Summer.
+
+More specifically, the near-term release schedule that we agreed
+was reasonable is this:
+
+1 or 2 developer releases (one now, more or less, and another
+one in another 2 weeks). 6 weeks time (end of September 2003):
+First pre-release of 2.0, including the features mentioned
+above, and any other minor features that people code in the
+meantime (hint, hint). Roughly 3 months later: 2.0
+
+It was more or less agreed that 3 to 4 weeks was a nice
+turnaround time for pre-releases, so that would imply between 4
+and 6 (inclusive) pre-releases before 2.0.
+
+The reason for not having a pre-release straight away was
+mentioned above: to be feature complete, some features need a
+little more than 2 weeks work, and people have real lives. So 6
+weeks was felt to be a reasonable amount of time to have the
+path tool and the help browser in place.
+
+#### Bugs
+
+The developer release will also be a prelude to a bug week. We
+would like people (that's you, in particular) to actively work
+on bugzilla clean-up for 2.0 - bugs need to be prioritized,
+unconfirmed bugs need confirming and milestoning (and if you're
+feeling really helpful, fixing). The idea would more or less be
+that the 2.0 milestone will be locked down for anything other
+than serious bugs after this bug week, so if there are bugs that
+are annoying you a lot, this is your chance to get them
+considered and worked on for the 2.0 releases.
+
+Just to spell that out - at the end of the bug week, any bugs
+reported against The GIMP in CVS will be milestoned for 2.0.x,
+or even 2.2, unless they are considered blockers for the
+release. If we want to get a 2.0 release soon, we need to get
+lots of testing done, and lots of bugfixing done, but we also
+need to choose what to do and what not to do. We felt this was a
+reasonable compromise.
+
+It was also re-discussed whether it would make sense to have
+module owners. The conclusion was that for certain components,
+it makes sense to have a smaller group of people getting the bug
+reports and having responsibility for them. This would be done
+via mail aliases for the group of people guiding the component,
+in a similar way to that which is used for (say) gtktreeview in
+gtk+.
+
+The module owner group wouldn't have to be technical, and we
+should be actively recruiting people to do this kind of work and
+leave more time for programmers to program.
+
+This leads us on to...
+
+#### Task list
+
+There are lots of non-technical jobs that need doing around the
+gimp-docs, website, bugzilla triage, internationalisation,
+etc. Often it is quite difficult to know what needs doing, and
+who to contact about getting it done. We need a list of
+bite-sized tasks that people can do, including the kinds of
+tasks that only take a few hours a week to do, but are ongoing
+tasks.
+
+We used to have a TODO, and we could use that system again, if
+someone were maintaining it. That could come under the remit of
+the release manager to some extent, but since the mainenance of
+the TODO list is mostly a non-technical task, anyone could do it
+(in fact, as an example of a task, "Maintaining the TODO
+list" would go in the TODO list).
+
+We might do this through Bugzilla using a keyword to allow
+getting at the list easily, which would imply getting more
+people looking at bugzilla regularly. Then again, if there were
+a link to a bugzilla query on the webpage marked "GIMP
+TODO list" we could get that for free.
+
+#### GIMP Foundation
+
+Basically, we're agreed this is a good idea to have some kind of
+public face people and companies can contribute to. There is no
+problem with having 2 foundations, one in Europe and one in the
+US. It was more or less agreed that assigning copyright to the
+foundation isn't going to happen soon (for a start, so many
+plug-in authors have gone their merry way and are almost
+unfindable) This may hapen in the future, but most people felt
+that it would not be something they'd be happy doing personally.
+
+Other people said they would prefer to assign copyright to an
+organism under the jurisdiction of European law rather than
+under US jurisdiction.
+
+So, to sum up, there's no reason not to have one of
+these. Daniel Rogers has agreed to do the necessary paperwork
+and set up the foundation and the bank account for donations in
+the US. Pretty quickly after getting that up and going, we will
+need to get a board of directors and a set of by-laws. We know
+lots of people who can help with this (in particular, the GNOME
+foundation and the FSF).
+
+If someone wants to set up an equivalent in Europe, we're all
+ears. Currently no-one has said they'll do it, so it's an open
+point. To start, the foundation will only be a board an a bank
+account - in the future, we could expand its responsibilities to
+promotional work, a single point where people could go to get
+speakers, a group that does press releases and so on. It was
+agreed that at least in the short term it is undesirable to have
+the foundation have actual control of source code, just in case
+the foundation then gets sued.
+
+In brief, it's being set up with a very narrow remit, with the
+possibility to expand later if it is felt that there is a need.
+
+#### Release manager
+
+The responsibilities are:
+
+
+ * Follow CVS so that he can write release notes, and knows at
+any given time who is working on what, and at what stage it
+is
+ * Follow bugzilla closely
+ * Make releases regularly, according to the roadmap (or make
+sure releases get made)
+ * Update the roadmap to reflect reality
+ * Write release notes for the releases (keep NEWS up to date)
+ * Generally annoy people sending mails to the mailing lists and
+sending content to the website to explain the state of play
+and get people to work on stuff.
+
+Dave Neary (me) agreed to do this. He already regrets it.
+
+That's it folks - today, Sven and mitch are going to talk to us
+about the major changes in the codebase and the general utility
+stuff which exists now which has been written from scratch,
+Calvin and Daniel are going to talk about GEGL and how we can
+use it, and work towards having a GEGL that we can use in a
+year. I'm going to lead a discussion on communication in the
+GIMP, and how to maybe make it easier for people to contribute,
+and jimmac is going to demonstrate what a power user really is.
+
+Goodbye from everyone at camp. As usual, comments are welcome on
+all this stuff. While on a philosophical level, we are agreed on
+the direction things should take, all the details are open to
+discussion, if there's any reason to change them.
+
+Written by Dave Neary
diff --git a/content/conferences/gimpcon/2003/minutes-3.md b/content/conferences/gimpcon/2003/minutes-3.md
new file mode 100644
index 0000000..b02440e
--- /dev/null
+++ b/content/conferences/gimpcon/2003/minutes-3.md
@@ -0,0 +1,158 @@
+---
+title: "The Third Big Serious Meeting of GIMPCon 2003"
+date: "2003-08-09+0200"
+author: "Dave Neary"
+---
+
+August 9th 2003, some time in the afternoon
+
+Here are the minutes of Yet Another Big Meeting that took place
+this afternoon in the GimpTent. The meeting was chaired by Dave
+Neary and these minutes were written by Raphaël Quinet.
+
+The title of this meeting was "Communication". The
+main topics were how to improve the communication between
+developers and users or potential new developers. We also
+discussed how to present The GIMP to the "outside"
+and how to make it easier for new users to try out The GIMP or get
+involved in GIMP development.
+
+Altough there was no pre-defined agenda for this meeting,
+the following topics were discussed:
+
+ * [How to get new developers?](#how-to-get-new-developers)
+ * [De we need binary distributions?](#do-we-need-binary-distributions)
+ * [Is Bugzilla too hard to use for new users?](#is-bugzilla-too-hard-to-use-for-new-users)
+ * [List of open tasks](#list-of-open-tasks)
+ * [Mailing lists](#mailing-lists)
+
+#### How to get new developers?
+
+Like in any Free Software project, developers are leaving from
+time to time to pursue other projects. And from time to time,
+new developersare joining the team and starting to contribute.
+However, it looks like the number of new developers joining the
+GIMP development has been decreasing in the recent years. This
+may be due in part to the fact that there haven't been any major
+changes in a stable release for a long time.
+
+Another reason may be that it is difficult to build the
+development version because it depends on released versions of
+some libraries that are not included yet in the major GNU/Linux
+distributions (e.g., GTK+ version 2.2.2). Also, the number of
+dependencies for GIMP 1.3.x is much higher than the number of
+dependencies for GIMP 1.2.x, so it ismore difficult to have a
+working build environment for the 1.3.x version. This problem
+may be solved as time passes, because more and more
+distributions will include the required libraries.
+
+There should be a section on www.gimp.org or developer.gimp.org
+titled "How to contribute?" or "How to get
+involved?". It should be easy for potential new
+developers to see where to start and how they can help. More on
+that below.
+
+#### Do we need binary distributions?
+
+There was a discussion about binary distributions. This may help
+people to try some versions of the GIMP (especially the
+development versions) without having to compile everything.
+However, maintaining binaries is a lot of work, even if we only
+maintain binaries supplied by others. In addition, this would
+bring some additional responsabilities that we do not want to
+have. For these reasons, it was decided that www.gimp.org would
+not host any binaries but would link to the pages of those who
+are providing binaries for various platforms.
+
+It would be very nice to have Windows binaries for the
+development version.
+
+#### Is Bugzilla too hard to use for new users?
+
+It was suggested to make it easier for users to submit bug
+reports, for example by having an e-mail address to which bug
+reports can be sent without having to register to Bugzilla (we
+already have such an address, although it is not widely known).
+This proposal was rejected because most of the bug reports
+(especially from new users) are incomplete and require
+additional information. If the user does nothave a Bugzilla
+account, it is not possible to rely on the automatic
+notification system to send messages to the user when a comment
+is added to their bug report or when the status of their bug
+report changes.
+
+
+Most developers consider Bugzilla to be a very valuable tool
+that works well. Instead of trying to hide Bugzilla from the
+users, we should try to make it as easy as possible for the new
+users to join. This is already done to some extent by the bug
+submission wizard available from http://bugs.gimp.org/. There is
+a small problem with the GNOME2 keyword that prevents the open
+GIMP bugs from being displayed to the user and we should try to
+get this fixed.
+
+#### List of open tasks
+
+There are many open bug reports or proposals for enhancements
+that would be relatively easy to fix or implement. We should
+make it easier for potential contributors to see the list of
+easy tasks that are open. The "easy tasks" should
+include anything that can be done in one or two hours by an
+average developer or maybe a bit more if the contributor is not
+familiar with the code.
+
+The best way to keep the list of open tasks up-to-date is
+probably to base it on Bugzilla. We could for example use a
+Bugzilla keyword for all bugs that are easy to fix (there is
+already a keyword "easy-fix" reserved for that,
+although we could invent our own). It would then be easy to
+create a Bugzilla query showing the list of easy tasks. Another
+solution would be to have a page on www.gimp.org or
+developer.gimp.org containing a list of all these bugs, with
+direct links to the corresponding bug reports. The second
+solution may require a bit more work because it would have to be
+maintained by someone, but it might be a bit easier to use.
+
+#### Mailing lists
+
+Sometimes, there is a lack of communication between users and
+developers of The GIMP. After some discussion, it was decided
+that we should not merge the mailing lists gimp-user and
+gimp-developer because this could cause various problems: the
+combined amount of traffic may be too high for some subscribers,
+the discussions among developers may be confusing for some
+users, and in general we should let people subscribe to what
+they are interested in, instead of removing this option by
+merging the lists (we cannot force anybody to read what they do
+not want to read).
+
+But it would be very useful for the developers to get more
+feedback from the users, especially about UI and usability
+issues. For this reason, all developers are strongly encouraged
+to subscribe to the gimp-user list.
+
+The web site (www.gimp.org) should contain a list of the various
+sources of information about the GIMP: mailing lists, newsgroup,
+Yahoo group, GUG, other web sites such as linuxgraphic.org or
+gimp.de, etc. The description of the mailing lists should
+encourage people to subscribe to both the users and developers
+lists.
+
+#### Summary
+
+We hope that the next stable release will attract new
+developers. This has been the case when 1.0 and 1.2 were
+released. The transition to the new web site will also help,
+especially if the navigation menu contains some useful items
+such as "Bugs", "FAQ", etc. The
+following items should be available in the web site:
+
+ * "How to contribute?" or "Getting involved"
+ * List of tasks
+ * List of sources of information (mailing lists, newsgroup, ...)
+ * FAQ
+
+As with the other documents summarizing what is happening here
+at GimpCon, comments are welcome...
+
+Written by Raphaël Quinet