Website redesign (was Re: Please clear up DarwinPort/MacPorts confusion)

Juan Manuel Palacios jmpp at
Mon Apr 9 11:21:39 PDT 2007

On Apr 9, 2007, at 1:46 PM, Landon Fuller wrote:

> On Apr 9, 2007, at 10:17, markd at wrote:
>> But the disadvantage, as opposed to a Wiki, is that joe user can't 
>> make
>> changes to the docs. And that is what people want. Although I wonder 
>> if
>> we have Joe user contributing to the docs if it will really be 
>> better. It
>> may be, I just don't know.
> I've come across a number of projects using wiki documentation 
> lately. Lacking any centralized editing, it tends to vary wildly in 
> quality, substance, and style. Information is poorly organized and 
> difficult to find, and documentation is often duplicated.
> Maybe my experiences aren't a sufficiently representative example, but 
> I've been left with a very poor impression of open source wiki 
> documentation.
> -landonf

	One solution to this problem I was thinking about is a middle ground 
between requiring coding skills to allow you to edit a doc (if you have 
them, logic tells me you already hold a macports commit bit and 
therefore can edit the Wiki already.... or are not afraid to delve into 
Dockbook sources ;-) and giving access to everyone (open season on our 
Wiki, anyone can edit): said middle ground could be a WIKI_EDITING trac 
permission setting (or whatever to that effect) we could hand 
selectively to those who've proven an at least acceptably high 
knowledge of MacPorts; said people need not be skilled enough to commit 
to our repo and/or know how to edit docbook sources, but should at 
least be knowledgeable enough to know what they're talking about when 
writing documentation. We could receive nominations for such people and 
judge based on their activity on our lists, for instance, and maybe 
even the Wiki editor status could be seen as a step before gaining 
commit access to the repo (though not necessarily).



More information about the macports-dev mailing list