On Tue, Nov 11, 2008 at 10:16 AM, Josh Saddler <email@example.com> wrote:
> However, it's been quite awhile since the last time we (the GDP) talked
> it over. Given our current issues of manpower and time (see
> archives.gentoo.org for commit totals), perhaps a wiki could solve some
> The classic problems are:
> 1) Who has access
> 2) Who reports faulty articles
> 3) Who fixes them
> 4) Who verifies the article is correct
> 5) ???
> 6) Profit
I think we need to drop the incentive that the documentation on that
wiki is validated by a developer. The moment you work with
community-driven documentation, this is almost impossible to achieve.
In my opinion, the moment we would start a wiki, we use it for what it
is made for: community-driven documentation development.
However, I would use the following practices:
- Specific documentation that is "dangerous" to execute should have a
big red warning block, telling the users that this is not common
practice, is dangerous to execute, might result in yielding support
from developers, yada-yada. Examples of such topics could be
bootstrapping, editing portage code, specific C(XX)FLAGS, ...
- Translations of documentation are free to perform and should not be
reigned by rules such as "must be based upon a revision of the English
documentation". This does assume that the topic in the wiki is
- Wiki information pertaining to ~arch stuff should be in a different
namespace or some other way of destinguishing them (if not, even a tag
would help) that informs people that ~arch ebuilds are not tested
enough and can contain bugs
As manpower is important with wiki's (think of spam regulation), it
would be nice if we could tie forum accounts to wiki accounts, and
edits on the wiki are only allowed with accounts (no anonymous
editing). The moment a spammer occurs, account deletion should result
in some practice where all his/her edits are checked (I believe this
also occurs on forums, but I'm not sure).
Note that I'm not suggesting that forum admins should work on wiki's
too - if they want to, that's great, but it's a different playground
and I wouldn't want to push them into responsibilities they didn't ask