Website redesign (was Re: Please clear up DarwinPort/MacPorts
confusion)
Juan Manuel Palacios
jmpp at macports.org
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 macports.org 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).
Thoughts?
-jmpp
More information about the macports-dev
mailing list