Re: Setting up a wiki for GNU Project volunteers?

[Carlos O'Donell]

On Fri, Dec 13, 2019 at 11:00 AM Brandon Invergo <brandon@gnu.org> wrote:
> 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'm happy to publicly discuss having a wiki, and what concerns you have.

For example, if you are concerned about the content being confused for
official content, how might we resolve that?

Would a non-gnu.org URL suffice?

I am interested in your own opinion. I don't expect you to speak for others.

> > Where could we host a wiki like this without causing confusion with
> > official project content?
>
> Unless that decision changes, any wiki discussed here is necessarily
> unofficial and any proposed content is in no way implicitly endorsed or
> supported by the GNU Project.

I care about enabling GNU Project volunteers to do their best work.

I care about engaging with GNU Maintainers and building a stronger GNU
Project community.

> Personally, I've found that in most cases wikis are an inefficient means
> of active collaboration and discussion, that they accumulate outdated
> cruft too quickly for casual documentation to be anything more than
> ephemerally useful, and that they're too mutable for maintaining
> important documents.

I disagree that they are inefficient. We have efficiently used a wiki
in glibc, gcc, and gdb for almost a decade, and these are three of the
largest projects that are part of the GNU Project. It is exactly a
wiki's low-cost mutability that makes them useful.

When you say "important documents" you need to explain what aspects
are important to you. Just like saying something is "better" you have
to explain "better at what?" Are these documents important for policy
reasons? Are they important to developers day-to-day process?

> Any best practices, advice, etc. would be better
> placed in the coding standards or maintainers documents.  Active
> collaboration of small teams does not need a project-wide wiki and can
> be more efficiently achieved by ad hoc methods.  Core documentation of
> the project should only be on the main website, and by definition it
> should not be easy to change.

Not all documents have the same requirements.

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.

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.

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).

> Gnome's wiki is a perfect example of why it's a bad idea.

No. It is your opinion that it is a bad idea. Have you asked GNOME
developers if they find the wiki useful?

The top-level page and maintainer's pages have all seen updates in
2019, with notes that look valuable and useful to me.

> All this makes finding current and correct information about any details 
> about Gnome to be too difficult
> without having to carefully vet everything against other sources.

Not all documents have the same requirements.

Are you a user of GNOME? Looking for official GNOME documentation? Go
here: https://help.gnome.org/

Are you developing GNOME applications? Go here: https://developer.gnome.org/

Are you an existing GNOME developer? Working on FreeBST jhbuild? Go
here: https://wiki.gnome.org/Projects/Jhbuild/FreeBSD

Are you a new GNOME developer? Looking for a list of mailing lists to
subscribe to? https://wiki.gnome.org/Newcomers/BeforeWeBegin

The GNOME wiki is clearly a developer-focused wiki, so you can't call
it a bad idea that it doesn't succeed at needs it was never meant to
meet.

There are lots of pages on the GNOME wiki which are updated and
current and are clearly being used to keep GNOME developers in sync
and focused with summarized and useful information.

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.

In summary:
==========
- You make reference to a statement by Richard where he states he
doesn't want a GNU Project wiki.
- You state that any wiki not approved by Richard would be an unofficial wiki.
- You yourself think wikis are a bad idea.

Do you object strongly to GNU Project volunteers organizing and
creating a wiki for their use?

Cheers,
Carlos.