launchpad-dev team mailing list archive

[Jonathan Lange <jml@xxxxxxxxxxxxx>]

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.

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

jml