[gimp-web-devel/hugo] Move gimpcon stuff under conferences/
- From: Pat David <patdavid src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [gimp-web-devel/hugo] Move gimpcon stuff under conferences/
- Date: Sat, 6 Aug 2022 18:13:13 +0000 (UTC)
commit ba05b4b1263aefa9804bcfd300bb256ff11a115b
Author: Pat David <patdavid gmail com>
Date: Sat Aug 6 13:07:54 2022 -0500
Move gimpcon stuff under conferences/
Per
https://gitlab.gnome.org/Infrastructure/gimp-web-devel/-/issues/7#note_1509643
I'm moving all the gimpcon stuff under the dir /conferences/.
I'm assuming we may have more than just GIMPCon conferences listed
at some point possibly.
content/conferences/_index.md | 9 +
content/conferences/gimpcon/2000/_index.md | 28 ++
content/conferences/gimpcon/2000/people-small.jpg | Bin 0 -> 49236 bytes
content/conferences/gimpcon/2003/_index.md | 48 ++
.../conferences/gimpcon/2003/gimpcon2003-mins-1.md | 188 +++++++
.../conferences/gimpcon/2003/gimpcon2003-mins-2.md | 295 +++++++++++
.../conferences/gimpcon/2003/gimpcon2003-mins-3.md | 239 +++++++++
.../conferences/gimpcon/2003/gimpcon2003-mins.md | 144 ++++++
content/conferences/gimpcon/2003/people-small.png | Bin 0 -> 244483 bytes
content/conferences/gimpcon/2003/people.png | Bin 0 -> 1047014 bytes
content/conferences/gimpcon/2004/Dave_Neary.jpg | Bin 0 -> 7489 bytes
content/conferences/gimpcon/2004/Oyvind_Kolas.png | Bin 0 -> 50772 bytes
content/conferences/gimpcon/2004/_index.md | 296 +++++++++++
content/conferences/gimpcon/2004/gnu-head-sm.jpg | Bin 0 -> 5286 bytes
.../conferences/gimpcon/2004/mac_gimp_logo4.png | Bin 0 -> 11474 bytes
.../gimpcon/2004/macosx_screenshot1_thumb.jpg | Bin 0 -> 14879 bytes
content/conferences/gimpcon/2006/_index.md | 542 +++++++++++++++++++++
content/conferences/gimpcon/2006/meetings.jpg | Bin 0 -> 220989 bytes
.../conferences/gimpcon/2006/meetings_small.jpg | Bin 0 -> 33965 bytes
content/conferences/gimpcon/2006/people.jpg | Bin 0 -> 281806 bytes
content/conferences/gimpcon/2006/people_small.jpg | Bin 0 -> 38999 bytes
content/conferences/gimpcon/_index.md | 19 +
22 files changed, 1808 insertions(+)
---
diff --git a/content/conferences/_index.md b/content/conferences/_index.md
new file mode 100644
index 0000000..41fbb25
--- /dev/null
+++ b/content/conferences/_index.md
@@ -0,0 +1,9 @@
+---
+title: 'Conferences'
+date: 2022-08-06T12:49:14-0500
+author: 'Pat David'
+menu: main
+weight: 3
+---
+
+This is the conferences section.
diff --git a/content/conferences/gimpcon/2000/_index.md b/content/conferences/gimpcon/2000/_index.md
new file mode 100644
index 0000000..b5f58bb
--- /dev/null
+++ b/content/conferences/gimpcon/2000/_index.md
@@ -0,0 +1,28 @@
++++
+title = "GIMP Developers Conference 2000"
+author = "The GIMP Development Team"
+abbrev = "GIMPCon 2000"
+description = "Chaos Computer Club, Berlin"
++++
+
+The first official GIMP Developers Conference took place
+*June 2nd - 4th 2000* in [Berlin](https://www.berlin.de).
+
+The [Chaos Computer Club Berlin](http://berlin.ccc.de/)
+was so kind to allow us to use their rooms for the
+conference. The [Chaos Computer Club](https://www.ccc.de)
+is a galactic community of human beings including
+all ages, genders, races and social positions. They demand
+unlimited freedom and flow of information without censorship.
+
+[people-small.jpg](The People at GIMPCon 2000)
+
+From left to right, top to bottom: Calvin, Simon, Seth, Jakub,
+Lauri, Austin, Tigert, Tim, Jens, Tor, Jay, Daniel, Sven, Adam,
+Mitch, Garry, Marc, Caroline, Andy, Yosh.
+
+We'd like to thank the [Free Software Foundation](https://www.fsf.org),
+the [Chaos Computer Club](https://www.ccc.de) and
+[O'Reilly Germany](https://www.oreilly.de) for their
+help that made this meeting possible.
+
diff --git a/content/conferences/gimpcon/2000/people-small.jpg
b/content/conferences/gimpcon/2000/people-small.jpg
new file mode 100644
index 0000000..51f90a1
Binary files /dev/null and b/content/conferences/gimpcon/2000/people-small.jpg differ
diff --git a/content/conferences/gimpcon/2003/_index.md b/content/conferences/gimpcon/2003/_index.md
new file mode 100644
index 0000000..0465164
--- /dev/null
+++ b/content/conferences/gimpcon/2003/_index.md
@@ -0,0 +1,48 @@
++++
+title = "GIMP Developers Conference 2003"
++++
+
+ <titleabbrev>GIMPCon 2003</titleabbrev>
+ <summary>Chaos Communication Camp, near Berlin</summary>
+ </head>
+
+ <para>
+ The second GIMP developers conference took place the
+ <emphasis>7/8/9/10th August 2003</emphasis> at the <ulink
+ url="http://www.ccc.de/camp/2003/";>Chaos Communication
+ Camp</ulink>. The Camp was an international, four-day open-air
+ event for hackers and associated life-forms on a field near
+ Berlin, Germany.
+ </para>
+
+ <para role="images">
+ <ulink url="people.png">
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="people-small.png"/>
+ </imageobject>
+ <textobject>
+ <phrase>The People at GimpCon 2003</phrase>
+ </textobject>
+ </mediaobject>
+ </ulink>
+ </para>
+
+ <para>
+ 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
+ <olink targetdocent="minutes">here</olink>.
+ </para>
+
+ <para>
+ We'd like to thank the
+ <ulink url="http://www.fsf.org/";>Free Software Foundation</ulink>,
+ <ulink url="http://www.oreilly.de/";>O'Reilly Germany</ulink>,
+ <ulink url="http://www.macgimp.org/";>MacGIMP</ulink>,
+ <ulink url="http://www.flamingtext.com/";>FlamingText</ulink> and
+ the <ulink url="https://www.ccc.de/";>Chaos Computer Club</ulink>.
+ Without their support this meeting wouldn't have been possible.
+ </para>
+
+</webpage>
diff --git a/content/conferences/gimpcon/2003/gimpcon2003-mins-1.md
b/content/conferences/gimpcon/2003/gimpcon2003-mins-1.md
new file mode 100644
index 0000000..e9043c2
--- /dev/null
+++ b/content/conferences/gimpcon/2003/gimpcon2003-mins-1.md
@@ -0,0 +1,188 @@
++++
+title = "The First Big Serious Meeting of GIMPCon 2003"
+abbrev = "First Meeting"
+description = "Minutes of the first GIMPCon 2003 Meeting"
+author = "The GIMP Development Team"
++++
+
+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)](#decisions)
+* [General stuff about CVS, Bugzilla](#general)
+* [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
+<quote>marketing</quote> 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 <quote>5 days and it's dead</quote>
+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/gimpcon2003-mins-2.md
b/content/conferences/gimpcon/2003/gimpcon2003-mins-2.md
new file mode 100644
index 0000000..47f55ec
--- /dev/null
+++ b/content/conferences/gimpcon/2003/gimpcon2003-mins-2.md
@@ -0,0 +1,295 @@
++++
+title = "The Second Big Serious Meeting of GIMPCon2003"
+abbrev = "Second Meeting"
+description = "Minutes of the second GIMPCon 2003 Meeting"
+author = "The GIMP Development Team"
++++
+
+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:
+
+* <link linkend="features">Features required for 2.0</link>
+* <link linkend="documentation">Documentation</link>
+* <link linkend="web">Web-site</link>
+* <link linkend="roadmap">Roadmap</link>
+* <link linkend="bugs">Bugs</link>
+* <link linkend="tasks">Task List</link>
+* <link linkend="foundation">GIMP Foundation</link>
+* <link linkend="manager">Release manager</link>
+
+## 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:
+
+<orderedlist>
+1. <listitem>Complete path tool (nomis)</listitem>
+2. <listitem>Remove libgck (Sven and mitch)</listitem>
+<listitem>Finish the text tool (Sven)</listitem>
+<listitem>Documentation (more on this later)</listitem>
+<listitem>Web-site (again, more on this later)</listitem>
+<listitem>Some libgimp changes which need to be made now so that
+we can havebinary compatibility across a 2.2 release</listitem>
+</orderedlist>
+</para>
+
+</section>
+
+<section id="documentation">
+<title>Documentation</title>
+
+<para>
+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
+<quote>This help item does not exist yet.If you would like to
+help write it, contact docs gimp org</quote> or some such.
+<footnote>
+<para>
+That email address doesn't exist (yet). People interested in
+helping with the documentation should have a look at the
+<ulink url="http://wiki.gimp.org/gimp/GimpDocs";>Wiki</ulink>.
+</para>
+</footnote>
+
+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.
+</para>
+
+</section>
+
+<section id="web">
+<title>Web-site</title>
+
+<para>
+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 <quote>your website sucks</quote> 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.
+</para>
+
+</section>
+
+<section id="roadmap">
+<title>Roadmap</title>
+
+<para>
+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.
+</para>
+
+</section>
+
+<section id="bugs">
+<title>Bugs</title>
+
+<para>
+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...
+</para>
+
+</section>
+
+<section id="tasks">
+<title>Task list</title>
+
+<para>
+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, <quote>Maintaining the TODO
+list</quote> 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 <quote>GIMP
+TODO list</quote> we could get that for free.
+</para>
+
+</section>
+
+<section id="foundation">
+<title>GIMP Foundation</title>
+
+<para>
+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.
+</para>
+
+</section>
+
+<section id="manager">
+<title>Release manager</title>
+
+<para>
+The responsibilities are:
+<itemizedlist>
+<listitem>
+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
+</listitem>
+<listitem>
+Follow bugzilla closely
+</listitem>
+<listitem>
+Make releases regularly, according to the roadmap (or make
+sure releases get made)
+</listitem>
+<listitem>
+Update the roadmap to reflect reality
+</listitem>
+<listitem>
+Write release notes for the releases (keep NEWS up to date)
+</listitem>
+<listitem>
+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.
+</listitem>
+</itemizedlist>
+
+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/gimpcon2003-mins-3.md
b/content/conferences/gimpcon/2003/gimpcon2003-mins-3.md
new file mode 100644
index 0000000..b1b3da9
--- /dev/null
+++ b/content/conferences/gimpcon/2003/gimpcon2003-mins-3.md
@@ -0,0 +1,239 @@
++++
+author = "The GIMP Development Team"
++++
+
+ <title>The Third Big Serious Meeting of GIMPCon 2003</title>
+ <titleabbrev>Third Meeting</titleabbrev>
+ <summary>Minutes of the third GIMPCon 2003 Meeting</summary>
+ </head>
+
+ <para>
+ August 9th 2003, some time in the afternoon
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ The title of this meeting was <quote>Communication</quote>. 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 <quote>outside</quote>
+ and how to make it easier for new users to try out The GIMP or get
+ involved in GIMP development.
+ </para>
+
+ <para>
+ Altough there was no pre-defined agenda for this meeting,
+ the following topics were discussed:
+ <itemizedlist>
+ <listitem>
+ <link linkend="developers">How to get new developers?</link>
+ </listitem>
+ <listitem>
+ <link linkend="binary">De we need binary distributions?</link>
+ </listitem>
+ <listitem>
+ <link linkend="bugzilla">Is Bugzilla too hard to use for new
+ users?</link>
+ </listitem>
+ <listitem>
+ <link linkend="tasks">List of open tasks</link>
+ </listitem>
+ <listitem>
+ <link linkend="mailinglists">Mailing lists</link>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <section id="developers">
+ <title>How to get new developers?</title>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ There should be a section on www.gimp.org or developer.gimp.org
+ titled <quote>How to contribute?</quote> or <quote>How to get
+ involved?</quote>. It should be easy for potential new
+ developers to see where to start and how they can help. More on
+ that below.
+ </para>
+
+ </section>
+
+ <section id="binary">
+ <title>Do we need binary distributions?</title>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ It would be very nice to have Windows binaries for the
+ development version.
+ </para>
+
+ </section>
+
+ <section id="bugzilla">
+ <title>Is Bugzilla too hard to use for new users?</title>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ </section>
+
+ <section id="tasks">
+ <title>List of open tasks</title>
+
+ <para>
+ 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 <quote>easy tasks</quote> 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.
+ </para>
+
+ <para>
+ 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 <quote>easy-fix</quote> 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.
+ </para>
+
+ </section>
+
+ <section id="mailinglists">
+ <title>Mailing lists</title>
+
+ <para>
+ 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).
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ <para>
+ 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.
+ </para>
+
+ </section>
+
+ <section>
+ <title>Summary</title>
+
+ <para>
+ 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 <quote>Bugs</quote>, <quote>FAQ</quote>, etc. The
+ following items should be available in the web site:
+ <itemizedlist>
+ <listitem>
+ <quote>How to contribute?</quote> or <quote>Getting involved</quote>
+ </listitem>
+ <listitem>
+ List of tasks
+ </listitem>
+ <listitem>
+ List of sources of information (mailing lists, newsgroup, ...)
+ </listitem>
+ <listitem>
+ FAQ
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ As with the other documents summarizing what is happening here
+ at GimpCon, comments are welcome...
+ </para>
+
+ <para>
+ Written by Raphaël Quinet
+ </para>
+
+ </section>
+
+</webpage>
diff --git a/content/conferences/gimpcon/2003/gimpcon2003-mins.md
b/content/conferences/gimpcon/2003/gimpcon2003-mins.md
new file mode 100644
index 0000000..f1c68eb
--- /dev/null
+++ b/content/conferences/gimpcon/2003/gimpcon2003-mins.md
@@ -0,0 +1,144 @@
++++
+author = "The GIMP Development Team"
++++
+
+ <title>Minutes of The GIMP Developers Conference 2003</title>
+ <titleabbrev>Minutes</titleabbrev>
+ <summary>Minutes of the GIMPCon 2003 Meetings</summary>
+ </head>
+
+ <para>
+ 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.
+ </para>
+
+ <section>
+ <title>The First Big Serious Meeting</title>
+
+ <para>
+ This meeting was held in the evening of August 7th, 2003. The main
+ issues discussed were:
+ <itemizedlist>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-1"
+ localinfo="foundation">The GIMP foundation</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-1"
+ localinfo="manager">Release manager</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-1"
+ localinfo="decisions">Decision making (or lack of
+ it)</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-1"
+ localinfo="general">General stuff about CVS,
+ Bugzilla</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-1"
+ localinfo="communication">Communication</olink>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ The minutes from this meeting can be found <olink
+ targetdocent="gimpcon2003-mins-1">here</olink>.
+ </para>
+
+ </section>
+
+ <section>
+ <title>The Second Big Serious Meeting</title>
+
+ <para>
+ This meeting was held in the evening of August 8th, 2003. The
+ main issues discussed were:
+ <itemizedlist>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-2"
+ localinfo="features">Features required for 2.0</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-2"
+ localinfo="documentation">Documentation</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-2"
+ localinfo="web">Web-site</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-2"
+ localinfo="roadmap">Roadmap</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-2"
+ localinfo="bugs">Bugs</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-2"
+ localinfo="tasks">Task List</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-2"
+ localinfo="foundation">GIMP Foundation</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-2"
+ localinfo="manager">Release manager</olink>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ The minutes from this meeting can be found <olink
+ targetdocent="gimpcon2003-mins-2">here</olink>.
+ </para>
+
+ </section>
+
+ <section>
+ <title>The Third Big Serious Meeting</title>
+
+ <para>
+ This meeting was held in the afternoon of August 9th, 2003. The
+ main issues discussed were:
+ <itemizedlist>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-3"
+ localinfo="developers">How to get new
+ developers?</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-3"
+ localinfo="binary">De we need binary
+ distributions?</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-3"
+ localinfo="bugzilla">Is Bugzilla too hard to use for new
+ users?</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-3"
+ localinfo="tasks">List of open tasks</olink>
+ </listitem>
+ <listitem>
+ <olink targetdocent="gimpcon2003-mins-3"
+ localinfo="mailinglists">Mailing lists</olink>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para>
+ The minutes from this meeting can be found <olink
+ targetdocent="gimpcon2003-mins-3">here</olink>.
+ </para>
+
+ </section>
+
+</webpage>
diff --git a/content/conferences/gimpcon/2003/people-small.png
b/content/conferences/gimpcon/2003/people-small.png
new file mode 100644
index 0000000..c921c9c
Binary files /dev/null and b/content/conferences/gimpcon/2003/people-small.png differ
diff --git a/content/conferences/gimpcon/2003/people.png b/content/conferences/gimpcon/2003/people.png
new file mode 100644
index 0000000..a141b84
Binary files /dev/null and b/content/conferences/gimpcon/2003/people.png differ
diff --git a/content/conferences/gimpcon/2004/Dave_Neary.jpg b/content/conferences/gimpcon/2004/Dave_Neary.jpg
new file mode 100644
index 0000000..33f5c8d
Binary files /dev/null and b/content/conferences/gimpcon/2004/Dave_Neary.jpg differ
diff --git a/content/conferences/gimpcon/2004/Oyvind_Kolas.png
b/content/conferences/gimpcon/2004/Oyvind_Kolas.png
new file mode 100644
index 0000000..4aad64c
Binary files /dev/null and b/content/conferences/gimpcon/2004/Oyvind_Kolas.png differ
diff --git a/content/conferences/gimpcon/2004/_index.md b/content/conferences/gimpcon/2004/_index.md
new file mode 100644
index 0000000..0142cb7
--- /dev/null
+++ b/content/conferences/gimpcon/2004/_index.md
@@ -0,0 +1,296 @@
++++
+title = "GIMP Developers Conference 2004"
+abbrev = "GIMPCon 2004"
+description = "GUADEC, Kristiansand"
+author = "The GIMP Development Team"
++++
+
+The GIMP Developers Conference 2004 was held as a sub-event
+ of <ulink url="http://2004.guadec.org";>GUADEC 5</ulink> in
+Kristiansand, Norway, on the 28th, 29th and 30th of June.
+
+## GIMP related talks at GUADEC
+
+ Programming a GIMP Plug-in — Dave Neary
+
+ <para role="images">
+ <ulink url="mailto:bolsh NOSPAM gimp org">
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="Dave_Neary.jpg"/>
+ </imageobject>
+ <textobject>
+ <phrase>Dave Neary</phrase>
+ </textobject>
+ </mediaobject>
+ Dave Neary
+ </ulink>
+ </para>
+
+ <para>
+ Dave Neary's been hanging around free software for about 6
+ years. He started off as a leech, and then decided to turn into
+ a leechee sometime around 1999, when he started working on the
+ GIMP. His main interest in the GIMP is revitalising the
+ relationship betweek the user and developer communities. He has
+ also helped out a little now and again on other things, and is
+ listed as a co-author of gnect.
+ </para>
+ <para>
+ He is currently living and working in Lyon, France.
+ </para>
+
+ <para>
+ Custom widgets in GtkCairo — Øyvind Kolås
+ </para>
+
+ <para role="images">
+ <ulink url="mailto:pippin NOSPAM gimp org">
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="Oyvind_Kolas.png"/>
+ </imageobject>
+ <textobject>
+ <phrase>Øyvind Kolås</phrase>
+ </textobject>
+ </mediaobject>
+ Øyvind Kolås
+ </ulink>
+ </para>
+
+ <para>
+ Øyvind is working on an application called Bauxite, which
+ uses a node-based data structure similar to GEGL This
+ application is both a standalone video editor and a
+ comprehensive test bed of GEGL's node structrues.
+ </para>
+ <para>
+ Øyvind is also working on the next generation XCF format.
+ </para>
+ <para>
+ His primary interests in the GIMP is graph compositing.
+ </para>
+ </section>
+
+ <section>
+ <title>Other graphics talks at GUADEC</title>
+
+ <itemizedlist>
+ <listitem>
+ Typography and graphic design for programmers —Liam Quin
+ </listitem>
+ <listitem>
+ The future of rendering in GNOME — Owen Taylor
+ </listitem>
+ <listitem>
+ GStreamer Internals — Benjamin Otte
+ </listitem>
+ <listitem>
+ Digital Photography in a GNOME Environment — Hubert Figuiére
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section>
+ <title>Sponsors</title>
+
+ <para>
+ Many thanks to our generous sponsors, without whom GIMPCon
+ would not be possible:
+ </para>
+
+ <para role="framelessimages">
+ <ulink url="http://www.fsf.org";>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="gnu-head-sm.jpg"/>
+ </imageobject>
+ <textobject>
+ <phrase>The Free Software Foundation</phrase>
+ </textobject>
+ </mediaobject>
+ The Free Software Foundation
+ </ulink>
+ </para>
+
+ <para>
+ The Free Software Foundation has consistently been the greatest
+ supporter of the GIMP project, and has been the primary sponsor
+ of each of the three GIMP Conferences which we have held. Many
+ thanks go out to RMS and everyone else at GNU.
+ </para>
+
+ <para role="framelessimages">
+ <ulink url="http://www.macgimp.com";>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="mac_gimp_logo4.png"/>
+ </imageobject>
+ <textobject>
+ <phrase>MacGIMP</phrase>
+ </textobject>
+ </mediaobject>
+ MacGIMP
+ </ulink>
+ </para>
+
+ <para>
+ Mat Caughron sells the GIMP commercially with support and
+ documentation, and has been generous on each occasion we have
+ asked for his support.
+ </para>
+ <para>
+ The GIMP is also fortunate to have a community of supporters who
+ have donated smaller amounts to the project. Many thanks go out
+ to all those supporters. More information on how to donate to
+ the GIMP is available on <ulink
+ url="http://www.gimp.org/donating/";>the GIMP home page</ulink>.
+ </para>
+ </section>
+
+ <section>
+ <title>GIMP conference activities</title>
+
+ <para>
+ The GIMP Developers Conference, also known as GIMPCon, is a
+ gathering of GIMP and GEGL developers from all over the
+ World. It is a vital opportunity for the GIMP developers to meet
+ each other and discuss the direction which the software will
+ take over the coming years.
+ </para>
+
+ <para>
+ There have been two GIMP Conferences previously, both in Berlin,
+ and both graciously hosted by the CCC (the Chaos Computer Club),
+ a much less chaotic bunch of guys than their name suggests.
+ </para>
+ </section>
+
+ <section>
+ <title>The GIMP Developers Conference 2003</title>
+
+ <para role="images">
+ <ulink url="../2003/people.png">
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="../2003/people-small.png"/>
+ </imageobject>
+ <textobject>
+ <phrase>The People at GimpCon 2003</phrase>
+ </textobject>
+ </mediaobject>
+ </ulink>
+ </para>
+
+ <para>
+ Last year's GIMP Conference was a sub-event of the Chaos
+ Communications Camp, a camping trip with broadband and
+ laptops. During the camp, we discussed ways we could make the
+ GIMP better both technically and as a community, which led up to
+ the 2.0 release at the end of March.
+ </para>
+
+ <para>
+ At this year's conference we will discuss, among other things,
+
+ <itemizedlist>
+ <listitem>
+ What we expect from a replacement for the PDB (Procedural
+ Database)
+ </listitem>
+ <listitem>
+ How we will integrate GEGL into the GIMP
+ </listitem>
+ <listitem>
+ Managing plug-in distribution
+ </listitem>
+ <listitem>
+ The GIMP's organisation
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section>
+ <title>The GIMP, Live!</title>
+
+ <para>
+ Two of our resident graphics designers, Jakub Steiner (jimmac)
+ and Tuomas Kuosmanen (tigert) are giving a user-day GIMP
+ demonstration on Wednesday. Last year, jimmac presented a series
+ of tutorials on basic GIMP techniques to a crowd of over 100
+ people, and held them captivated for nearly 3 hours.
+ </para>
+
+ <para>
+ This is an opportunity to see what the GIMP can do in the hands
+ of professionals, and to pick up some tips for your own use. A
+ spectacle not to be missed.
+ </para>
+ </section>
+
+ <section>
+ <title>About the GIMP</title>
+
+ <para>
+ Started in 1995 by Spencer Kimball and Peter Mattis, the GIMP
+ has evolved into a mature and powerful application. The current
+ release is version 2.0, which has major improvements over its
+ predecessors in the user interface, making the GIMP more
+ accessible for casual users as well as graphics professionals.
+ </para>
+
+ <para role="images">
+ <ulink url="http://www.gimp.org/screenshots/macosx_screenshot1.png";>
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="macosx_screenshot1_thumb.jpg"/>
+ </imageobject>
+ <textobject>
+ <phrase>GIMP on the Mac OS X operating system</phrase>
+ </textobject>
+ </mediaobject>
+ GIMP on the Mac OS X operating system
+ </ulink>
+ </para>
+
+ <para>
+ GIMP is expandable and extensible. It is designed to be
+ augmented with plug-ins and extensions which allow access to its
+ capabilties via a number of languages. The advanced scripting
+ interface allows everything from the simplest task to the most
+ complex image manipulation procedures to be easily scripted.
+ </para>
+
+ <para>
+ The software comes with lots of features, some are newly
+ implemented and available with the 2.0 Release. A short list
+ over the most interesting features are:
+
+ <itemizedlist>
+ <listitem>
+ a full suite of tools for painting and image manipulation
+ </listitem>
+ <listitem>
+ preview of brush outline while you're drawing
+ </listitem>
+ <listitem>
+ customizable interface using a drag-and-drop dockable
+ </listitem>
+ <listitem>
+ advanced scripting capabilities (Scheme, Python, Perl)
+ </listitem>
+ <listitem>
+ over 100 plug-ins available as standard
+ </listitem>
+ <listitem>
+ fullscreen mode and view filters
+ </listitem>
+ <listitem>
+ much, much more!
+ </listitem>
+ </itemizedlist>
+
+* <ulink url="http://2004.guadec.org";>The main GUADEC website</ulink>
+* <ulink url="http://www.hia.no/oksam/inf-vit/travel.php3";>Getting there</ulink>
+* <ulink url="http://www.hia.no/oksam/inf-vit/accomodation.php3";>Accommodation </ulink>
diff --git a/content/conferences/gimpcon/2004/gnu-head-sm.jpg
b/content/conferences/gimpcon/2004/gnu-head-sm.jpg
new file mode 100644
index 0000000..49502c7
Binary files /dev/null and b/content/conferences/gimpcon/2004/gnu-head-sm.jpg differ
diff --git a/content/conferences/gimpcon/2004/mac_gimp_logo4.png
b/content/conferences/gimpcon/2004/mac_gimp_logo4.png
new file mode 100644
index 0000000..d96f370
Binary files /dev/null and b/content/conferences/gimpcon/2004/mac_gimp_logo4.png differ
diff --git a/content/conferences/gimpcon/2004/macosx_screenshot1_thumb.jpg
b/content/conferences/gimpcon/2004/macosx_screenshot1_thumb.jpg
new file mode 100644
index 0000000..aa0fb1b
Binary files /dev/null and b/content/conferences/gimpcon/2004/macosx_screenshot1_thumb.jpg differ
diff --git a/content/conferences/gimpcon/2006/_index.md b/content/conferences/gimpcon/2006/_index.md
new file mode 100644
index 0000000..70e3a41
--- /dev/null
+++ b/content/conferences/gimpcon/2006/_index.md
@@ -0,0 +1,542 @@
++++
+author = "The GIMP Development Team"
++++
+
+ <title>GIMP Developers Conference 2006</title>
+ <titleabbrev>GIMPCon 2006</titleabbrev>
+ <summary>Libre Graphics Meeting, Lyon</summary>
+ </head>
+
+ <para>
+ The GIMP Developers Conference 2006 was held as a sub-event
+ of the <ulink url="http://www.libregraphicsmeeting.org";>Libre
+ Graphics Meeting</ulink> in Lyon, France, on the 17th, 18th and
+ 19th of March.
+ </para>
+
+ <para role="images">
+ <ulink url="people.jpg">
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="people_small.jpg"/>
+ </imageobject>
+ <textobject>
+ <phrase>The People at GIMPCon 2006</phrase>
+ </textobject>
+ </mediaobject>
+ </ulink>
+ </para>
+
+ <section>
+ <title>About the GIMP Developers Conference</title>
+
+ <para>
+ The GIMP Developers Conference, also known as GIMPCon, is a
+ gathering of GIMP and GEGL developers from all over the
+ World. It is a vital opportunity for GIMP developers to meet
+ each other and discuss the direction which the software will
+ take over the coming years.
+ </para>
+
+ <para>
+ There have been four GIMP Conferences previously: two in Berlin,
+ Germany hosted by the CCC (the Chaos Computer Club), one in
+ Kristiansand, Norway as part of GUADEC 2004 and one in
+ Stuttgart, Germany as part of GUADEC 2005.
+ </para>
+
+ </section>
+
+ <section>
+ <title>Minutes of the GIMP Developers Conference 2006</title>
+
+ <para>
+ During LGM, we had two sessions dedicated to GIMP: one on
+ Saturday afternoon (16:30-18:00) and one on Sunday
+ (10:30-16:00). The following points were on the agenda:
+
+ <itemizedlist>
+ <listitem>
+ <link linkend="gimp24">GIMP 2.4</link>
+ </listitem>
+ <listitem>
+ <link linkend="documentation">Documentation</link>
+ </listitem>
+ <listitem>
+ <link linkend="gimp299">GIMP 2.99</link>
+ </listitem>
+ <listitem>
+ <link linkend="developers">How to get more GIMP developers?</link>
+ </listitem>
+ <listitem>
+ <link linkend="vision">GIMP vision</link>
+ </listitem>
+ </itemizedlist>
+ </para>
+
+ <para role="images">
+ <ulink url="meetings.jpg">
+ <mediaobject>
+ <imageobject>
+ <imagedata fileref="meetings_small.jpg"/>
+ </imageobject>
+ <textobject>
+ <phrase>Discussions and presentations at GIMPCon 2006</phrase>
+ </textobject>
+ </mediaobject>
+ </ulink>
+ </para>
+
+ </section>
+
+ <section id="gimp24">
+ <title>GIMP 2.4</title>
+
+ <section>
+ <subtitle>SIOX</subtitle>
+
+ <para>Gerald explained the current status of SIOX and its future
+ developments:
+
+ <itemizedlist>
+ <listitem>
+ There are still some performance concerns because SIOX was
+ designed mainly for web-sized images. In the morning,
+ Raphaël suggested a way to add a low resolution preview
+ for large images and this feature will be implemented
+ soon.
+ </listitem>
+ <listitem>
+ Implement a detail refinement brush. Simon suggested to
+ apply the refinement automatically on the edge area, but
+ Gerald replied that defining such an area assumes that the
+ shape is simple, which is something that SIOX tries to
+ avoid.
+ </listitem>
+ <listitem>
+ New preview toggle, which temporarily disables the
+ automatic computation for multiple brush strokes for
+ example.
+ </listitem>
+ <listitem>
+ A volunteer for integrating more SIOX features in GIMP
+ is needed.
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section>
+ <subtitle>New tools</subtitle>
+
+ <para>
+ <itemizedlist>
+ <listitem>
+ Sven pointed out that the rectangular and ellipse selection
+ tools should have the same behavior.
+ </listitem>
+ <listitem>
+ The new align tool is also confusing for some users. Its
+ behavior is still too flaky. Sven mentioned that Peter
+ Sikking may be able to help in determining what the users
+ want. A session with Peter is planned for tomorrow (the
+ <link linkend="vision">vision discussion</link>).
+ </listitem>
+ <listitem>
+ The code for the Lanczos interpolation is currently
+ broken. Either we fix the Lanczos code or we hide it from
+ the 2.4 release by removing it from the UI and from the
+ PDB.
+ </listitem>
+ </itemizedlist>
+ </para>
+ </section>
+
+ <section>
+ <subtitle>Google's Summer of Code</subtitle>
+
+ <para>
+ Dave pointed out that the Summer of Code is coming soon and
+ ideas are needed. GIMP is one of the projects which can offer
+ tasks to be solved.
+ </para>
+ <para>
+ Ideas and Tasks are needed soon, probably around the beginning
+ of May.
+ </para>
+
+ </section>
+
+ <section>
+ <subtitle>Preparation for the 2.4 release</subtitle>
+
+ <para>
+ Michael pointed out that some terms in the GIMP UI uses are
+ misleading and very different from other image manipulation
+ programs. One example is the misleading dpi instead of ppi.
+ </para>
+
+ <para>
+ Michael proposed a Texttool PDB and also new features: multiple
+ styles for a line of text, more control over text.
+ Unfortunately, GIMP does not currently support all pango
+ features. Sometimes ligature problems occur with Bitstream
+ Vera Sans.
+ </para>
+
+ <para>
+ Various other issues were also discussed: undo handling of
+ vector operations, improvements to the full screen mode (some
+ plug-ins cannot display progress bars), etc.
+ </para>
+
+ <itemizedlist>
+ <title>TODO</title>
+ <listitem>
+ <para>
+ A list of blocker bugs for the 2.4 release is needed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A string and UI freeze is needed.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Mitch's cleanup should not be commited before the 2.4
+ release.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Volunteers are needed for checking GIMP terms (English and
+ translations). A wiki page should track the terms and also
+ possible translations. One volunteer should elaborate if
+ Rosetta from Ubuntu can be used for this.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A bug is needed for plug-ins which use g_message() and where
+ dialogs pop up behind the main window.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ A volunteer is needed for the Texttool PDB.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+ </section>
+
+ <section id="documentation">
+ <title>Documentation</title>
+
+ <para>
+ The manual currently features nine languages, five are activly
+ worked on. Russian and Norwegian will be added after the 0.10
+ release. DocBook/XML is a barrier for new contributors, but there
+ is currently no valuable alternative available.
+ </para>
+
+ <para>
+ For PDF creation we should use dblatex instead of the dead project
+ db2latex.
+ </para>
+
+ <para>
+ The more translation an XML file holds the more difficult it is
+ for contributors to concentrate on their content. Maybe we should
+ split up the content directory-wise instead of profiling.
+ </para>
+
+ <para>
+ Michael proposed way users can comment on HTML pages like the PHP
+ documentation. The problems are: what will happen to comments
+ after an update of the documentation, how and who manages
+ comments, which system will suit our needs.
+ </para>
+
+ <itemizedlist>
+ <title>TODO</title>
+ <listitem>
+ <para>
+ Stick to DocBook/XML for the next year. Be aware of the
+ problems and change to a different internal structure if
+ needed. A new project page should make it easier to
+ contributors to join the project.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Elaborate which issue tracker can lower the barriers for
+ feedback from our readers without turning it into a
+ discussion forum that needs active moderation.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section id="gimp299">
+ <title>GIMP 2.99</title>
+
+ <section>
+ <subtitle>GEGL</subtitle>
+
+ <para>
+ Pippin pointed out that GEGL does not yet support calculation
+ over regions of interest. Some of the code that does that is
+ currently 8-bits only, but the reference buffer implementation
+ would be 32bits float per pixel. Yosh proposed to generate all
+ the code needed for this from a template.
+ </para>
+
+ <para>
+ Pippin: GEGL is undead.
+ </para>
+
+ <para>
+ Mitch suggested that the integration of GEGL should be in small
+ steps. The plug-in API should be GEGL only, but will provide
+ backwards compatibility from old plug-ins for 8bits only.
+ </para>
+
+ <para>
+ UI and Usability problems are also caused by the indexed mode.
+ We concluded that it should be available if the user exports
+ his image to an indexed format, like GIF or PCX. For some indexed
+ images, the order of the colors in the palette is significant.
+ Raphaël proposed to handle these images through GEGL as 16bits
+ images with the 8 least significant bits representing the
+ original palette index so that it can be restored later when
+ saving. Gerald mentioned that Apple may already be doing
+ something similar.
+ </para>
+
+ <itemizedlist>
+ <title>TODO</title>
+ <listitem>
+ <para>
+ Write the 32bits float version first, then generate others
+ from that reference version.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Replace the code in the base directory by GEGL operations.
+ First replace the image map tool (used for color correction,
+ etc.) using GEGL adapters around the pixel buffers. Then
+ later replace the layers and masks.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+ </section>
+
+ <section id="developers">
+ <title>How can we motivate people to join the GIMP development?</title>
+
+ <para>
+ The current project page for gimp.org is not really structured and
+ not very easy to get in touch with the developers. It would
+ help to show to the potential contributers a list of tasks that
+ GIMP developers consider relatively easy and useful for the
+ next version. We could also use the task list for the Google
+ Summer of Code or for bounties, etc.
+ </para>
+
+ <para>
+ We should make sure that people feel welcome when they read the
+ GIMP mailing lists. For example, we should avoid criticizing
+ those who mention GimpShop or commercial programs such as
+ Photoshop.
+ </para>
+
+ <para>
+ Some suggestions were discussed, such as introducing aging in
+ the list of GIMP authors. The About dialog would first list
+ those who contributed to the current version and then a longer
+ list of previous contributers. Sven and Yosh remarked that we
+ are not really using the mailing lists for discussing GIMP
+ development. Most of the discussion happens on IRC or directly
+ between people. This could be improved. There was also some
+ debate about how to avoid pointless discussions on the gimp-web
+ mailing list.
+ </para>
+
+ <itemizedlist>
+ <title>TODO</title>
+ <listitem>
+ <para>
+ Setup a tasks list on the wiki of what can be achieved and
+ implemented. It ranges from easy to very complex tasks. Each
+ task should be linked to a bugzilla bug report. If someone
+ starts working on one of these tasks, its bug report should
+ be marked as ASSIGNED.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Improve the infrastructure for the web site and try to make
+ contributions easier: simpler installation and testing, if
+ possible without requiring special skills or permissions.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section id="vision">
+ <title>GIMP vision</title>
+
+ <para>
+ Peter Sikking helped us to formulate a product vision for GIMP.
+ The vision helps to define what standard installation of the
+ GIMP is: what plug-ins are standard and what plug-ins are
+ optional. It shouldn't be a simple cost-and-benefit analysis of
+ what it means to support a feature. The current problem of the
+ product vision is too broad to be practical. Peter proposes that
+ our product vision should address a kind of Gauss curve of what
+ users GIMP is made for. Currently we have the experts and newbies,
+ but a low point for the intermediates.
+ </para>
+
+ <para>
+ Good defaults would be chosen depending on our vision, not
+ by inventing new scenarios for each thing that we want to
+ evaluate. The user scenarios would be written down in advance.
+ These scenarios should not be changed afterwards because it would
+ lead to too much discussion. The goal is to cut down all this
+ discussion. <emphasis role="bold">The product vision is to be used
+ as a filter.</emphasis>
+ For example: If someone comes with the request that the UI of GIMP
+ should be like Photoshop, we can simply state: <quote>We are not
+ trying to be like Photoshop, because we have a different product
+ vision.</quote> Though, the feature requests should still be
+ examined carefully.
+ </para>
+
+ <section>
+ <subtitle>Targeted user base</subtitle>
+
+ <para>
+ GIMP targets experienced users. If we acknowledge that GIMP is
+ not (primarily) for beginners, we cut off a lot of problems
+ such as <quote>do we need to support that,</quote> etc. Peter
+ noted that a <quote>GIMP Light</quote> would not just have
+ some options cut off from the menus: it would have a
+ completely different user interface, even if it would use the
+ same code under the hood.
+ </para>
+
+ <para>
+ Some developers work on GIMP to promote the Free Software
+ movement and would probably not contribute if GIMP was not
+ free. Others think that GIMP should provide fun for its
+ developers, although our user base has grown a bit large for
+ just doing fun experiments. We have to acknowledge that we
+ address a user base that may be more experienced in image
+ manipulation than we are, so the developers are partially out
+ of the target group.
+ </para>
+
+ <para>
+ Before converging towards a definition of the GIMP target
+ groups and GIMP vision, there were several discussions
+ involving examples and use cases, whether GIMP should be the
+ best image manipulation program in the universe (best for
+ who?), whether those working on icons and those working on
+ photos have the same needs (number of images open, relative
+ sizes), whether people need to switch frequently between GIMP
+ and other applications (browser or editor for web work),
+ whether we will support painting with shapes and natural
+ media, etc.
+ </para>
+
+ <para>
+ Eventually, a GIMP vision emerged...
+ </para>
+ </section>
+
+ <section>
+ <subtitle>What GIMP is:</subtitle>
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ GIMP is Free Software
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GIMP is a high-end photo manipulation application, and
+ supports creating original art from images;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GIMP is a high-end application for producing icons,
+ graphical elements of web pages, and art for user interface
+ elements;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GIMP is a platform for programming cutting edge image
+ processing algorithms, by scientists and artists;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GIMP is user-configurable to automate repetitive tasks;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GIMP is easily user-extendable, by easy installation
+ of plug-ins.
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section>
+ <subtitle>What GIMP is not:</subtitle>
+
+ <itemizedlist>
+ <listitem>
+ <para>GIMP is not MS Paint or Adobe Photoshop</para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <itemizedlist>
+ <title>TODO</title>
+ <listitem>
+ <para>
+ Make it easier to perform repetitive tasks (macro recording)
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Provide a UI with a low barrier to entry
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ GIMP should be easily extensible by the average user: one
+ click-installation of plug-ins
+ </para>
+ </listitem>
+ </itemizedlist>
+ </section>
+
+ <section>
+ <para>
+ Minutes written by Roman Joost and Raphaël Quinet. Photos by
+ Jean + Karine Delvare and Raphaël Quinet.
+ </para>
+ </section>
+
+</webpage>
diff --git a/content/conferences/gimpcon/2006/meetings.jpg b/content/conferences/gimpcon/2006/meetings.jpg
new file mode 100644
index 0000000..fbc7660
Binary files /dev/null and b/content/conferences/gimpcon/2006/meetings.jpg differ
diff --git a/content/conferences/gimpcon/2006/meetings_small.jpg
b/content/conferences/gimpcon/2006/meetings_small.jpg
new file mode 100644
index 0000000..4974a6a
Binary files /dev/null and b/content/conferences/gimpcon/2006/meetings_small.jpg differ
diff --git a/content/conferences/gimpcon/2006/people.jpg b/content/conferences/gimpcon/2006/people.jpg
new file mode 100644
index 0000000..beb4a57
Binary files /dev/null and b/content/conferences/gimpcon/2006/people.jpg differ
diff --git a/content/conferences/gimpcon/2006/people_small.jpg
b/content/conferences/gimpcon/2006/people_small.jpg
new file mode 100644
index 0000000..09a9b7f
Binary files /dev/null and b/content/conferences/gimpcon/2006/people_small.jpg differ
diff --git a/content/conferences/gimpcon/_index.md b/content/conferences/gimpcon/_index.md
new file mode 100644
index 0000000..8469c69
--- /dev/null
+++ b/content/conferences/gimpcon/_index.md
@@ -0,0 +1,19 @@
++++
+title = "GIMP Developer Conferences"
+abbrev = "Conference"
+description = "Hanging out with GIMP developers."
++++
+
+
+The GIMP Developers Conference, also known as GIMPCon, is a
+gathering of [GIMP](https://www.gimp.org) and
+[GEGL](https://www.gegl.org) developers from all
+over the World. This is where we get together and discuss the
+future development, hack on GIMP and meet GIMP users.
+
+* [GIMPCon 2000](gimpcon/2000), June 2-3-4 in Berlin, Germany.
+* [GIMPCon 2003](gimpcon/2003), August 7-8-9-10 in Berlin, Germany.
+* [GIMPCon 2004](gimpcon/2004), June 28-29-30 in Kristiansand, Norway.
+* GIMP meeting at GUADEC 2005, May 28-29-30-31 in Stuttgart, Germany.
+* [GIMPCon 2006](gimpcon/2006), March 17-18-19 in Lyon, France.
+
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]
![http://www.gimp.org/screenshots/macosx_screenshot1.png"](http://www.gimp.org/screenshots/macosx_screenshot1.png"){kind=link}