New wiki

[paul beard]

Hmm, is it about time for the Bike Shed link to be cited?

As a non-committer who has used MacPorts since it was DarwinPorts and used
Fink before that, here's my two shiny bits of something or other.

I wasn't aware there was large body of documentation to be migrated, so the
argument that a new syntax has to be mastered isn't all that strong.

As to whether or not this is the most important issue, that is up to each
person who uses this project. No one is suggesting that port hacking stop so
that documentation can be re-written. What I suspect will happen, if an
accessible format is chosen, is that more contributors will appear to do
that work. I considered doing some docs for DarwinPorts and FreeBSD but the
work was to be done in docbook, if memory serves, and that just didn't work
for me. I didn't want to learn a text formatting system just to document how
to use a port management system. If you want to examine prioritization,
there's an example: how much of a volunteer's scarce attention do you want
applied to productive work vs learning a toolset?

Perhaps in the review of page views/status, we could find out how many
people use the docs in place and how many use TRAC as a resource. I wasn't
aware of it as documentation repository so much as a ticket manager, and I
have not seen a lot of wiki syntax/formatting beyond using the {{{ }}}
markup to denote code or fixed-width output.

I agree that the best way to see if this is a good idea is to try it. As
often as useage tips appear on this list, it would make a lot of sense to
put them all in one place.

Maybe some docs on how to build from the MacPorts trunk, so we can access
all the bug fixes to 1.6, would be a good place to start?


-- 
Paul Beard / www.paulbeard.org/
<paulbeard at gmail.com/paulbeard at gmail.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.macosforge.org/pipermail/macports-users/attachments/20080611/830e05c3/attachment.htm