launchpad development|
Size: 5274
Comment:
|
Size: 5369
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 8: | Line 8: |
| 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. | '''Original requirements:''' [[https://dev.launchpad.net/Registry/UpstreamLinkUbuntu#Project community services (New)|UpstreamLinkUbuntuBlueprint]] |
| Line 11: | Line 11: |
| 1. 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. |
1. Indicate when the Launchpad project is not linked to the upstream's bugs or source code. * Accomplished by showing disabled (grayed) links in the involvement portlet. |
| Line 18: | Line 18: |
| '''Original requirements:''' [[https://dev.launchpad.net/Registry/UpstreamLinkUbuntu#Project community services (New)|UpstreamLinkUbuntuBlueprint]] | |
| Line 54: | Line 53: |
| missing or how to go about fixing it. | missing or how to go about fixing it. The Answers, Blueprints, and Translations links will remain invisible instead of graying them out, since it is not as important to Ubuntu to have the community link them to the upstream. Opening up the configure links to the community is pending on the implementation of user standing. |
|
Non-owners can only configure the two services whose upstream links are important for Ubuntu. (The balloon is actually a tooltip.) |
Project owners can configure the other services as well. Answers, Blueprints, and Translations are hidden when unconfigured as opposed to being grayed out with a warning icon. |
Overview
Original requirements: UpstreamLinkUbuntuBlueprint
This proposal tries to address these items:
- Indicate when the Launchpad project is not linked to the upstream's bugs or source code.
- Accomplished by showing disabled (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.
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. The Answers, Blueprints, and Translations links will remain invisible instead of graying them out, since it is not as important to Ubuntu to have the community link them to the upstream.
Opening up the configure links to the community is pending on the implementation of user standing.
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).
