launchpad-dev team mailing list archive

[Edwin Grubbs <edwin.grubbs@xxxxxxxxxxxxx>]

On Wed, Mar 10, 2010 at 8:13 AM, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> On Thu, Mar 4, 2010 at 2:32 PM, Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx> wrote:
>> On Thu, 2010-03-04 at 07:52 -0600, Edwin Grubbs wrote:
>>> On Thu, Mar 4, 2010 at 1:20 AM, Martin Pool <mbp@xxxxxxxxxxxxx> wrote:
>>> > On 4 March 2010 16:32, Edwin Grubbs <edwin.grubbs@xxxxxxxxxxxxx> wrote:
>>> >> 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.
>>> >>
>
> Thanks for this Edwin. Sorry I've taken so long to get to replying.
>
> A couple of quick thoughts:
>  * we should just drop "Register a blueprint" from the "Get involved" box
>  * what would clicking on the "Bugs" tab show for a project that has
> "Report a bug" crossed out on the "Get involved" box? similarly for
> Translations etc.


Why would we remove the "Register a blueprint" link from the "Get
involved" portlet? Right now, the tabs show some info on activating
usage of the service, if the user has permission to do that. The one
exception is the Branch tab, on which you can register a branch
without any prior configuration to activate the service. Therefore,
graying out the "Submit a branch" link in the "Get involved" portlet
just serves the purpose of advising the user whether the upstream code
base is readily available.


>>> >> The wiki page with screenshots can be viewed at:
>>> >> https://dev.launchpad.net/Registry/InvolvementPortletRefactor
>>> >
>>> > Hi, this sounds like a point of dissatisfaction at the moment and
>>> > something worth improving.
>>> >
>>> > I don't really understand the "one community/two communities" thing.
>
> To be honest, neither do I.
>
>>
>> I think the message is lost in the spec. Contributors need to see and
>> set information that are need to contribute to a project. Ubuntu needs
>> to know the upstream contact, bug tracker, the development branch (in
>> launchpad), and automatic translation imports enabled for that branch.
>>
>
> I'm a bit confused. From the emails, it sounds like the spec is trying
> to solve the problem telling Launchpad more about exactly how a
> project is not using Launchpad. (e.g. where should bugs be filed?
> Launchpad? Some other tracker?), but I don't really see any of that in
> the specification.
>
>> These are application issues that overlap somewhat with the Involvement
>> portlet. Edwin proposes that we extend it to ask for the missing
>> information. What we have *not* solved is how to show that
>> information...this information is not always used to create an artefact
>> in an application.
>>
>
> "The value is in the output"! I guess this problem remains unsolved?
>
>> Let me provide to examples that illustrate my frustration when I try to
>> help link Ubuntu to upstreams I think the problem will be very obvious.
>>
>
> Thanks, these are good examples!
>
> Can I encourage you to turn this into a LEP and add it to
> https://dev.launchpad.net/LEP (I've recovered from my blueprints
> insanity)?


I have converted the page into a LEP. The scope has been narrowed and
new mockups have been added, so it is worth rereading.

https://dev.launchpad.net/Registry/InvolvementPortletRefactor

-Edwin

== Overview ==

'''Original requirements:'''
[[https://dev.launchpad.net/Registry/UpstreamLinkUbuntu#Project
community services (New)|UpstreamLinkUbuntuBlueprint]]

The goal of this proposal is to crowdsource the projects' upstream
links for bug reporting and source code.
Upstream bugtracker links help Ubuntu forward bugs and close bugs on
sourcepackages as soon as
they are fixed in the upstream. Upstream source code links help Ubuntu
build source packages
from branches with patches on top of the upstream source code.

We are no longer trying to apply this crowdsourcing to Blueprints and
Answers, since that is not
as valuable for improving Ubuntu. Translations is much more
complicated since the upstream
links are actually on the series, so we won't try to solve
crowdsourcing for it in this proposal.


'''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>>

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

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


== Workflows ==

[[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]])

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


||<tablestyle="background: #eef"> Date || # of projects with
bugtrackers || # of projects with dev focus branches ||
|| March 10, 2010 ||  950 || 7935 ||

{{{#!highlight python
/* 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).