launchpad-dev team mailing list archive

[Bjorn Tillenius <bjorn@xxxxxxxxxxxxx>]

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.



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


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.


-- 
Björn Tillenius | https://launchpad.net/~bjornt