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. _______________________________________________ Mapbender_dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/mapbender_dev
