launchpad development|
Size: 7277
Comment:
|
Size: 4913
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 4: | Line 4: |
| = Overview = | == Overview == |
| Line 10: | Line 11: |
| * Accomplished by showing disabled links (grayed/strikethrough) links in the involvement portlet. | * Accomplished by showing disabled links (grayed) links in the involvement portlet. |
| Line 12: | Line 13: |
| * Accomplished by adding an edit link in the top right corner of the involvement portlet. | * Accomplished by adding an edit links at the bottom of the involvement portlet. |
| Line 18: | Line 19: |
| 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. |
'''As a ''' project owner or community member<<BR>> '''I want ''' to be alerted when Launchpad does not know where upstream bugs are tracked<<BR>> '''so that ''' I can configure a bugtracker or use Launchpad Bugs for upstream bug reports.<<BR>> |
| Line 28: | Line 23: |
| = Mockups = | '''As a ''' project owner or community member<<BR>> '''I want ''' to be alerted when the development focus series does not have a linked branch<<BR>> '''so that ''' I can link a branch that represents the upstream codebase.<<BR>> == Rationale == Even when Launchpad is not the official website for a project, Launchpad needs to show users how to forward bugs in Ubuntu to the upstream. Ubuntu developers may want to easily branch off the current codebase to create a new sourcepackage for Ubuntu. Community members may want to create a branch for a sourcepackage in their PPA. We do not want project owners to prevent community members from using Launchpad services that would be beneficial to Ubuntu users. == Stakeholders == * Jelmer * William Grant == Constraints == * The project index page must provide a visual cue when bugs cannot be submitted to the upstream and when branches off the current codebase cannot be created easily. * The project index page must provide an edit button positioned where it is obvious that it will fix the missing information. Currently, the links are just not visible, so it is not clear that something is missing or how to go about fixing it. == Workflows == |
| Line 34: | Line 61: |
| = Community Structuring = | == Success == |
| Line 36: | Line 63: |
| == One community, all services == The project owner is using Launchpad to host everything. All services are official, tabs enabled, involvement filled. * Consequences, none. |
''How will we know when we are done?'' |
| Line 41: | Line 65: |
| == 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. |
When it is clear that Bugs and Code need configuring, and it is easy to configure. |
| Line 47: | Line 68: |
| == 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. |
''How will we measure how well we have done?'' |
| Line 52: | Line 70: |
| == 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. |
By counting how many projects have bugtrackers set and how many projects have a branch linked to the development focus series. |
| Line 60: | Line 73: |
| == 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 |
Results on March 10, 2010: * # projects with bugtrackers: 950 * # projects with dev focus branches: 7935 |
| Line 68: | Line 77: |
| == 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. |
{{{ /* BugTracker count */ SELECT COUNT(*) AS bug_tracker_count FROM Product WHERE bugtracker IS NOT NULL; |
| Line 79: | Line 83: |
| = Launchpad services = | /* Branch count */ SELECT COUNT(*) AS dev_focus_branch_count FROM Product p JOIN ProductSeries ps ON ps.id = p.development_focus JOIN Branch b ON b.id = ps.branch; }}} |
| Line 81: | Line 90: |
| 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 |
== Thoughts? == |
| Line 87: | Line 92: |
| 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 == |
|
| Line 98: | Line 98: |
| == Bugs == | |
| Line 106: | Line 105: |
| == 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. |
=== Ideas to make Launchpad usage clear === |
| Line 115: | Line 107: |
| == 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). |
* 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. * 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). |
|
|
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:
- Indicate when the Launchpad project is not linked to the upstream's bugs, source code, forums, etc.
- Accomplished by showing disabled links (grayed) links in the involvement portlet.
- Allow the community to edit more of these links.
- Accomplished by adding an edit links at the bottom of the involvement portlet.
This will eliminate the need for the duplicate info provided by the Uses launchpad for section.
Original requirements: UpstreamLinkUbuntuBlueprint
As a project owner or community member
I want to be alerted when Launchpad does not know where upstream bugs are tracked
so that I can configure a bugtracker or use Launchpad Bugs for upstream bug reports.
As a project owner or community member
I want to be alerted when the development focus series does not have a linked branch
so that I can link a branch that represents the upstream codebase.
Rationale
Even when Launchpad is not the official website for a project, Launchpad needs to show users how to forward bugs in Ubuntu to the upstream.
Ubuntu developers may want to easily branch off the current codebase to create a new sourcepackage for Ubuntu. Community members may want to create a branch for a sourcepackage in their PPA.
We do not want project owners to prevent community members from using Launchpad services that would be beneficial to Ubuntu users.
Stakeholders
- Jelmer
- William Grant
Constraints
- The project index page must provide a visual cue when bugs
- cannot be submitted to the upstream and when branches off the current codebase cannot be created easily.
- The project index page must provide an edit button positioned
- where it is obvious that it will fix the missing information.
Currently, the links are just not visible, so it is not clear that something is missing or how to go about fixing it.
Workflows
Mockup of current project page layout
Mockup of proposed page (Balsamiq file)
Success
How will we know when we are done?
When it is clear that Bugs and Code need configuring, and it is easy to configure.
How will we measure how well we have done?
By counting how many projects have bugtrackers set and how many projects have a branch linked to the development focus series.
Results on March 10, 2010:
- # projects with bugtrackers: 950
- # projects with dev focus branches: 7935
/* BugTracker count */
SELECT COUNT(*) AS bug_tracker_count
FROM Product
WHERE bugtracker IS NOT NULL;
/* Branch count */
SELECT COUNT(*) AS dev_focus_branch_count
FROM Product p
JOIN ProductSeries ps ON ps.id = p.development_focus
JOIN Branch b ON b.id = ps.branch;
Thoughts?
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 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.
Ideas to make Launchpad usage clear
- 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.
- 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).
