In DebConf25, a BOF was dedicated to discuss the state of the Debian Wiki. Known historical issues were summarized, in particular:

In the following days action was taken about this.

Contents

  1. Participating
  2. Communication
  3. Software migration
  4. Content licensing
    1. Choice of license
    2. Old content
    3. New content
  5. Other conversations
    1. Debian Bug Links
  6. See also

Participating

Want to help? See the section below on channels of communication. On IRC, you can ask how you can help and participate in discussions regarding migration and licensing.

Communication

The debian-wiki@lists.debian.org was created to discuss the Wiki, in addition to the #debian-wiki IRC channel. If you want to participate, you are encouraged to subscribe to both means of communication as discussions often occur on either one.

Software migration

During the BOF, the possibility of a migration to MediaWiki was brought up, a well-established wiki platform already being used by many others like !Wikipedia and the Arch Wiki.

Since then, @taavi has worked with DSA to setup mozart.d.o, a machine running Debian Trixie that hosts a MediaWiki instance. It can be accessed at https://wiki2025.debian.org/. Do not begin to migrate content here yet, it may be wiped without notice.

Currently, the plan is to migrate most pages to the MediaWiki instance using tools being developed by @guillem and @maytham, which will retain edit history as well as convert content to MediaWiki syntax as a final edit at the end. This is achieved by accessing the internal file-based database for MoinMoin. You can find a demonstration of this on FreedomBox (new wiki), where edit history has been retained.

Current resources for conversion:

The configuration and extensions for the new instance have not been finalised yet. @maytham is working on an extension to provide the Debian navbar that is present on many other Debian sites. New extensions require manual intervention by DSA, which can take some time, especially if they are not packaged.

See also: MediaWiki next steps

Content licensing

The migration provides a good opportunity to also deal with the long-standing licensing problems that mean content from the wiki cannot really be reused or redistributed legally. This should not stand in the way of the migration to MediaWiki though if it begins to take too long; migrating content between Debian servers should be fine, and the preservation of edit history will also help.

Choice of license

The Creative Commons Attribution-ShareAlike 4.0 license was agreed upon between participants in the mailing list and IRC because:

Why not public domain / CC Zero? The license chosen should generally require attribution. Virtually no content from other sources/sites could be copied to the wiki because nothing is compatible with public domain except other public domain content.

Why not Expat (MIT)? This license is intended for software. Licenses like the Creative Commons licenses were created specifically with non-software works in mind. Note that the Debian website (www.debian.org) uses this though.

Why not GFDL? In 2006, Debian Developers moved a General Resolution that concluded the GFDL is not a DFSG-compatible license, except when it is used without any of its invariant options. It is also much more restrictive, reducing the possibility of using wiki content elsewhere, like manual pages or official documentation.

Why not CC's NC or ND options? These are not DFSG-compatible.

See also: Re: Content licensing

Old content

@maytham is leading an ongoing relicensing effort to contact previous contributors and obtain permission for their work to be relicensed under CC BY-SA 4.0.

New content

Notices have been added to the current wiki so that any contribution submitted after 24 July 2025 00:00 UTC is released under the CC BY-SA 4.0, unless otherwise noted. A copyright.html page has also been written up with details on how to be compliant with the license

Other conversations

/!\ This section attempts to summarise conversations from the mailing list and IRC channel. It will always be somewhat out-of-date and incomplete.

The current wiki renders Debian and Ubuntu bugs specially - links get a title and closed bugs are struck through. For example, the following bugs should be struck through, and you should see a custom title when you hover over them: Debian Bug #399237 Launchpad bug 1597017.

This is implemented by including bugstatus.js in every page, which scans the HTML for appropriate links and sends requests to the bugstatus script and the launchpad script. The bugstatus script in turn uses the Debbugs SOAP interface, while the launchpad script uses launchpadlib.

MediaWiki alternatives to this solution include:

MediaWiki:Common.js is a JavaScript file included on every page in a wiki. This is the most direct translation, but can be hard to manage because of the temptation to put unrelated content in the same file.

The Gadgets extension is a more powerful alternative to MediaWiki:Common.js, and seems like the natural choice for a MediaWiki equivalent of the current implementation.

Scary Transcluding lets you include pages and templates from other wikis. Data is cached, with a configurable timeout. For example, this would let us run an internal service that generates HTML from some pre-existing Perl library, then transclude that HTML into ordinary wiki pages. It's the wrong tool for this particular job, but may be worth revisiting if other use cases pop up.

The Cargo extension lets MediaWiki store and query data in an internal database, which could potentially be synchronised with an external database somehow. But Cargo has a poor security reputation, and synchronising data could be awkward.

The External Data extension lets MediaWiki interrogate external sources like the Ultimate Debian Database. This would let us render links server-side instead of in JavaScript, but would introduce questions around caching. Allowing the wiki to query the UDD opens up a lot of interesting possibilities, and this might be a good way to make that possible. This is the solution we currently expect to use.

For more on this topic, see DebianBug links on the mailing list.

See also