Re: Setting up a wiki for GNU Project volunteers?

[Alfred M. Szmidt]

   > In the interest of public transparency and honesty, you should have
   > mentioned that Richard has already explicitly and unequivocally rejected
   > the proposal for a public, project-wide wiki.  Therefore, the following
   > question must be emphasized:

   Richard, as do you, have the right to reject anything you dislike.

   Do you have a public URL to Richard's statement?

I think what he wrote was quite clear, so there is little use to
persue the topic further.  A decision was made, so please respect
that.

   The "GNU Coding Standards" is a good example of a document that has no
   real official requirement to be followed, and my opinion is that it
   should have more liberal updates by programming language experts from
   the GNU Project volunteers with modern experience in the tooling used
   to develop such programs. I have no interest in proposing changes to
   the GCS unless and until it is publicly documented how the process of
   updates will work and who will review the changes and authorize their
   acceptance.

That process is already documented, and it is like with any other GNU
project, you talk to the maintainer, e.g, the GCS is maintained by
RMS.  If you wish to send improvments, or discuss changes to it you
can send that to bug-standards@gnu.org.

   Policy documents should absolutely live in very highly controlled
   repositories and go through a specifically crafted processes for
   change. We must follow many of the requirements in the "Information
   for maintainers of GNU software" and that document should be as clear
   as possible.

You say we must follow requirements and policies, but yet you
purposely rejected it when you removed text that was explcitly asked
to be kept by RMS in the glibc manual.  Which is it?

   Lastly, even small teams can make effective use of wikis. I have run a
   team of ~4 developers for a long time and we make effective use of
   wiki or wiki-like software for collaboration. My impression from the
   dozens of other developers I've spoken to on this topic indicates the
   same effective use of wikis. Most ad-hoc mechanisms boil down to using
   wiki-like software, either etherpad (which we could run too, and it's
   FOSS) or pastebin (available under CC0 for Stikked).

And others have run similar, and larger projects without wikis. 

I agree with Brandon, in that wikis are terrible for documentation
purposes, and think that the quality of the glibc/gcc/... manuals, for
example, has become much worse due to the fact that a wiki is being
used.  Much of it is very hard to navigate, and find relevant
information -- not to mention that one is required to have a network
connection.  And some parts might be very very wrong.  A good manual
takes concious effort to update, since a wiki doesn't it will always
be a much worse place for writing down things.

   I refute your claim that wikis are bad ideas. You personally may not
   like them and they may not suit your own developer needs, but that is
   not true for all developers.

The GCS, etc, are maintained by people who feel that they don't have a
use for a wiki or that it would be useful for the purpose.  GCC, the
GNU C library, are maintained by people who feel that a wiki is useful
for their purpose.  Today, we have a nice balance of people being able
to make things work for them, but you are trying to force everyone
into your workflow.