Day: December 2, 2005

Wikis?

My NavData project is in serious danger of overwhelming my blog, and just having a comment section doesn’t seem like the best way to collaborate on the design (assuming I get any actual collaborators). I’m wondering if I should set up a Wiki for the design. Does anybody have any experience with Wikis? Can they suggest a good one for doing software design collaboration, and give me pointers on how to use it for that purpose?

How to do this?

Update: I’ve moved this discussion to the Wiki where Douglas Robertson started a conversation on a few other approaches.

One of the things I’d really like to do in this project is provide the capability for people to leverage the previous editors, but not allow them to accidentally or on purpose ruin the data. Thus I don’t want some random stranger to delete a DAFIF waypoint, or move KJFK to Timbuktu. So I was thinking that each editor would have a “dataset” of their own, but it’s based on previous datasets. There would be a heirarchy of datasets, with of course FAA and DAFIF data as the base, then an editor or end user could decide to include or exclude the other datasets based on whether that dataset intersects their area of interest, their perception of the dataset owner’s credentials, the recency of updates, or other criteria. Not sure exactly how to accomplish that. Maybe a rating system or a public comment area where another editor or an end user can say “Hey, this guy’s points are really inaccurate” or the editor himself could say “I didn’t type in the lat/longs from a publication, I just took my GPS to the airport fence”?

I don’t want an editor to be able to delete another person’s waypoint, but I also recognize that waypoints disappear or change names. So I think there needs to be a way in dataset “a” to indicate that waypoint “FOO” no longer exists. That way if you’re using dataset “a”, you won’t get waypoint “FOO”, but if you don’t trust “a” and so exclude it, you’ll still get “FOO”.