launchpad-dev team mailing list archive

[Edwin Grubbs <edwin.grubbs@xxxxxxxxxxxxx>]

I would appreciate any feedback on this proposal for displaying users
which services are unconfigured. This is very closely related to the
proposal that Curtis emailed with the subject "RFC Changing
permissions to allow contributors to set upstream information", but
this document is only concerned with the project index page.

The wiki page with screenshots can be viewed at:
https://dev.launchpad.net/Registry/InvolvementPortletRefactor

Thanks,
Edwin

= 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.
 1. Allow the community to edit more of these links.
    * Accomplished by adding an edit link in the top right corner of
the involvement portlet.

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

'''Original requirements:'''
[[https://dev.launchpad.net/Registry/UpstreamLinkUbuntu#Project
community services (New)|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 =

[[attachment:old_project_page.png|Mockup of current project page layout]]

[[attachment:new_project_page.png|Mockup of proposed page]]
([[attachment:new_project_page.bmml|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.
     * Consequences, none.

== 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.
     * Consequences, none.

== One community, some services ==
The project owner is using Launchpad to track bugs.
Only bugs is official, no other tabs, involvement has one link.
     * Consequences, users do not no how to get support or code.

== 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
     * Consequences, no one can request a code import, or translations,
     which drives users to create duplicate projects; ubuntu lynches
     launchpad developers.

== 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
     * Consequences, owners may want to block the other community,
     or owners want to register an alternate service but cannot
     * Owners can block some some services like translations

== 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.
     * Consequences. links missing information, such as bug tracking
     prompt for someone to complete it. It seems like it is possible
     for communities to enabled multiple services, and it is not
     clear who uses them.

= Launchpad services =

I think there are several axes of the problem here that we are not observing
as we try to solve this:
     * Official vs. Community (cathedral vs bazaar)
     * Hosted vs. Remote
     * Synced vs. Isolated

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 =
     * Each service must make it clear if it is used, and possibly if
it is official or community.
     The state of the involvement portlet is never reflected in the
current use of the tabs.
     It is okay for me to visit code and see that the code is a mirror
of github. It is okay
     if answers says no one uses it.
     * Unused Launchpad services must state that they are not used to
users and search engines.
     * Communities have permission to enable a service
     * Communities have permission to set up upstream service information.
     * Owners can set instructions for blueprints and answers like
they can for bug tracking.
     * There must be a place where I can see and set information. I
     cannot see the upstream bug tracker in the UI. Registering a bug
     tracker happens in an arcane location, and I do not have
     permission to link the tracker with the project. This problem
     seems independent of my desire to report a bug (as directed by
     the involvement portlet).