Ubuntu Wiki

Ubuntu Support and Learning Center Overview

The Ubuntu Support and Learning Center (USLC) will be an awesome, quality, dynamic website that acts as an online learning and support center for Ubuntu users to both solve their problems or work through tasks, and also to learn more about Ubuntu and how to contribute to it. The final site would involve material from the manual project, docs team, learning project and third party articles, split into well organized, topic based help using cutting edge web technologies like HTML5. The website would also collect information and feedback from the users on the usefulness of articles or individual paragraphs, so that we can constantly improve our material to make it the best quality we can.

Meetings

How it's gonna happen

In the Ubuntu Manual team meeting last week I shared some mockups of a plan for an online support website that uses the content we have in the manual, as well as adding some valuable tools for users to provide feedback and allowing us to offer more dynamic content such as videos.

The website would be split into two parts, an "Ubuntu support" section, and a "Learning Center." The support section would offer solutions to problems that users have, and provide instructions on how to do tasks. Think Chapters 1 - 5 in our manual, "Getting Started with Ubuntu 10.04." The Learning Center would have our "advanced" content that teaches users things beyond what they need to know for a basic, means to an end experience. This section would not only involve our content from Chapters 6 - 9, but also content submitted from the community could be uploaded and featured. Integration with the Learning/Classroom teams in the future would be fantastic and classes could be scheduled and managed through the Learning Center as well. It would also be nice to work with the people working on the Ubuntu Developers Manual to get their content into the Learning Center.

It will work as a type of "moderated wiki" where users can suggest changes to paragraphs or provide feedback in the form of a star rating system. This feedback would be sent to us and we could then make a decision whether to go ahead and implement the suggested changes or not. I think this strikes a good balance between a free for all wiki and "static" documentation.

The website is designed to be very user friendly and minimalistic so the reader isn't distracted from the main content and we should work closely with the Canonical training department and design team researchers so we can figure out exactly what users are having difficulty with and what questions they ask frequently.

The manual itself will be cut down for the next few releases so that it truly becomes a "Getting Started" guide and will not cover advanced topics at all. The advanced material will be available solely on the website, but will be stored in the same pool as the content from the manual so that translations can be done from the same place.

If you couldn't make the meeting, I highly recommend you read the log: http://irclogs.ubuntu.com/2010/05/06/%23ubuntu-meeting.html#t21:00

Project Requirements (DRAFT)

When considering a common format pool for various downstream users, we should be explicit about the following:

• Identify key users (individuals who represent the teams that consume the content) as stakeholders
• Make sure stakeholders have an "official" methodology of governance of the common content pool
• Allow stakeholders to identify their list of requirements
• Identify specific output formats, localization requirements, scheduling (string freeze, translation) requirements
• Identify a clear release management owner and process
• The tool chain must be sufficiently rich, and be proven/tested for converting the common content pool source format to the required delivery formats
• Common content pool must be able to be localized for both text and images
• Localization should only need to be done once (at the common content pool level.
• Downstream users should be able to add content while re-using existing localized content)
• The common content pool should have a methodology for commit control (who can commit, and how do others participate)
• The common content pool should use bzr and exist as an LP project with translations restricted to Ubuntu Translators
• Community portals should be identified and used (email list, LP project, LP team, other)
• Additionally, the development of the common content pool should be done 'in' the common pool, not done elsewhere (downstream - i.e., ubuntu-docs or ubuntu-manual) and then imported (upstreamed) into it.

Current Stakeholders and Delivery Formats For Each

• ubuntu-docs: mallard, xhtml, others?
• ubuntu-manual: A form of getting from the format of the content pool to latex files *.tex to turn into pdf, png's.
• ubuntu/canonical-training team: open-office present? pdf? (not sure)
• ubuntu-learning team: pdf, svg, png, text and code files for publishing. Svg, asciidoc for editing.
• ubuntu-translators: po files?

What source format(s) and toolchain(s) supports these proposed requirements?

Possible Syntaxes

Mallard

• Pros
  • Gnome upstream is moving to it
• Cons
  • Can't convert to latex
  • XML Based, hard to edit easy to break.
  • No GUI Editor
  • Can't do published document contexts.

Docbook

• Pros
  • Has rich markup for everything you typically find in a book.
  • Can convert to latex.
• Cons
  • Can't convert to mallard.
  • XML Based, hard to edit, easy to break.
  • No open source GUI Editor

DITA

• DITA xml content delivered via a web framework in a manner similar to this ( http://www.marklogic-news.com/images/MarkLogic_Flatirons_07_Using_DITA.pdf ).

  • Caveats: Neither DITA nor the DITA Open Toolkit are packaged for Ubuntu or Debian. (Currently, only OpenSUSE packages the two.) The toolchain (the DITA Open Toolkit) is well supported, though, and is under active development.
  • Authoring in DITA is not simple. Topics need to be well planned and content needs to be well-structured.

  • Debian has packaged Serna Free XML Editor, which includes DITA and the DITA-OT as part of the packaged binary. ( http://packages.debian.org/sid/serna ) This makes authoring a touch easier, but still not tremendously simple.

Initial List of Possible Frameworks (DRAFT)

Mozilla Sumo

Mozilla Sumo, the project behind support.mozilla.com. Code and build instructions are available via the Mozilla wiki.

A couple of caveats:

• It uses MySQL as the database backend, whereas Ubuntu is mostly a Postgres shop.

• The wiki syntax used is from TikiWiki, while Ubuntu uses MoinMoin.

• With regards to a "content pool," it's not immediately clear how any content written here could filter out to Ubuntu training documents or desktop help files.

Still, it seems to have pretty much all of the features that have been requested:

• Any registered user can contribute content, but content can be approved before going live on the site.
• Topic-based. Articles are built around answering users questions and helping users fix problems.
• Searchable (uses Sphinx for search)
• Translatable via the site itself.
• Could be configured so that users could see content that is customized for their version (i.e. 9.04/10.04, or Kubuntu / Xubuntu, etc.)
• Users can indicate whether or not an article solved their problem / was helpful, and they can give feedback regarding an article.
• The Mozilla team is able to get real-time stats on which articles are getting hits, and what questions are being asked.
• Mozilla licensing terms would allow the site code to be used by us as long as we customized the CSS, graphics, etc.

Plone

• Feature set is rather extensive ( http://plone.org/products/plone/features/3.0 ), and there a wide range of plugins available.

  • Note, those are the Plone 3.0 features, but Plone 4.0 is nearing completion
• Plone is written in Python, and could thus could likely be easily integrated into the Ubuntu / Canonical web environment.
• Plone is actively developed, widely deployed, and is has a reputation of being secure.

Rolling Our Own

• Use an existing web framework (Django or something more adventurous like Zotonic (written in Erlang), as examples) to roll our own CMS.

Drupal and DITA

Drupal has a broad range of features and has been used for wiki and documentation management alike in medium to large deployments. Recently efforts have been made to build single source publishing functionality into Drupal. These efforts are focussed around DITA as this is a versatile open standard that has gathered critical mass as a documentation platform in several industries.

No decision has been made, but there is interest in the documentation team for the adoption of single source mechanisms for the Drupal documentation, for example a conditional text project was accepted for GSoC.

Other Ideas

• Place your idea here.

Initial Mockups

The support home page:

An example of an article, with the Table of Contents hidden:

What happens when you click on "edit" in the feedback widget:

An article with the Table of Contents displayed when you click the "Table of Contents" up the top:

An explanation of the various features of the article page: