Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.


This sub-spec of ConnectingHelpSystems focuses on ways to make managed (and thus not directly editable by general users) wiki pages still receptive to comment and editing suggestions by the everyone. It tries to match the simple, community driven user interfaces described in ConnectingWikiToForums.

Release Note

Many of the critical support wiki pages are now managed by editing teams for higher reliability.

To keep managed pages accessible and current, there is a new "suggest an edit" feature which is nearly identical to the normal "edit" feature on unmanaged pages, which also supports community review and karma.

Every user's personal page is now managed by themselves, so you can get the experiment with the editor tools, should you wish to learn to manage pages.


Managed pages under the care of trusted editors are essential for maintaining high, known quality. Users prefer to have confidence in the quality of the pages they refer to, and the related spec LinkingDesktopToOnlineHelp also shows a need for managed wiki pages, if they are to be packed long term for release. However, cutting the population off from editing and updating the content of the pages would be a bad idea. The pages would rapidly become stale because the trusted editors (being a much smaller group) cannot have nearly the collective experience and activity the entire population does.

Thus, this spec attempts to marry high quality managed control, with user driven editing and review to capture the best of both worlds. There has been a ton of interest in contributing to documentation recently, and this pool of potential editors can be tapped to stay up with community feedback on all essential pages.

Use Cases




Notes migrated from the forum section when I realised it should not be a clone of this:


This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like:

UI Changes

Should cover changes required to the UI, or specific UI that is required to implement this

Code Changes

Code changes should include an overview of what needs to change, and in some cases even the specific details.



Test/Demo Plan

It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during CD testing, and to show off after release.

This need not be added or completed until the specification is nearing beta.

Outstanding Issues

This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.

BoF agenda and discussion

Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected.


ConnectingSuggestionsToManagedPages (last edited 2008-08-06 16:37:51 by localhost)