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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : [email protected] Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
