[Mapbender-dev] IRC Meeting ...

[Christoph Baudson]

Thanks for your comments, Michael. I want to add my thoughts to one topic

> - Change Request and Development: I think small change requests and
> enhancements should go directly into trac. There can even be small
> discussions about special matters of that ticket and direct linking to
> versions. For bigger changes (like OL or SLD) I find the workgroup
> pages plus trac tickets (link to versions) a good way. The workgroup
> pages provide a similar overview and detailed information as e.g. the
> MS RFCs. I would not make each point on the development page a
> milestone (not everyone can create milestones), rather only an
> enhancement ticket, that can subsequently be turned into a milestone,
> if it gets enough attraction.

You are right about the milestones. Milestones should be defined rarely. A
change request is not a milestone, contrary to my statement in the
meeting. A change request is better represented as a ticket.

My thoughts on Trac vs. Wiki concerning change requests:

I think Trac is a better choice for maintaining the change requests than
the Wiki. A huge advantage of Trac in comparison to Wiki is, that it's
easier to maintain and present the change requests. In a Wiki, a lot of
people might add content, but hardly anyone maintains the information. In
a way a Wiki is more powerful, yet harder to tame.

In Trac there are tickets and reports: A ticket is a singular task, bug or
change request with information in well-defined categories, like
description, priority, version, type (like "defect", "enhancement"),
keywords, owner, status. A report is a set of tickets, aggregated by
certain criteria. Example: all tickets which are assigned to me, ordered
by priority.

You can change information, simply by selecting an entry from a select
box, or clicking a button. This is much easier than editing text, where
the criteria how the text is structured might not be transparent. You can
easily manipulate reports to sort by date, by owner, etc. So the
information is also easier to find than in a Wiki.

How to represent the change requests in Trac:

Change requests could be tickets with the type "enhancement", but we are
also able to add other labels, f.e. "change request". Then we could create
a report in Trac that only displays these "change requests". The Wiki
could explain the Trac functionality and simply link to that report
(similar to the "bug fixes" link in "Version history"). (Note: We could
also add a Wiki page "Road map" which links to the milestone page of
Trac). We could use the priority in order to indicate how well the change
request is financed.

The challenge in using Trac in this context is IMHO to explain it to the
outside world. People hardly understand how to use the Wiki (or IRC), and
Trac is even weirder. The only thing people really understand is the
mailing list, so we should use this medium to teach the other media.
Before my vacation I had written a mail to the user list in order to
explain Trac; I believe it was well received. We should have these
tutorials in the Wiki, and once in a while post them. By this we could
also present the most important parts of the Wiki, which are sometimes
hard to find.

I think the mailing lists, especially the user list is the medium which
people are most familiar with, so we should utilize it in order to
establish the other media. (This would also include sending a link to the
latest IRC meeting log file).

Please add your opinion, I'm curious what others think.