• 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

Project Configuration Presentation

Registering a project in Launchpad should be as lightweight as possible, requiring the user to provide the minimal amount of information to get the project up and running enough to perform the initial task at hand. After that first effort there are many aspects of the project that still need to be specified for it to be a completely specified project. The maintainer of the project must be shown which parts are not yet specified and provide links to various configuration pages. The maintainer should be able to tell at a glance from the project index page how far along the project configuration is and the tasks remaining.

As a Launchpad user
I want create a project representing an upstream
so that I can link a bugtask to the project.

As a project maintainer
I want to see unconfigured aspects of my project
so that I can setup the project to use more Launchpad features.

As a Ubuntu package maintainer/MOTU/helpful person
I want to create a project to link it to an Ubuntu package, and specify as much information as possible
so that Ubuntu can better interact with upstreams.

This feature is not about the actual data gathering, the extant forms are sufficient. It is about providing guidance to users to know what is missing and to make links to the forms.

Rationale

Why are we doing this now?

We are undertaking the task now as part of the bridging-the-gap initiative. There are many projects in Launchpad that are insufficiently provisioned in that the upstream bug tracker has not been specified, the answer tracker hasn't been set-up, translations are unavailable, etc. The full potential of Launchpad is not being realized for these projects because the maintainers either don't know what they are missing or they don't know how to perform the configuration tasks.

What value does this give our users? Which users?

The users interested in a given project will benefit because they will be able to perform more tasks on a well-provisioned project. The project maintainers will benefit because it'll be obvious to them what remains to be done and how to go about performing those tasks. Launchpad engineers less frequently suffer the stress of seeing "This project does not use Launchpad".

Stakeholders

Who really cares about this feature? When did you last talk to them?

Ideas have been floated on the launchpad-dev mailing list. Stakeholders are Launchpad users who either register projects or seek to improve knowledge about projects in Launchpad. Individuals include:

1. Jelmer - frequently registers projects, has MOTU ties
2. Curtis
3. Jonathan

Constraints

The new behavior must:

1. Show maintainers the set of features that are configured and those that are not configured,
2. Provide clear links to the setup pages of unprovisioned features,
3. Show non-maintainers the set of active features (enabled) and inactive features (disabled).

It must not:

1. Provide configuration links to users without the necessary permission.
2. Kill bunnies.

Subfeatures

None

Workflows

Product index page with one involvement portlet
This mock-up is the one I am proposing. It has a single involvement portlet with application actions followed by configuration status and links. The application actions are shown enabled for those that are provisioned and disabled for the ones that are not. The individual links are conditionally enabled based on the user's permissions.

Note the download portlet has been moved further down on the page to accommodate a higher visibility for the involvement portlet. A vigorous bike shedding argument could be made for relative placement for these two portlets. I feel presenting the involvement portlet first makes sense since its size is bounded whereas the download portlet can grow quite large. With this layout both portlets will be visible on the initial page load of a reasonably sized browser.

Product index page with separate setup portlet
This mock-up explored the idea of splitting out the configuration bits into a separate portlet that is only shown to users with edit permission. The ideas shown here have been rejected in favor of the previous mockup.

Success

How will we know when we are done?

We'll know we're done when maintainers can see how far along they are in fully provisioning their projects and they have a clear understanding of what needs to be done and how to do it.

How will we measure how well we have done?

Before implementation we can look at the status of all projects registered in the previous month paying attention to applications provisioned, number of contributors, and artifacts created. A month after rolling this change out to production (to ensure we aren't just testing our more skilled beta testers) we can gather the statistics again and compare to the previous control group.

Thoughts?

1. Blueprints are intentionally left out of the re-worked involvement portlet in order to discourage their use. The rules are:
   1. Do not show a disabled 'Register a blueprint'.
   2. Do not show the 'Configure blueprints' link to maintainers.
   3. If blueprints are enabled then show an active 'Register a blueprint' to all users.
2. The visual design of the progress bar has not been done. Do we have a suitable graphic to serve as its base?
3. In the Involvement portlet, the order of the action links and the configuration links should be the same.