Note that we could switch the wiki.gnupg.org back to local authentification
(or any other authentification that moinmo.in provides, see https://moinmo.in/AuthMarket)
and continue using it.

As for the migration plans. I think we should decide which way to go. I see three possibilities:

1. migrate everything
2. migrate only a part, e.g. keep the development parts in the phabricator wiki and the user centric parts in wiki.gnupg.org.
3. migrate nothing

I'll send an email to gnupg-devel to inform the community of this discussion.

Mail send: https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033012.html

Ideas

• We shall decide how much history to keep. Usually it would be good to keep the history for transparency reasons, but for a number of pages it may not be necessary, they could be recreated.
• If we migrate a significant number of pages we should look into automatic conversion. There are several creole python parsers, so we should be able to write a transforming script with reasonable efforts.
• It is possible to easily use some integration from moinmo.in to phabricator and the other way round.
• If we decide to keep some contents on wiki.gnupg.org, we have an additional system to maintain, but also another system to be able to provide information.
• How long will Phabricator be in use? (Moinmo.in software has a 17 year history an a four year history with GnuPG/Gpg4win. Phabricator has 7 years of history and is run a few month for GnuPG.)
• The advantages of moving the Phabricator would be
  • Integration (what in particular? Updates when linking to issues?)
  • Only one wiki markup to learn for Devs.
  • Only one login.

Target audiences

• wiki.gnupg.org was a catch all: dev people, users, wider community, openpgp, end-to-end Free Software crypto.
• One idea would be to split a fraction of target groups and ony move them. Like the devs which would profit from the integration with phabricator a lot.
• A second idea: A refocus on users or Gpg4win or the wide community with the wiki.gnupg.org.
• A third idea: Another ways to split would be to say that the dev.gnupg.org wiki has the official infos and the wiki.gnupg.org is more open to people adding the infos (like wikipedia).

@marcus you've closed it while I was adding stuff. Where shall we document the way forward? In wiki.gnupg.org or https://dev.gnupg.org/w/ or in this task?

To avoid a single point of failure I would prefer to keep the wiki off from al-kindi and, if Intevation agrees, to keep it where it is.

Gathered information:

@marcus does not aim for migrating the wiki himself in the foreseeable future, thus we should reenable the wiki.gnupg.org as long as there is no clear plan -> T3342

@werner prefers that the wiki can run independently from dev.gnupg.org to avoid too much centralisation.

A single-sign on is potentially possible using https://secure.phabricator.com/book/phabcontrib/article/using_oauthserver/ to configured at https://dev.gnupg.org/oauthserver . Moinmoin can be configured to use local passwords as backup. If a cookie is used, a short blackout of dev.gnupg.org would possibly be okay as well.