[OSM-talk] Things-To-Do Wiki Page

[Frederik Ramm]

Hi,

> I think you are completely wrong on this. If you look at any
> open-source project of a decent size, you will find that they all
> manage issues with some kind of bug tracking database. Those issues
> include bugs, but generally include requests for enhancement, wishlist
> items, and so on. It really is what trac (and other bug tracking
> systems) was designed for.

Agreed that a database-backed system with a nice representation layer  
(which trac, at least ours, doesn't offer) would top a wiki. But what  
I have in mind is not clear enough to be put into individual tickets.  
I am thinking something like (just an example!)

X. tilesAtHome

tilesAtHome (link) is a distributed rendering mechanism widely used  
today. The tiles for the slippy map (link) are created by renderers  
and uploaded to the server which also manages a request queue (link).  
Things that should be improved about tilesAtHome are

...

and then a list of things which may not necessarily be "atomic", i.e.  
it may be that some of them are best tackled together. I want them to  
be on one page, in a normal, human-written structure, with references  
("as written above, ...") and so on. And I also wanted to have  
element where people could add their weight, so that the importance  
of something was not determined by the guy who enters the ticket but  
by those who read it. And I wanted the page to also list "vacancies"  
like "we need someone who cleans up the wiki"...

> wikis are not a good place for transient information, and they are not
> intended for use as databases.

What I want is talk to humans, give them a properly written and well  
composed account of where we stand and what the issues are. A trac  
dump to a project novice is just rubbish without context, suitable  
only for experts.

> Perhaps trac needs some love to make it more approachable.

Then that can be the first item on the list: "Change trac so that  
lists like this can be generated from it" ;-)

It might be possible to use a wiki page to provide the context and  
the overall picture, and from there make references to trac tickets.  
That would have some difficulties of its own (status change in the  
trac ticket would not automatically change wiki), but could also  
merge the advantages of both - the smooth entry with quick overviews  
and pointers on the wiki, and then the "hard facts" in atomic trac  
tickets.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'