• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Product Registration Workflow

Note: this page is obsolete. The ideas here have been folded into GuidedProjectRegistration

• Launchpad entry: https://blueprints.launchpad.net/launchpad-registry/+spec/product-registration-workflow

• Created: 2007-07-20 by GuilhermeSalgado

• Contributors:

Split the product registration into multiple steps with only the very first ones being actually required to get the product registered.

Release Note

• TODO

Rationale

The current form to create a new product is huge and requires a lot of information the user may not know if he's registering a project not owned/maintained by himself. We need to allow users to create new products more easily.

Use cases

Assumptions

The bare minimum details required to register a new product are:

• Name
• Launchpad ID
• Summary

After the user entered these details, the other ones should be separated in different "themed" steps that can be easily skipped by the user in case he doesn't know (or doesn't want) to fill those details.

Design

This is just a copy-n-paste of the discussion we had in London about this. It still needs some cleanup work.

1. product-registration-workflow
   1. Required fields:
      • Name: GNU Haskell (current displayname)
      • Launchpad ID: gnu-haskell (nice to autofill)
      • Do you know the homepage for this project?
        • [ ] "(We'll use this to check for duplicates!)"
   2. Check if a matching project exists. Allow the user to go on if there isn't an existing one. Detect if he's asking for Ubuntu CDs!
   3. Fill out remaining information:
      • Name
      • Launchpad ID
      • URL
      • Images (branding)
      • Who should be responsible for this project?

        • < > Me
          < > [ ] (choose)
          < > I don't know (=> Registry Admins? Still need to let user change some things)
          

      • If Launchpad is the primary location for this project:
        • Description
        • License
        • Set up "uses Launchpad" stuff, on by default
        • Drivers
        Things you might want to do next:
        • Import code from an existing CVS or SVN repository
        • Create a hosted branch
        • Set up translations
        • Set up your bug tracker
        • Set up your answer tracker
        • Set up Blueprints (Bug #56614) (Reuse tour content to give background on LP applications)
   4. Set up your bug tracker
      • - Foreign:
        • Bug tracker
        • Context (for Bugzilla, Product/Component)
        - Hosted:
        • Import bugs from an existing tracker
        - Set up roles:
        • bug contact
        • security contact
   5. Set up translations
      • Choose translation policy
      • Set up a translation group (optionally)
      • Upload new templates and translations

Implementation

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.

Schema Changes

Migration

Include:

• data migration, if any
• redirects from old URLs to new ones, if any
• how users will be pointed to the new way of doing things, if necessary.

Unresolved issues

• MatthewPaulThomas: Excellent idea to use the project's home page URL to check for duplicates! However, I don't think that means we need to split up project registration into multiple pages. I think we should stop using the word "workflow" to mean "something we're not clever enough to fit into a single page".

  The project schema will become much simpler soon (specifically, merging Display Name and Title, shortening Summary, and dropping the Wiki, Screenshots, and Download URL fields). With less data to enter, there will be much less benefit in interrupting people with duplicate-checking; and that's exactly the sort of thing that should use XmlHttpRequest (when available) anyway, rather than a separate page.

  "Things you might want to do next" is a cool idea, but I think it should appear to maintainers on the project page whenever they visit it, not just during registration. That way they can come back to it whenever they like.

• ChristianReis: for now, we don't have a simplified schema, nor XmlHttpRequest, so we'll have to do with multiple page loads for now. And, at any rate, I don't want to make the direct registration of projects any easier than it already is, because we get so much spam right now it hurts. For more specific situations (such as create-a-project-while-creating-a-bugwatch) I agree it should be as simple as possible.