Diff for "Registry/InvolvementPortletRefactor"

Not logged in - Log In / Register

Differences between revisions 1 and 2
Revision 1 as of 2010-02-22 22:54:06
Size: 6199
Editor: edwin-grubbs
Comment:
Revision 2 as of 2010-02-22 23:02:56
Size: 6085
Editor: edwin-grubbs
Comment:
Deletions are marked like this. Additions are marked like this.
Line 81: Line 81:
Asking users to report bugs outside of launchpad undermines Launchpad Asking users to report bugs outside of Launchpad undermines Launchpad
Line 83: Line 83:
users off site, we want the tracker to enable bug watches. The ideal is
that all bugs are synced, and when I report a bug in Launchpad and it is
automatically forwarded to the report bug tracker.
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.
Line 92: Line 92:
Launchpad, then can. The owner is never required to look a blueprints.
His concern is that a user may mistake the communities use of blueprints
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
Line 97: Line 97:
Answers does have some conflict between the owner and the community.
Owners may want a mailing list or forum, and do not like other
communities to adopt a
nswers. If the upstream mailing list were
represented as an answer contact (a team), it might be possible to let

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 A
nswers. If the upstream mailing list were
represented as an Answer Contact (a team), it might be possible to let
Line 102: Line 103:
hard. One request for owners is for Launchpad to make it clear where he
offers support.
hard.
Line 105: Line 105:
= Ideas to make launchpad usage clear =
     * Each service must make it clear if it 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 if
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.
= 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.
Line 114: Line 112:
     * Communities have permission to setup 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)
     * 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).


Service Tabs & Project Involvement Portlet

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.

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 community, 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 community, 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 community, 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 community, some services, soft enforcement

The project owner is using Launchpad to track bugs. Other communities can enable a Launchpad service without the owners 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 seams 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.

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).

Registry/InvolvementPortletRefactor (last edited 2010-03-11 16:47:53 by edwin-grubbs)