launchpad-dev team mailing list archive

[Danilo Šegan <danilo@xxxxxxxxxxxxx>]

У чет, 04. 03 2010. у 14:27 -0500, Curtis Hovey пише:
> On Thu, 2010-03-04 at 18:20 +0100, Danilo Šegan wrote:
> > > Branches: series branch
> > > -----------------------
> ...
> > +1 Basically, we want to have a concept of "imported" project, and
> > perhaps having Registry Admins own it is a good indicator of such.
> > 
> > I think we are going to run into a lot of complications when we start
> > considering LP hosted projects where they are using only some bits of
> > LP, yet other users want to use others as well (eg. branches and/or
> > translations).
> 
> Indeed. This is the reason why Edwin's proposal to change the
> Involvement portlet is confusing. Most people think of Launchpad as a
> project hosting service. I think it is better to think of Launchpad are
> a community hosting service. Projects are where communities often
> intersect and they must share.

Agreed.  So, it'd be nice if we can formalize the concept of "hosted"
into something like IProject.is_hosted property.  And, come with with a
nice indication if one part of Launchpad is not officially used by a
project (for hosted projects, it would be only some bits of it; for
imported projects, it would appear on all sub-app pages for a project,
perhaps except on registry pages).

I.e. do something like the following

if (project.are_translations_configured and 
    not project.official_rosetta):
+-----------------------------------------------------------------+
| % Evolution is not using Launchpad for translations officially! |
| Please visit project homepage to learn how you can contribute.  |
+-----------------------------------------------------------------+

And for the time being, we'd make the 'translations' app for these
projects read-only (to be automatically used only in Ubuntu), and we'd
change the notice once we have support for sending contributions back
upstream for this project.

> I have considered the case where the project does use Launchpad for
> hosting. If conflicts over series cannot be reconciled, I would allow
> anyone to create a series instead of the projects drivers. This will
> allow communities to work in parallel. This also invited forking which
> may be a false understanding since branches are also forks.

Yeah, series are an interesting case.  However, I think we can safely
let many things be set up and created by the community if we have a tag
that indicates which items are official.  I.e. official series vs.
community series.  Because we have official_* flags per-app, we can make
use of that right away.

> > > Translations: enable imports
> > > ----------------------------
> ...
> > > I want to permit any user to enable imports from the series branch
> > that is
> > > also linked to a source package.
> > 
> > Is there a reason to limit it like this?  My take would be similar to
> > above: for any Registry-owned project, anyone can set it up.  For
> > projects with branches and unset translations, anyone can set it up.
> > Perhaps the second condition should also take the existence of a link
> > to a sourcepackage as well.
> 
> I was thinking the users would have link to a source package first, but
> I think your suggestion is best. I think this will also reduce the
> number of users who want to import a project instead of translating the
> project already in Launchpad.

I'd like to come back to translations imports crowd-sourcing later: we'd
probably want to have it as simple as one-click at one point that sets
up translation imports for all series branches and sets translation
focus to the development focus and sets appropriate translation policy
(i.e. 'Closed').

> > > I want this to be visible to the series
> > > release manager because I think he will be more willing to except
> > exports
> > > to he branch if he knew another community was helping him.
> > 
> > Considering how we don't want to allow anyone to translate in LP once
> > translations are imported, allowing export is not going to be of much
> > use: whatever is imported would be exported as well.
> 
> I do not understand this point.

Basically, before we have good implementation of the other direction
(from Launchpad to upstreams), we won't allow translations to happen in
projects not officially using LP for translations.  Thus, we won't allow
people to set up translations export for such projects (there won't be
any changes to export).

> > At the moment, it's perfectly possible to set up translations import
> > from a branch without "enabling" Launchpad Translations.  And for the
> > benefits we are expecting in Ubuntu, that's just about enough.
> 
> Ah! I was looking at the project, not the series. Okay, This is good. I
> can see I can do this for my projects, Registry Administrators, and
> projects owned by other users. This does not need a permission change,
> it just needs to made more prominent--this path requires knowledge.

Right, we need to make a simple 'set up translations' page which:

 1. recommends setting up a sourcepackage link (reusing what registry is
doing already) if it doesn't exist
 2. ensures branches are set up (Tim, does Code team have something
similar to what we have now for sourcepackage links?)
--
 3. sets translation_focus to development_focus series 
 4. sets the translation imports flag to 'import templates and
translations'
 5. sets project translation policy to 'closed' unless it's hosted and
officially uses LP for translations

This page should be project-based, and should basically be the
translations homepage if translations are not set up.

Second part of it all should be allowing everybody read-only access to
all the project translations sub-pages even if official_rosetta is
False.

I've filed relevant bits that I think need doing for translations as


https://blueprints.launchpad.net/rosetta/+spec/translations-import-crowdsourcing

(with two bugs linked to it).

> https://launchpad.net/ubuntu/lucid/+source/gedit > gedit HEAD series
> https://launchpad.net/gedit/head > Translations
> https://translations.launchpad.net/gedit/head > Set up branch synchronization

There is a good set of defaults that we should use for people wanting to
set it all up, and we should strive to make it as simple as possible.

> I would like to avoid this. We get feedback@ email and questions about
> bug trackers because Launchpad hides bug tracker registration and does
> not permit the user to set this information. This is also wrong because
> the email/question should go to the project maintainers, not us.

True: it would only be a band-aid, so let's avoid it.

> > Or alternatively, we can start decorating objects with
> > "just_an_import=True" and allowing changes by anyone with sufficient
> > karma/standing on such objects (branches, translation set-ups, project
> > properties, etc.). 
> 
> I think you are right. I think a good crowd sourcing implementation
> requires us to complete standing. I wonder if I would need to be
> scanning Launchpad for spam every day if we had complete standing two
> years ago.

Most likely not.  I believe 'standing' is necessary if we are to allow
changes to non-official pieces of a project.  And it'd be nice to
generalize the 'officialness' check somehow.

Cheers,
Danilo