Can we use launchpad for non-project bugs?

Thanks for your thoughtful and generous answer.

We'll probably register another project with a name like one of csl-tech, mvhub-server, mvhub-support or the like to deal with issues related directly and indirectly to our hosting of mvhub on our servers.

This project will include tech bugs which somewhat directly effect mvhub support:

     "create SPF and domain key records so emails requesting people update records don't get spam filtered"

...and indirectly:

 "figure out new ldap replication mechanism in debian lenny so we can move ldap-01 and ldap-02 to lenny"

8.5 of the 9 of us are concerned with tech stuff, but August 01 a new VISTA (like the peace corps but US only) starts with us. Her focus is outreach. With her approval, we'll either create a project like csl-admin, csl-fund, or the like.

Alternatively we'll take a stab at managing outreach tasks in thunderbird / lighting w/ our or (sigh) google's CalDav server. The advantage of this approach is that it exposes people who will be alumni to a generic software libre solution that is desktop fast.

To answer your question, the only immediate help we could use is to add the ability to create dependencies among bugs the way you can with blueprints. (I don't now feel strongly enough about this to open a bug/blueprint on launchpad itself)

Generally we are liking Launchpad so far. We started with google code, but left/got booted after (Duh!) realizing they didn't permit the Affero GPL.

We're with you because we can use AGPL v3, because launchpad's code is open / becoming open. and you have the sexy rounded web 2.0 corners that Aloth / Savanah don't.

The other killer feature is Karma, We all joke about how we don't care, but I'm surprised at how often people check their score. --Elements of peer review like Aloth has (but which don't seem used) might be helpful.

The big nit (and it isn't that big) is that google code is easier to use. --Nothing I can put my finger on quickly, but I'd guess the google useability team is bigger than the Launchpad usibility team.

Maybe Launchpad was built to support the hugeness of Ubuntu and Google code was built to support 15 year old kids in their basement?

Thanks again for your help.

On Mon, Jul 13, 2009 at 11:44:32PM -0000, Dan MacNeil wrote:
> To answer your question, the only immediate help we could use is to add
> the ability to create dependencies among bugs the way you can with
> blueprints. (I don't now feel strongly enough about this to open a
> bug/blueprint on launchpad itself)

There's been many requests in this line and I think that it is indeed a
feature worth implementing, but the priority of it is unclear. It
remains on the radar for consideration in our release planning, and your
input into how important it would be would count.

> We're with you because we can use AGPL v3, because launchpad's code is
> open / becoming open. and you have the sexy rounded web 2.0 corners that
> Aloth / Savanah don't.

And more rounded corners are being added every day. The source code is
indeed about to be released; stay tuned for news on that.

> The other killer feature is Karma, We all joke about how we don't care,
> but I'm surprised at how often people check their score. --Elements of
> peer review like Aloth has (but which don't seem used) might be helpful.

Indeed, the social networking aspect of Launchpad hasn't yet been fully
explored, and we will invest more in that past July.

> The big nit (and it isn't that big) is that google code is easier to
> use. --Nothing I can put my finger on quickly, but I'd guess the google
> useability team is bigger than the Launchpad usibility team.
>
> Maybe Launchpad was built to support the hugeness of Ubuntu and Google
> code was built to support 15 year old kids in their basement?

There is definitely some of that. We have evolved from complex to
simple, and Google Code will end up evolving in the opposite direction
if they are to manage large complicated projects. The 3.0 redesign that
will show up in the following months will really focus on giving
projects a much more focused service than the existing layout -- right
now we overprivilege the fact that we host everything together, which
isn't the right message.
--
Christian Robottom Reis | [+55 16] 3376 0125 | http://launchpad.net/~kiko
                        | [+55 16] 9112 6430 | http://async.com.br/~kiko

Dan writes
> > we could use is to add
> > the ability to create dependencies among bugs the way you can with
> > blueprints.

> There's been many requests in this line
> and I think that it is indeed a
> feature worth implementing, but the
> priority of it is unclear. It
> remains on the radar for consideration
> in our release planning, and your
> input into how important it would be would count.

I did not see an existing bug or blueprint on this so I opened a blueprint.

Christian Robottom Reis writes
> Indeed, the social networking aspect of
> Launchpad hasn't yet been fully explored,
> and we will invest more in that past July.

I think "reputation systems" are different (and more important) than
"social networks".

The most used / useful reputation system I know of is on
http://perlmonks.org. You might read through some of the meta discussion
there.

On perlmonks, I have a childish but real incentive to "level up". Apart
from glory, after a certain level people get more privileges,
(moderation rights primarily) --Automatically vetting moderators is
another plus for the community.

More important, I get immediate and (usually) positive feedback to make
me "work" better by making better posts based on the feedback.

As happy side effects, "best post" lists are generated.

It is a bit like slashdot, but better.

It works where Aloth (last I checked) peer eval doesn't because the
reviewing is tiny, continuous and part of the nature flow of work.

Random idea:

 1) Assign existing karma per team
    or per project

 2) Have the team members allocate
    it to other team members or per
    project contributor.

You'd not be able to assign it to yourself. The effect would be that
people starting out would get a boost

Alternatively, allow people to share their Karma as individuals.

On the gripping hand, assign karma per team/project but let team/project
owner choose among several allocation schemes.

On Wed, Jul 15, 2009 at 05:48:08PM -0000, Dan MacNeil wrote:
> I did not see an existing bug or blueprint on this so I opened a
> blueprint.

Can I have the URL to it?

> Christian Robottom Reis writes
> > Indeed, the social networking aspect of
> > Launchpad hasn't yet been fully explored,
> > and we will invest more in that past July.
>
> I think "reputation systems" are different (and more important) than
> "social networks".

Well, I'm using the two terms as rough synonyms.

> 1) Assign existing karma per team
> or per project
>
> 2) Have the team members allocate
> it to other team members or per
> project contributor.
>
> You'd not be able to assign it to yourself. The effect would be that
> people starting out would get a boost
>
> Alternatively, allow people to share their Karma as individuals.

These two are actually pretty interesting ways to improve Karma; today
as it is only automatically managed, there is no human touch and we're
always a bit careful when deciding permissions or privileges based on
it. I'll put this up for consideration in the next planning meeting.
--
Christian Robottom Reis | [+55 16] 3376 0125 | http://launchpad.net/~kiko
                        | [+55 16] 9112 6430 | http://async.com.br/~kiko

>> On Wed, Jul 15, 2009 at 05:48:08PM -0000, Dan MacNeil wrote:
>> I did not see an existing bug or blueprint on this so I opened a
>> blueprint.

> Christian Reis
> Can I have the URL to it?

https://blueprints.launchpad.net/launchpad/+spec/add-dependencies-to-bugs