Introduction

• This page contains a summary of my thoughts towards ["MOTU/WikiCleanUp"], driven in part by a review of the Wiki.

General Notes

Audience

• Documententation should be written so as to provide clear information to four distinct groups:
• The interested public
• Those who will need a sponsor to accomplish the goal
• Those who will perform the action directly
• Those sponsoring/reviewing the actions of others

Integration with Launchpad

• Where practicable, any guide towards doing things to support development should include documentation of the workflow using launchpad to complete the action.

Processes

• Each process page should contain the following sections:
• Description of the purpose of the process
• The relevant policy governing the process
• Procedural documentation for each distinct audience Process pages should be based on a Task focus, rather than being workflow outlines for specific teams: it's much easier to rationalise a process when all the steps are in one place.

Organisisation

• All Development-related pages should be in a clear Development namespace
• There should be no pages that are only links to other pages - use a TOC instead
• There should be clear separation between information about Ubuntu-specific activities and general information. Where appropriate, process pages should link to general guides, and general guides should link to relevant Ubuntu processes.
• There should be overview pages for each development role (Contributor, Developer, Core Developer) pointing to relevant process pages, and other links of interest.

• This section needs more thought

Page Size

• Small pages should be avoided, and the content rather included in a larger page, to provide the appropriate context for the reader.

Teams

• Team pages should include, at a minimum:
• The name of the team
• Activities overview for the team
• Formal charter for the team
• Pointer to LP team to see membership, etc.
• Indication of criteria for team membership
• Pointers to other pages of interest to the team Pages previously used by no-longer active teams should be archived, or merged elsewhere Separately from the above, how is a MOTU team different than other development teams?

Specs

• New specifications should really go into a /Spec/ namespace, and the documentation and guidelines for creating these should indicate as much. This makes it much easier to separate documents of historical or future planning interest from documentation of current practice.

Review of pages in the Wiki

• The sections below are loosely organised as I thought of categories: they don't really mean anything other than being a way for me to organise my thoughts. This is also currently a work in progress. While I've read all the pages, I've not yet compiled all the comments.

Contributing

• ["ContributeToUbuntu"] is a good page, but the section on contributing to Universe needs an update.

• ["HelpingUbuntu"] is nice, and has lots of content that probably belongs in ["ContributeToUbuntu"]

• ["EasyWaysToHelpUbuntu"] Needs cleanup, and might be better as a section in ["ContributeToUbuntu"]

• ["MOTU/Contributing"] is over-detailed, and doesn't match the other contributing documents well. Also, there are instructions here that are useful beyond contributing (How to prepare a patch, how to prepare a new revision, how to prepare a new package).

• ["ContributingToDebian"] could use a refresh, and update, and pointers to DCT

• ["NewDevelopersAndMaintainers"] is confusingly named. If this must be kept for historical reasons, it should be put in /Historical/ or /Archive/. External links that break reaching this page are probably preferable to actually presenting this content as official.

• ["MOTU/Hopeful/Tips"] has a name that implies something other than "THIS PAGE IS MOSTLY REDUNDANT WITH OTHER PAGES ON THE WIKI.".

• ["DocumentationTeam/GettingStarted"] is a nice example of an introduction. Let's shoot for something with this feel.

• ["MOTU/Hopeful/Recruitment"] covers some of the process, but fails utterly to describe the criteria for evaluation, or represent actual recruitment of "Hopefuls" (a term I do not prefer). This (and a related guide to moving from Developer to Core Developer should be documented as part of some page describing each of the teams.

Packaging

• ["HowToBuildDebianPackagesFromScratch"] needs some work (and should offer alternatives to dh_make)

• ["MOTU/School/PackagingBasics"] needs an update, and the extraction of documentation, rather than a School session
• ["MOTU/School/2005-12-10"] could use a better title, and some cleanup
• ["MOTU/Packages/Reviewing"] looks good, but could use a cleanup / refresh
• ["MOTU/Packages/Reviewing/Tips"] would be better to merge up. More generally, those reviewed should be exposed to the reviewers guide so that they may pre-review, if so desired.
• ["MOTU/Packages/Packaging/Kubuntu"] seems to be a parallel document. There is useful information here, but overall management would be easier with everything in one place

• ["UbuntuPackagingChanges"] needs to be up-to-date, and be easier to find. I never encountered this previously.

• ["MOTU/Packages/Packaging/Tips"] has some useful content, but it's uneven, and not very friendly to read

• ["MOTU/Packages/CommonPackagingMistakes/DebianCopyright"] is nice, but would benefit from review & a TOC

• ["MOTU/Packages/CommonPackagingMistakes/ChangingTheOrigTarball"] is nice, but would benefit from a review & a TOC

• ["MOTU/Packages/CommonPackagingMistakes"] is painfully sparse. Either guidance should be added, or the namespace collapsed, and documents should link to the specific mistakes directly.
• ["MOTU/School/PackagingMistakes"] should mined for more like the above, and all should be named something less negative in the final version.

Patching

• ["MeetingLogs/openweekfeisty/patching"] could use review, and extraction of good bits not covered elsewhere.
• ["MOTU/School/PatchingSources"] needs a TOC, and likely a bit more dicussion
• ["Bugs/HowToFix"] would benefit from review and better process integration (what is sought from those who can edit code, but are unfamilar with packaging?)

• ["CreatePackageFromSourcePackage"] has some handy commands, and is a clear indication that someone could not find this documentation.

General

• ["UbuntuDevelopment"] should be overhauled as part of the cleanup.

• ["PackageManagement"] is very outdated, but has some useful bits. It probably needs pointers to a real spec

• Pages like ["MozillaTeam/Bugs/Triage/Responses"] should be encouraged for all teams.
• ["MOTU/Documentation/Todo"] appears to be the last attempt - why branch?
• ["MOTU/Documentation"] Contains lots of links, but no guidance

• ["DebuggingProcedures"] Contains lots of links, but no guidance

• ["DevelopersDocumentation"] is hopelessly sparse

• ["Acronyms"] should either be expanded (and agressively linked) or dropped
• ["DocumentationTeam/Ideas"] makes some good points, worth reviewing
• ["MOTU"] is a nice page, but probably needs a refresh as part of the rewrite

• ["LinuxTips"] is the least useful collection of Linux tips it has been my profound misfortune not to be able to avoid viewing.

• ["MOTU/FAQ"] has good information, but this isn't the best place for it. Also, these don't appear t tbe the most frequently asked of questions (although maybe that's because people read the FAQ).
• ["MOTU/ReferencePackages"] looks like a good start, but needs work. Also, care should be given to using the same example packages in several references, so those from the patching and merging guides might do well here (of those should be updated to use packages shown here).

• ["KubuntuDocs"] is nice, but seems lonely.

• ["MOTUMenuHeader"] has a color scheme that doesn't match the default.
• ["MOTU/Recipes"] contains links to useful documentation (although it needs launchpad integration), but is very sparse. Such documentation should rather be linked from a more verbose guide to developer activities.

Processes

• ["SeedManagement"] is nice, but it needs a cleanup for 1) TOC, and 2) reorg so that the information at the top of the page is more accessible to those unfamiliar with seeds.

• ["MOTU/Packages/Merging"] covers the topic well (could use a TOC), but would benefit from launchpad notes, and encouragement to include outstanding Ubuntu bugfixes at the same time as the merge (several Contributors have expressed that they would patch bug X as soon as package Y was merged, whereas I think both should be the same upload to reduce archive churn and the load on the buildds).
• ["MOTU/Merging"] contains lots of useful links. More generally, there should be one page for all merging, to all repositories, with variance specified where appropriate (it's not that different).
• ["MOTU/Merging/Policy"] should be updated, and merged with other sources of the same information

• ["StableReleaseUpdates"] would benefit from a rewrite and rationalisation to cover the procedures for both main/restricted and universe/multiverse.

• ["MOTU/SRU"] should be fed into StableReleaseUpdates

• ["SecurityUpdateProcedures"] needs a cleanup to make it easier to understand

• ["MOTU/Launchpad/Guide"] is outdated, and in some cases wrong, but may contain useful guidelines on launchpad interaction which are not documented elsewhere
• ["MOTU/Packages/REVU"] should probably be split, such that much of the content becomes a manual that is specific to the REVU tool, and the remainder feeds back into more general processes for 1) getting new software into Ubutu, and 2) releasing new upstream versions into Ubuntu prior to inclusion in Debian.
• ["MOTU/Processes/REVU"] Documents a process for an unimplemented spec, and should be dropped.
• ["MOTU/Packages/New/Policy"] Content from this page is of historical interest, but should rather be merged into the relevant new software packages procedure, just to remind uploaders that they are responsible for ensuring that an RFP has been filed for the package. Linking to/from DCT pages would be good as well.

• ["DebianMaintainerField"] is a spec, but there should be a maintainermangling process as a result.

• ["MOTU/Sponsorship/SponsorsQueue"] is useful, but I wonder if Sponsorship is actually a separate process...

• ["SponsorshipProcess"] would benefit from cleanup, audience expansion, generalisation, and a TOC

• ["UbuntuMainInclusionRequirements"] is nice, but could use a TOC and audience expansion

• ["MainInclusionProcess"] is the other half of ["UbuntuMainInclusionRequiremens"] and also not very nice to view.

• ["MOTU/Packages/New"] is out of date. The content should be merged with "Preparing new packages" section of ["MOTU/Contributing"] and put somewhere else, which place should meet general guidelines.
• ["MOTU/Packages/Candidates"] has the some of right content, but it's tiny, and doesn't really help the person wanting to add the package.

• ["NewDeveloperProcess"] is a vast improvement over ["MOTU/Hopeful/Recruitment"], but starts in a confusing manner, and the content would be better in membership processes for the team pages for Ubuntu Developer and Ubuntu Core Developer

• ["MOTU/Mentoring/Contributor"] would be better as part of an expanded ["MOTU/Mentoring"]
• ["MOTU/Mentoring/Mentor"] would be better as part of an expanded ["MOTU/Mentoring"]
• ["MOTU/Mentoring"] Needs expansion, a TOC, some prettification, and the inclusion of the split-out content

• ["MOTU/UpstreamVersionFreeze"] should be generalised or merged with ["UpstreamVersionFreeze"] and ["FreezeExceptionProcess"]

• ["NewReleaseChecklist"] could be a lot more informative for those seeking to understand or help the RMs and REs.

Bugs

• ["Bugs/UsefulSearches"] seems like the best place to keep lots of searches. Those MOTU pages with bug searches might do better to be added as part of a rewrite of this page.

• ["DrinkingFromTheFirehose"] is nice, but I haven't seen much documentation as to the resulting new processes. Is this bughelper? Does it just need more work?

• ["MOTU/Bugs"] - a lot of this seems like it might be better to feed into Bugs/, and point there, rather than keeping it separate. The remainder seems process-based, and would be better there.
• ["Bugs/ReportingToDebian"] should be emphasized: it's especially important to encourage those making new revisions, or processing merges to check to make sure the bugs are filed in Debian, and if so, are linked appropriately to the (now closed) LP bugs. Some cleanup would be nice as well, and perhaps less emphasis on reportbug, for those with broken local mail configurations.

• ["Bugs/Importance"] Should be more visisble to Developers. As it is, those who didn't come through BugSquad (and those that have forgotten) often set Importance differently than specified here.

• ["Bugs/Responses"] is hard to use, and now growing very large.

Other

• ["MOTU/Packages/DesktopFiles"] could use a TOC, and perhaps a rewrite

• ["DCT/DesktopFiles"] should be reconciled with ["MOTU/Packages/DesktopFiles"], so there is a consistent policy. See also [https://blueprints.launchpad.net/rosetta/+spec/rosetta-desktopfile-ui]

• ["IconComposition"] should have more informtion about preferred formats, filesystem locations, themes which are being actively developed locally, etc. Also, the .desktop file pages should link here. The link to the ArtTeam should also be updated.

• ["LaunchpadHowTo"] Could use signifcant expansion, including notes on things for which one must belong to specific teams, etc.

• ["MOTU/School"] should be more about school (and planning sessions, archives, etc.) and less about MOTU and contributing
• ["MOTU/School/Requests"] needs a kick to be useful again - I don't hear enough about it
• ["MOTUNotes"] probably belongs in another place, but this requires coordination with upstream. Also, it's hopelessly out of date.
• ["MOTU/TODO"] is a great list of resources, and a handy way to track things, and should have a place somewhere. It could also be prettified. Some of the philosophy expressed in ["MOTU/Contributing"] might be useful here. Use of real URLs is also preferred, as it makes it easier to tweak.
• ["MOTU/Tasks"] Seems to be old, and less useful. The content should be deleted or merged into ["MOTU/TODO"]
• ["MOTU/Packages"] is a handy namespace placeholder, but the majority of the content is useless, or duplicated (with better copy) elsewhere.
• ["MOTU/wx2.4Migration"] - transitions and other package-related coordination activities are better managed as LP bugs with many tasks. A bug should but opened in LP for the issue, and affected packages added as tasks. Developers should manage the bug as they normally would.

• ["DesktopTeam/GksudoChanges"] is another example of something possibly better a bug (it's also very out of date).

• ["Fridge/Motu-school-packaging"] doesn't seem useful, and may distract from the valuable content in ["MOTU/School"]. I don't see a lot of other Fridge pages like this (<10)

• ["KernelTeam/KnowledgeBase"] should be highlighted more

• ["CreatingBzrMaintainedPackage"] is useful, if sparse. Encouraging new packages with no upstream targeted for Ubuntu to use this will create non-native packages, which will later be easier for Debian to adopt, if appropriate at that time. It also clearly separates packaging from development, which allows different specialisations if it becomes popular and attracts a community.

• ["ApplicationIdeas"] needs a home, and probably a pointer to some process by which useful things could be accomplished, rather than the preparation of a list.

Tools

• ["PbuilderHowto"] could use a refresh (or rewrite to use terms like "current development release", "current stable release", "current LTS release", etc.). Also, aren't there some scripts that do most of this now?

• ["MultiDistroTools"] could use a refresh, an upstream, and maybe even a distributed package

• ["MOTU/Packages/REVU/REVU-Tools"] should be stuck in the archives and referenced in the Reviewing guide
• ["Strace"] is much harder to find than it should be

Specs

• ["CodeReviewSLA"] should probably be reconcilied with REVU2 towards developing a workflow that is easy for everyone - we should base tools on workflow, not workflow on tools (especially when the tools don't yet exist)

• ["DeveloperDocumentation"] should make the status as a Spec clearer.

• ["ExistingDocumentation"] is unfinished, out of date, and the scope is undefined

• ["AutomakeTransition"] should be more clearly highlighted. There's no reason this couldn't be advanced as part of merging (especially if patches flow back to the Debian BTS).

• ["MotuProcessesSpec"] is a good spec, but these processes should be more clearly documented outside the spec to allow for changes over time.

• ["EfficientCodingStrategySpec"] doesn7t seem very lively, but information produced as a result would do well to be documented in the Development tree, so that people look for that when making adjustments.

• ["MOTU/MorgueForMOTU"] should be formalised, and applied to all of Ubuntu - it's certainly not MOTU specific. Additionally, changes should be made to [http://merges.ubuntu.com] and [http://patches.ubuntu.com] to use this resource. Until a spec is implemented, MOTUs should be informed that the base version is always available by reverting the Ubuntu diff (from patches.ubuntu.com).

• ["ClosingBugsFromChangelog"] is done, and the results should be integrated everywhere else

• ["APTPackageDeltas"] seems a useless discussion page, but is confusingly named given the terminology of Ubuntu package deltas for that distributed from [http://patches.ubuntu.com/]

• ["Xdelta"] is confusingly named (it matches a universe package) If this isn't going anywhere, it should move into something else.
• ["APTIndexDeltas"] seems to be another random branch in this forest

• ["PackageNamingStandards"] doesn't seem to have gotten anywhere, and certainly doesn't provide any useful guidance

• ["EasierMotuing"] still isn't. Ongoing work is great, but the recruiting, "career path", and guidelines for progression aren't clear yet.

• ["PackageVersionConflicts"] is unfinsihed, hopeless out of date, and covers a namespace that would be better for helping with library transitions, or Debian/Ubuntu changes (especially build-dep, etc.).

• ["SharingInformations"] is unfinished, out of date, and annoyingly named.

• ["UseTheSpoon"] is unfinished and out of date

• ["E17PackaagingPolicy"] is poorly named and unstarted. This should be generated or removed.

• ["DCT/SpecDatabase"] seems extra somehow - shouldn't most DCT activities be integrated in Ubuntu development practices?

• ["UbuntuPackagingGuide"] was a great spec, and did great things, but it should be moved into a clear Spec/ namespace, as the name can lead to confusion. There is a /Comments page that should stay with it.

• ["TrackingUpstreamAndDebianVersions"] is nearly empty and frustratingly named for those searching for merge stuff.

Teams

• ["MOTU/Teams/Audio"] seems to have moved into Ubuntu Studio. or more generally into the Audio team (depending on which portion is considered)
• ["MOTU"] needs signfiicant overhaul as part of the cleanup

• ["UbuntuDevelopers"] is a good structure, but doesn't appear in line with current MOTU thinking. Also, as a team page, it should be more ... something.

• ["UbuntuDevelopmentTeam"] seems a lost orphan - the content belongs somewhere else, or significantly more content belongs here.

• ["MOTU/Teams/Howto"] Doesn't seem meaningfully specialised for MOTU - content should be fed to ["BuildingCommunity/CreatingTeamGuide"]

• ["MOTU/Teams/Ideas"] UDU was a long time ago, and not much here either 1) makes sense now, or 2) is of historical interest.
• ["MOTU/Council/Charter"] seems a little out of date, and not really a Charter, or at least not formalised in such a way as to provide a good guide as to what properly belongs to MOTU Council, and what properly doesn't (I realise that this is yet to be strongly defined).
• ["MOTU/Council"] Seems a much better treatment, and would do well to have a TOC and include the charter.
• ["MOTU/Meetings/TeamReorg"] was a temporary page, and doesn't mean anything anymore
• ["MOTU/Teams/IM"] is a nice page, but needs contact info, a link to an LP team, etc.
• ["MOTU/Teams/Java"] is very out of date - this should be updated
• ["MOTU/Teams/Games"] is not active, but has massive historical content. This should be cleaned up, relevant data moved to the Debian games team, etc.
• ["MOTU/Teams/Python"] is a nice page, but needs contact info, a link to an LP team, etc.

Redirects

• ["MOTUTodo"] -> ["MOTU"]

• ["MastersoftheUniverse"] -> ["MOTU"]

• ["Motu"] -> ["MOTU"]

• ["MOTU/Processes/Processes/StableReleaseUpdates"] -> ["MOTU/SRU"]

• ["MOTU/Processes/SRU"] -> ["MOTU/SRU"]

• ["UniverseBugs"] -> ["MOTU/Bugs"]

• ["MOTU/BugFixing"] -> ["MOTU/Bugs"]

• ["UniversePackages"] -> ["MOTU/Packages"]

• ["MOTUIM"] -> ["MOTU/Teams/IM"]

• ["BugResponses"] -> ["Bugs/Responses"]

• ["MOTUJava"] -> ["MOTU/Teams/Java"]

• ["TriagingProcedures"] -> ["HelpingWithBugs"]

Odd External Result Pages

• These pages are a result of redirects in the wiki, for which I can no longer determine the source page. I suspect most of the redirecting pages are probably significantly aged, and any internal links should rather point to the external source directly. Someone should search for these redirects, and update pages that call them. At some later point, it may be worth removing the page entirely (or if there are no links, this may be that later point).. Note that the existence of a page in this section in no way reflects any opinion of that page. Most of them seem fairly nice, but all are outside the scope of the current cleanup.

• [https://help.ubuntu.com/community/ReportingBugs]

• [https://help.ubuntu.com/community/CommonQuestions]

Miscellaneous Pages that are confusedly named

• ["MorBuntu"] - also not very informative and out of date

• ["UbuntuOnTheClamshell"] probably belongs as part of HW support (if something more detailed is not already there)