Representing trusted project members who have access to private data, and can speak for the project
As the owner of a project
I want my company personnel to have access to private project data
so that the whole company can see the bugs and branches, without giving them responsibility to manage the project.
This document is about defining persons who are trusted project members. Two general problems are solvable when we can identify who is trusted in a project. Who can access private data like bugs and branches? Who represents the project in public messages.
Project may have private data that all it's members need to access. For example a company will want all it's employees to see private bugs and branches, without placing each person in the team that owns the project. These members are trusted to see all information, but are not taking on the responsibility to manage the project, triage bugs, and plan releases.
Projects need to identify their trusted members and their messages to users. Users of Launchpad need to determine the importance of a message and its author when making decisions. Within a project, Launchpad will display the project's icon with the official project member and his messages. The icon will act as a badge identifying the official aspect of the person or message to users.
This blueprint will probably be obsolete when Launchpad ACLs are revised
Blueprint information
- Status:
- Complete
- Approver:
- None
- Priority:
- Low
- Drafter:
- Curtis Hovey
- Direction:
- Needs approval
- Assignee:
- None
- Definition:
- Obsolete
- Series goal:
- None
- Implementation:
- Not started
- Milestone target:
- None
- Started by
- Completed by
- Curtis Hovey
Related branches
Related bugs
Sprints
Whiteboard
2007-09-11 Rinchen: setting initial priority to Medium. Distro team needs this. Priority may be adjusted as needed in the future.
2009-05-26 sinzui: Discovered a privacy story that better defines the need to know who trusted project members are