launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

Allowing contributors to set upstream information
=================================================

A common issue that blocks an Ubuntu contributor or knowledgeable user
from providing information that communities need to know about a project
is permissions. While we understand that a project is shared by many
communities, we have made a single person or team the project owner, and
this person often represents one community. Project owners are often
absent or do not provide the information needed by other communities to
contribute to the upstream project.

I want to change the permission rules for several project and series
attributes to enable contributors to provide the missing information. This
information pertains to Bugs, Branches, and Translations. I want to know
your opinions and concerns about these changes.

I'll be happy to drop aspects of this work if the respective team thinks
the idea is bad, or the solution requires a different approach.


Bugs: bug tracker
-----------------

Communities want to know the upstream bug tracker. The project owner can set
which bug tracker is used. If the information was never provided, I think
any contributor should be permitted to set it. If the project is owned
by Registry Admins, I think any contributor should be permitted to change it.

Such a rule change will exacerbate the bug tracker registration problem.
Creating a bug tracker requires arcane knowledge or luck. I know that most
launchpad users and engineers do not know how to register and set a bug
tracker. Expecting users to find a link at the bottom of a rarely visited
page that is only linked from another rarely visited root page does not
help us connection Ubuntu to upstreams. Discovering that the bug tracker
must be created *before* you try to set the project's bug tracker is cruel.
The Registry team will try to fix this problem in a related effort, but some
help may be needed from the Bug's team when the time comes.


Bugs: upstream contact
----------------------

Communities want to know the upstream contact person/team. The upstream bug
report says "contact", but it means Bug Supervisor. Do we really want to do
this? I think we should give serious consideration to changing the schema
to permit someone not associated with the Launchpad bug tracker. The upstream
contact falls back on the project group Bug supervisor. This is dubious in
many cases because the project group did not add the project, it was the
other way round; and the reasons for the relationship are not based on
bug tracking.

I registered the fail2ban project for the fail2ban source package last
week. While the project does not use Launchpad to track bugs, the project
maintainer does use Launchpad. To set him as the upstream contact, I must
enable Launchpad bug tracking, set him as the Bug Supervisor, then disable
bug tracking. This situation seems tortuous.

Regardless of the attribute that the upstream contact uses, I want to permit
contributors to set value when the attribute is empty. If the project is
owned by Registry Admins, I want give contributors permission to change the
attribute.


Branches: series branch
-----------------------

Contributors want to know the branch that a source package comes from. This
information is controlled by the series release manager or project owner.
Changes were made recently to allow some celebrity teams to make the change
when users asks a Question in the Launchpad project. I want to change the
rules to permit any user to set the branch for a series that has no branch. If
the project is owned by Registry Admins, I want to permit any user to update
the branch attribute.


Translations: enable imports
----------------------------

Only project owners can enable Launchpad Translations and setup automatic
imports/exports from a branch. This may be a contributing reason for the
many duplicate translation projects that are registered by users.

I want to permit any user to enable imports from the series branch that is
also linked to a source package. 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. This may require
users to enable Launchpad Translations, but I think the project's use of
Translations is separate from Ubuntu desire to get the latest Translations.


Implementation notes
....................

I think the proposed permission rules imply the return of the despicable
EditPersonLocation-style permission checker...

    class EditProductSomething(EditByOwnersOrAdmins):
        permission = 'launchpad.EditSomething'
        usedfor = IProduct

        def checkAuthenticated(self, user):
            """Anybody can edit something if it is not set."""
            something = self.obj.something
            if something is None:
                return True
            else:
                return super(EditProductSomething, self).checkAuthenticated(user)

...and the setup of some unique views to isolate this kind of change.

Since we are striving to remove the exceptional permission names, this whole
category of needs a name and story that is easy to test when we want to
reuse the permission name. We have a few cases of launchpad.append, but I
do not think that is this case. I also discount launchpad.moderate.
This looks like a launchpad.Propose, or launchpad.Suggest.

I have some reservation about this whole proposal--users cannot fix their
mistakes. This will lead to requests to other users to fix the data, and lead
to bug reports just like the reports to edit/delete comments.

-- 
__Curtis C. Hovey_________
http://launchpad.net/

Attachment: signature.asc
Description: This is a digitally signed message part