Wiki

A wiki to provide documentation and feature planning for launchpad projects.

Contact: https://launchpad.net/~xaav/+contactuser
On Launchpad: https://bugs.launchpad.net/launchpad-project/+bugs?field.tag=wiki

Rationale

Almost every open source software project needs somewhere to publish hypertext on the web. This might be for end-user system documentation, for storing notes about how developers do things, for planning out features or for things as yet undreamt of by man or woman. Case in point, this document.

When people set about starting an open source software project, or consider moving one to Launchpad, they need some place to publish this hypertext. Launchpad currently does not provide such a place, and this often makes people decide not to use Launchpad.

As such, the lack of wikis is an adoption blocker for Launchpad, particularly given that we fall behind our rivals here. Thus we should provide a wiki.

Hosting a website on launchpad creates problems with XSS attacks and other security issues. Creating a wiki would eliminate, or greatly reduce this need, because users could place their site content on the wiki.

Stakeholders

This is a community driven project.

Launchpad product strategist
Launchpad technical architect

User stories

As a developer of an open source software project
I want a wiki
so that I can provide documentation to my users and plan my features more easily.

Constraints and Requirements

Must

Provide a wiki for each project
Either scale horizontally initially or have a feasible plan for such scaling
- Key points from the Ubuntu wiki / moin
  - Page layout on disk
  - Search
  - Page subscriptions / mail
  - Pages must be easily cached for anonymous users
Be free of single-points-of-failure
Provide core page management features
- Delete pages
- Rename pages
- Deprecate pages
- Revert pages to previous version
- See who changed a page and how
- See who is alerted when you change a page
Use a standard, existing markup language so that new users have less of a hurdle to learn Launchpad
Be cleanly integrated with the rest of Launchpad (Blueprints, announcements, and bugs may all link to related wiki pages.)
Be able to edit pages through the Launchpad web UI
Markup used on wiki should have same meaning in every chunk of user-entered text on Launchpad
Markup for easily linking to other elements of Launchpad (Use existing link parser that is used for bugs)
Allow users to subscribe to particular pages on wiki
Allow users to review and edit all of their wiki subscriptions
Lock down pages that are of particular importance or have become unusually controversial
Including images on wiki pages (png, jpg, svg)
Be able to link to pages on other wikis on Launchpad
Wikis for private projects must be private
Provide mechanisms for reporting abusive behaviour
Be obvious which project's wiki you are viewing / editing
Allow search
- by title
- for arbitrary page text
- for pages that link to a specific
  - wiki page
  - bug
  - person
  - blueprint
  - branch

Nice to have

Render Wiki pages from Bazaar branches (Specify which branch to render pages from)
A WYSIWYG editor for wiki pages
Page refreshless editing of wiki pages
A way to branch the wiki, hack locally, and merge the wiki back to Launchpad's version.
Printable versions of pages
Some kind of mass import system

Translation

Way for translating pages from one language into another
Using Launchpad Translations to do this or help do this
Way to see progress for wiki translation for languages I am interested in
Way to see progress for wiki translation for all languages

Must not

Require shell access for performing administration

Out of scope

Wikis for a project group – project groups are deprecated

Unsure

Multiple wikis per project
Wikis for teams
- They could just use the project wiki - That's like teams wanting their own bug tracker.
  - Some teams do want their own bug tracker, and teams already get their own space for branches -- jml <<Date(2011-05-26T12:21:53Z)>>
- For what? If a team is building something, it's better to put it on the project wiki. Getting too fragmented here may be a problem, it may be better to just consolidate everything to the project wiki.
Wikis for distributions
Wikis for source packages
Ability to control who can view pages on a sub-wiki (e.g. per-page) basis
Ability to control who can edit pages on a sub-wiki (e.g. per-page) basis
Custom styling
- No. Not a good idea at all; too many security holes here; risk of people using the display:none; property to hide stuff and mess up the page. Wikis are for information only; Launchpad isn't supposed to be pretty, just functional.
  - It works for blogger, wordpress, etc. Many people use wikis as their "shop front". A bigger concern is the usability impact of having something that looks completely different. -- jml <<Date(2011-06-21T14:53:00Z)>>

Success

How will we measure how well we have done?

Can Launchpad itself adopt the wiki service for its help and dev wikis?
How many projects have non-trivial content on their wikis?
How much traffic do the wiki pages get?
Does the addition of wikis change the Launchpad project adoption rate?

Thoughts?

jml is very, very keen to avoid repeating the mistakes we made with Loggerhead:
- Inconsistent visual appearance
- Chronic performance problems due to scale mismatch
- Poor integration with the rest of Launchpad
- Navigation from loggerhead once you're there
- Extra clicks to get to code browsing
- Hard to re-use loggerhead elements in existing code pages
- Had to do extra work to integrate with Launchpad's authentication and authorization

Implementation notes

URL should be in the format of http://wiki.launchpad.net/project-name/Wiki_page
- This has always been what I thought -- thumper 2011-05-22 23:49:55
  - I'd like to kill off subdomains entirely. -- jml @date@
    - Why? Please explain what you mean. -- xaav
      - They force us to create useless pages (e.g. https://code.launchpad.net/), they encourage us to orient our content around our data model rather than what the user needs and they make use of Launchpad slower due to extra SSL negotations
- Actually, I think we don't want to expose the Launchpad cookie to wiki content (for the same reason we don't expose the Launchpad
  cookie to librarian content or bzr branches). So that would suggest a separate domain and URLs like http://project-name.launchpadwikis.net/Wiki_page or http://launchpadwikis.net/project-name/Wiki_page -- flacoste 2024-04-19 13:19:34
- I don't think that that thats a necessary conclusion. At the LEP level 'be secure' is a requirement. On a implementation level we get to choose between allowing the wiki to render to arbitrary results or limiting what it can produce (so that we preserve the LP cookie). I think we should be guided by what we'd like in an ideal world in the first instance: the problems here are solvable.
- Alternatively, the URL could be https://project-name.launchpad.net/

Bazaar branch

Inherit permissions from a Bazaar code branch
- This is the best way to handle permissions if we are going to be tracking pages using bazaar anyways.
  - XXX: It's not trivially obvious that using the branch permissions would be the entire answer. -- RobertCollins
May use wikkid for wiki engine.
- -- RobertCollins - why? wikkid is cool but I don't see how we can say its the right choice until we understand why we're doing this. And I don't understand that yet.
  - -- Geoff - I posted that because the developer of that developed it in hope that he could get a wiki into launchpad; it meets all the requirements, and I don't see the point of recoding something that's already been done.
- Wikkid was designed from the start to do this. As the primary developer and maintainer of wikkid, I'd love to see it used in Launchpad as it was the initial impetus to get it going -- thumper 2011-05-22 23:49:55
We should blacklist the "wiki" name as a series name, to allow the definition of lp:project/wiki to refer to the wiki for a project.

launchpad development

LEP/Wiki