Registry/InvolvementPortletRefactor

Not logged in - Log In / Register

Revision 15 as of 2010-03-04 04:13:50

Clear message


Contents

  1. Overview
  2. Mockups
  3. Community Structuring
    1. One community, all services
    2. Two communities, all services
    3. One community, some services
    4. Two communities, some services, hard enforcement
    5. Two communities, some services, firm enforcement (now)
    6. Two communities, some services, soft enforcement
  4. Launchpad services
    1. Branches and Translations
    2. Bugs
    3. Blueprints
    4. Answers
  5. Ideas to make Launchpad usage clear

involvement_soft_enforcement.png

Overview

The Uses launchpad for information is too simple. It acts as a flag, ignoring the fact that communities need to know who, what, and where to contact essential services.

This proposal tries to address these items:

  1. Indicate when the Launchpad project is not linked to the upstream's bugs, source code, forums, etc.
    • Accomplished by showing disabled links (grayed/strikethrough) links in the involvement portlet.
  2. Allow the community to edit more of these links.
    • Accomplished by adding an edit link in the top right corner of the involvement portlet.
  3. Make it clear when two communities are using both Launchpad services and external websites for the same task.
    • Accomplished by intermixing external links in the involvement portlet. (This is the most difficult item, since it is not clear whether to make

      the links blend in as shown with the External Mailing List link for Ask a question. There are also subtle differences in how each service should be handled.

This will eliminate the need for the duplicate info provided by the Uses launchpad for section.

Original requirements: UpstreamLinkUbuntuBlueprint

The intent of the Involvement portlet is to let the project owner specify the Launchpad services he uses. While other communities may use code hosting, he does not. The branches tab works, but it is not shown in the involvement portlet. Note that the links in the tabs are different from the portlet...the portlet drives the user to create an artefact, where as the tabs are access to the whole service. Tabs are for communities, the portlet links are for a user. The purpose of the portlet is to drive an action, where as the goal of complete upstream information is to communicate off-site information to users and systems.

Mockups

Mockup of current project page layout

Mockup of proposed page (Balsamiq file)

Community Structuring

One community, all services

The project owner is using Launchpad to host everything. All services are official, tabs enabled, involvement filled.

Two communities, all services

The project owner is using Launchpad to host everything. The other community can access all the same services. All services are official, tabs enabled, involvement filled.

One community, some services

The project owner is using Launchpad to track bugs. Only bugs is official, no other tabs, involvement has one link.

Two communities, some services, hard enforcement

The project owner is using Launchpad to track bugs. The other community can only use bugs. Only bugs is official, no other tabs, involvement has one link

Two communities, some services, firm enforcement (now)

The project owner is using Launchpad to track bugs. Only bugs is official, all tabs are enabled, involvement has one link The other communities can use unofficial services

Two communities, some services, soft enforcement

The project owner is using Launchpad to track bugs. Other communities can enable a Launchpad service without the owner's permission AND either community can register an alternate service. Regardless of official/unofficial, all tabs are enabled and all links are enabled.

Launchpad services

I think there are several axes of the problem here that we are not observing as we try to solve this:

Users who think Launchpad is hosting service for their project want official control over tabs and services, that undermines other communities; we will not honour the owners demand to become an island.

Branches and Translations

Branches and Translations offer imports, syncing, and hosting. They seem to avoid most issues with owner egos. There is no issue with registering github as the upstream repo, we can import it, offer merge reviews, and bzr can send the code to github. Some project do ask us to remove branches and we say no. The story for Translations is about the same.

Bugs

Bugs is different, syncing is not automated, each bug requires setup. Asking users to report bugs outside of Launchpad undermines Launchpad communities. We do not want to register a remote bug tracker to send users off site, we want the tracker to enable bug watches. The ideal solution is that all bugs are synced, and when I report a bug in Launchpad it is automatically forwarded to the right bug tracker.

Blueprints

Blueprints does not store the core data, and Launchpad already collects the off-site wiki. I think many of the owner vs community conflicts can be resolved by ensuring that blueprints knows about the upstream wiki. If the community wants to do extra work tracking blueprint statuses in Launchpad, then can. The owner is never required to look at blueprints. His concern is that a user may mistake the community's use of blueprints as his endorsement.

Answers

Answers does have some conflicts between the owner and the community. Owners may want a mailing list or forum, and do not want other communities to adopt Answers. If the upstream mailing list were represented as an Answer Contact (a team), it might be possible to let both systems share messages. In the case of a forum, integration is hard. The community might also want to use a Launchpad mailing list for handling questions instead of Launchpad Answers.

Ideas to make Launchpad usage clear