The Launchpad registry had a sprint in March 2010 to solve project registration issues. The topic was broadly set to be "drive through project creation", but the goal was to allow a community to provide project information at the time of need. For example, a user wants to report a bug about a package in Ubuntu. The bug must be forwarded to the upstream project to be fixed. The user may need to provide the upstream project's bug tracking information, and possible register the project in Launchpad first.

I talked about the madness of registering a bug tracker yesterday. Launchpad has many registered project without bug tracker information because there is no single simple page that allows a user to provide what is needed. I did a spike and could see that while we can collect the required information together in a single page, the information that the user must provide is not clear.

{width="600" height="492"} The disorganized information needed to configure a bug tracker.

Look at the picture. Can you tell that the "Remote project" field is subordinate to "In a registered bug tracker"? Bug expiration and reporting rules are subordinate to "In launchpad". I still cannot register a new bug tracker from this page, not can I set the bug supervisor (upstream bug contact), or security contact. The bug tracker widget needs a rethink, and I suspect a model change is needed, because the logic in the view is representing a boolean field and a bug tracker field as four radio buttons. These is some zany logic trying to reconcile the states.

I do not anticipate us starting on the new widget for a few weeks, but Edwin did take a partial step by extracting the bug tracker information from the project's +edit page. We will update the new page to be the single place that a user must visit to configure a project's bug tracker and contacts.