launchpad-dev team mailing list archive

[Curtis Hovey <curtis.hovey@xxxxxxxxxxxxx>]

On Wed, 2010-03-03 at 12:22 +0200, Bjorn Tillenius wrote:
> On Tue, Mar 02, 2010 at 01:33:21PM -0500, Curtis Hovey wrote:
> > 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.
> 
> I think the last sentence is key here, if Registry Admins owns the
> project, anyone should be able to change it. However, I would think a
> bit about the UI here. We might choose to have Registry Admins as the
> owner under the hood, but does it really make sense to expose this
> information to the users. Why can't we have an unowned project?
> Something that I have been missing for a long time, is to be able to
> say: I want to register this project, but I don't want to own it. We
> should make it clear that a project is unowned, so that it's obvious
> that people can change things there, and even take ownership themselves,
> if they care enough about the project.

This is a good point, and we have three related bugs that we want to
address in this series:

        * Bug 253341 [Active vs. placeholder projects are unhelpfully indistinct]
          https://bugs.edge.launchpad.net/launchpad-registry/+bug/253341
        * Bug 75604 [Marking projects 'abandoned']
          https://bugs.edge.launchpad.net/bugs/75604
        * Bug 162754 [Hard to disclaim maintainership of a project you're registering]
          https://bugs.edge.launchpad.net/bugs/162754

Solving the ownership presentation and claim/abandon action is something
I want to solve after we have changed permissions to allow users to fix
the data. We are working on a related problem. How to show that
information is needed on the project/series pages and how do we show the
information we have collected?


> 
> 
> > 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.
> 
> This is not my territory anymore, but since I've already started, I'll
> continue :) But again, thinking about the user story is important. What
> does making the bug supervisor field editable buy us? What does it mean
> that someone is a bug supervisor, when the project doesn't user
> Launchpad as the bug tracker? People can already subscribe to bugs in a
> project. Can't we use that information instead, to show who's interested
> in the project bugs? Do we need to control who can be considered the
> upstream contact?

Excellent question and I cannot answer it. The upstream bug report
claims to have an upstream contact, and I know it is really using the
bug supervisor. If the user of the upstream bug report do mind us
removing that field from the report, I think we can just state that
users are interested in the project...

But I think structural subscriptions are misleading here. I am
subscribed to many projects, but I can only affect the triage and fixing
of a bug in a few of them. I *think* Ubuntu, and any community really
want to know who can do triage and influence the fixing of this bug
upstream. The upstream contact could be either the upstream maintainer
or the leader of the bug team. (neither of these people may be launchpad
users)

> 
> BTW, I think this work is a great idea, I just think it needs mock-ups
> to show how people will actually use, and more importantly, understand
> this information.

We will when we get to that task. This is about fixing permissions.
Actions like setting the series branch does not require new ui. Setting
up a bug tracker and setting a project does need ui work, arguably ajax.
Each kind of information we need is a separate task. Having a lovely
overlay to set all this information is best for registering an upstream
project.


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

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