launchpadblog

We want the project maintainer to be the default party that the project shares private information with. The problem at the moment is that Launchpad does not know how to set a team as the project maintainer during setup. Improper project setup is the root cause of most cases where information is disclosed to the wrong people. We need to improve project registration and setup to ensure users can ensure private information is managed properly. This issue is complicated by a very old issue, it is not possible to register a team at the moment you discover you need one. Launchpad must let me register a new team that will maintain my project when I first setup my project.

The Purple Squad discussed what we can do to simplify team registration and perform the registration in any page that allows you to set a team. We discovered several areas where we can make improvements.

• Do not ask for non-essential information like contact address.
• We can simplify the team membership policy language.
• We can fix the confusion about membership renewal.
• Launchpad can pre-fill the form with sensible defaults when the team will be used in a role.

Ian put together a demonstration to prove we could extend the person picker to also permit you to register a team.

When you want to set the project maintainer to a new team, Launchpad will ask you to confirm its suggestions for the Launchpad Id, display name, and membership policy. You can change the values, but most of the time you will choose to continue, and Launchpad will register the team and place it in the role.

All users can now see the information type section that replaces the privacy and security section shown on bug and branch pages. This change allows users to clearly state the kind of information a bug or branch contains. Launchpad will soon permit project maintainers to share information types instead of managing individual bug and branch subscriptions. Project maintainers can see a link on their project’s front page to the  “Sharing” page. Sharing lists all the users and teams their project shares some private bugs and branches with. This list might be surprising. Launchpad Beta testers will soon be able share and unshare kinds of information to simplify management of whom the project discloses private information to.

See Reimaging the nature of privacy in Launchpad for more details.

The Purple Squad recently discussed how the forthcoming sharing feature changes project setup. Sharing will allow project maintainers to share kinds of information with users and team. This feature separates access to private information from bug and branch subscriptions. Maintainers do not need to manage hundreds of subscriptions, users do not needs to block unwanted email.

Before sharing, direct subscriptions were the only way Launchpad knew which users the bug or branch was disclosed to. Launchpad would subscribe the maintainer, or the team in a designated role to ensure someone could work with the information in the bug or branch.  The subscribed users would then be responsible for subscribing other users and team so that everyone who needs to know about the information could work with it. Most users subscribed to private bugs and branches get unsolicited email. Each user’s project, series, and milestone subscriptions are ignored.

After sharing, subscriptions to projects, series, and milestones will just work. If a private bug matches your project subscriptions, and that kind of information is shared with you, you will get the email. You will be able to subscribe to kinds of information, such as embargoed security.

The security contact role

The security contact role is obsoleted by sharing. It can be removed.

The security contact exists to tell Launchpad which team to subscribe to embargoed security bugs to ensure the information is disclosed to someone. The role does not convey any other privileges. Only one team could be in the role; it was not possible to tell Launchpad that embargoed security bugs should be disclosed to several teams. Sharing allows the maintainer to specify which teams embargoed security information is disclosed to.

The bug listing page implies that no one has access to security information when the role is not set. This was never the case. Launchpad subscribed the maintainer to the bug if no one was in the security contact role. Maybe Launchpad should show a notice to maintainers when it detects that no one is subscribed to get security mail? This presumes email is how users want to be notified. It think this is nice to have, but not a requirement. I would prefer Launchpad to present a log of recent activity on its pages and send me emails that summarise important activity when I have not visited the pages recently.

The bug supervisor role

The bug supervisor  looses its private bug responsibilities after sharing. It is still useful to delegated additional bug editing privileges to a team who does not drive development decisions.

The bug supervisor role will be used less often. Most teams currently in the bug supervisor role are also in the driver or maintainer role. Launchpad required maintainers to set the bug supervisor role to ensure that those that plan released can also see the private bugs. Small projects will not need the role. It will only be needed by projects that want to expand the number of contributor who can triage bugs without expanding the number of people who do release management.

The maintainer role

The maintainer role is unchanged by sharing. Well, it responsibilities are unchanged, so we must ensure that the project shares private information with the maintainer by default.

When a project is registered, Launchpad must share each kind of private information with the maintainer. This is rule is not as simple as you might think. Many projects are registered by a user, who sets a team as the maintainer during setup. From Launchpad’s perspective,  the project has transferred the role. Launchpad does not know what to do [1]. Some maintainers do not want to work with private information, they delegate to other teams. Launchpad cannot presume that changing the maintainer means changing who private information is disclosed to. Maintainers can always choose to share the information with themselves.

Launchpad’s project setup workflow is incomplete. There are two screens that gather the basic information, but you can set additional information on the project front page. There are five pages to configure how the project uses Launchpad that maintainers should review during setup, but we did not have the time integrate them. We do not want users to do more work. Instead we want Launchpad to present just the essential information and have sensible defaults.

Reimaging/completing project setup is out of scope for the sharing feature, but it might be in scope for the Purple Squads next feature, private projects. During setup, Launchpad needs to know who the maintainer will be and share private information with them. We can consider this work as an enhancement to maintain expected behaviour. We will do this work as a part of the sharing feature. When we work on private projects, we can explore what else project setup and reconfigure needs to do to ensure that information is disclosed to the proper teams. Private projects will also entail making projects public, which means reconfiguring the kinds of information a project has.

[1]  If you have ever changed the bug supervisor or security contact, you might know of the pain I am alluding to. Bang head against desk, scream at computer, weep, set aside a few weeks of your valuable time to update all bug subscriptions yourself so that the new team can do it’s job. This whole scenario is implicitly fixed by sharing since subscriptions are not used to manage access.

The Launchpad team is planning a new feature that will allow you to link bugs to each other and describe their relationship. The general idea is that you can say one bug depends of the fix of another. The goal is to make it clear where conversations to fix issues take place, who will do the work, and when the work can start.

I summarised the existing bug linking features and hacks previously. Now I want to explain the workflows and UI that Launchpad could support to create and explain relationships between bugs.

Managing bug relationships

Organisations and communities split issues into separate bugs when different people work at different times with different priorities to solve the bigger issue. Organisations and communities merge bugs when they want a single conversation to fix an issue that affects several projects at a single time. Explicit relationship between bugs (or the many projects listed on a single bug) would help projects organise work.

There are four general relationships that people try to describe when working to fix an issue. These relationship are either explicit, or implied when a bug affects multiple projects, or many bugs affect a single project. The relationship informs everyone about where the conversation to fix an issue happens, and the order of work to fix a group of issues.

• Duplicate: Bug X is the same as bug Y. The primary conversation about fixing the bug happens on bug Y. A secondary conversation happen on bug X. The affected projects, their status and importance, of bug X are identical to Bug Y.
• Dependency: Bug X depends on bug Y. Bug Y must be fixed before bug X can be fixed. The bugs have separate conversations, but each is informed of the other. Though the bugs have separate status and importance, there is some expectation that work proceeds from one bug to the next. As the bugs might affect different projects, the work to fix a bug may be done by different people. A project bug might depend on the fix in a library that is provided by another project. A bug in a distro series package might depend on the fix in an upstream project release. Dependency is implied when we see a bug that affects a distro package also affects the package’s upstream project.
• Similarity: Bug X and bug Y are caused by similar implementations. Bug X and Y require separate fixes that can happen concurrently. The bugs might share a conversation to find a fix, but the work and conversation is more often independent. In some cases, the proper fix is to create one implementation that the similar bugs depend on to fix the issue. A project might have two bugs caused by a bad pattern repeated in the code, or a pattern in one project is also used by another project. Each location of the pattern needs fixing. Maybe the right fix is to have a single implementation instead of multiple implementations.
• overlap: Fixing bug X  changes the scope of work to fix bug Y. These bugs have separate conversations, but the work to fix each issue needs coordination. Fixing one bug may make the other invalid, or make it more difficult to fix the other. Maybe these bugs need to be redefined so that they do not overlap? Maybe bug X can be fixed at the same time as bug Y? Maybe both bugs really depend on an unknown root cause…bug Z?

We might imagine the relationships like sets. The duplicate bug is a subset of the master bug. Two bugs intersect in the overlap relationship. Similarity is a superset of several bugs. The dependency relationship has a direction pointing from one bug to the next.

Managing separate conversations

People working with proprietary information create duplicate and or dependent bugs to manage separate conversations. The “Affect project”, “Affects distro”, and “Duplicate” action do not work because they either mix conversations, or loose status and importance. Users benefit when private conversations are split from public ones, but Launchpad does not help the user do this.

Launchpad will not permit projects to share the forthcoming “proprietary” bug information type. Proprietary information is given to one project in confidence; The project cannot share that information with another project. The “Affects project”, “Affects distro” cannot add projects to the bug, so Launchpad must help users report a separate bugs.

When someone realises a private bug affects more than one project, Launchpad could help the user split the bug into separate bug reports to manage conversations and the order of work to fix the greater  issue. Instead of adding a project or distro to the bug, the user might want to choose the project to report the bug in, and be prompted to revise the bug summary and description so that private information is not disclosed. The new bug is commonly public. It is the master bug, this is where the public conversation happens. This practice benefits more than the user who reported the bug…there is a public place for all users to discuss the issue.

Users are less likely to report a duplicate bug when Launchpad can show the public bug in the list of similar bugs. The principal cause of bug 434733 is not commercial projects, bug non-commercial projects like Ubuntu that mark bugs as duplicates of private bugs without consideration that users want to be informed and participate in the conversation.

Duplicate bugs continue to have separate side conversations that often focus on release issues. The discussion of how to fix the issue happens on the master bug. Duplicate bugs also have wasteful conversations that can be answered by the master bug. There is always a risk of disclosure when the reporter of a private bug has to visit the public bug to learn information that is pertinent to the private bug.  The risk and inconvenience could be avoided by showing the important information on the duplicate bug — do not force users to change the context when working with private data.

We can substitute another relationship for “duplicate” in my case for separating discussions. When a fix for a bug is dependent on a one or more other bug fixes, there are several conversations with different people with different concerns. The same is true for bugs with similar or overlapping concerns. The only time conversations really need to be shared is to coordinate the timing or scope of the fixes.

While privacy is a primary reason to split conversations, splitting public conversations can benefit as well. The current UI that encourages a single conversation of ambiguously related downstream and upstream projects is a source of unwanted email. If I am only interested in the issues that affect my projects, do not make be get email for all the other projects.  Splitting conversations into several bugs within a project is also a legitimate means to solve large problems that require different developers to fix code at different times. Minimising the notifications to just the relevant information keeps users focused on the issues.

Linking existing bugs

The workflow to select and link bugs is untrusted. When marking a bug as a duplicate, or linking a bug to a branch, Launchpad asks me to provide the bug number (Launchpad Id), then the page updates and I learn the consequences. Did I type the right number? Did people get emails about irrelevant or confidential information?

I expect Launchpad to ask me to review the bug I am linking and ask me to continue or cancel. Launchpad has to show enough information to answer my question’s and gain my trust:

• What is the bug’s summary?
• What is bug’s information type — is it private?
• Which projects does the bug affect?
• What are the bug’s tags?
• What is the bug’s description?

The presentation for bug listings provides most of this information. Launchpad could reuse the presentation (that I am already familiar with) when asking me to review the bug that matched the number I entered.

I imagine that if the action I am taking is specific, like marking a bug as a duplicate of another, Launchpad does not need to ask me about the relationship. In cases where the relationship is not implicit in the action, Launchpad must let me select the relationship between the bugs.

I know many users expect bug linking to work like selecting a user. They want to enter search criteria to see a listing of matches. The user might expand a match to see additional information. The user can select the bug, and maybe select the relationship to create the link. I am sceptical that this workflow would meet my needs. I often use advanced bug search to locate a bug; I cannot imagine offering advanced bug search in the small space to select a bug to link. The picker infrastructure that provides the workflows to select users and projects supports filters, which could be adapted to work with bug tags. I  doubt this will be very useful. Advanced bug search does not work well across multiple projects, and bug linking does and must work across projects. I think people will still needs to use advanced search to locate the bug that they want to link.

Presenting a summary of the bug relationships

When an issue is represented by several bugs, or a bug affects several projects, users need known how they relate to understand where and when someone needs to take action. Users often open many pages because Launchpad cannot summarise the relationships between several bugs. Users will also read through long comments to learn why a bug affects many projects.

When viewing a bug, the user needs to see a listing of related bugs (dependency, similarity, and overlap). The listing summarises the affected project, status, importance, assignee, and milestone.  Users might need to see bug tags, and badges for branches and patches. Maybe this is like the listing of bugs shown in bug search.

The affects table is a special bug listing. Does it need to be special? Users want to see the relationship between the items in the affects table. I want to know if the fix in a package depends on the fix in an upstream project. I am unsure how this could be done since there might be many relationships in the table. Maybe the many relationships, 3 or more affected project, packages, and series, will diminish when bug linking is available. We know that users unsubscribe when a bug affects many things because the conversation looses focus. When users can link bugs, there will be less needs to say a bug affects many things.

Privacy is a special case. A user can only see the relationship between two bugs if the user can see both bugs. When the listing contains private bugs, the presentation must call-out that they are seeing privileged information. Launchpad does not have a consistent way to show that part of a page contains private information.

• The user profile page will show locks before email addresses.
• Bug listings show a lock icon among other icons after the bug.
• Branch listings and linked branches show the lock icon after the branch.

Launchpad must make it clear to the user to not discuss the private relationships in the bug’s conversation.

Duplicates are presented differently from other bugs because they are subordinate to the master bug. There are several problems with the current presentation of duplicate bugs.

• Duplicate bugs show contradictory information in the affects table
• Duplicate bugs may not show the master bug if it is private
• Master bugs may show hundreds of duplicate bug numbers without summary or privacy information
• Why do I need to see all the duplicate bug numbers on a master bug?

Users do not need to see a list of all the duplicate bugs on the master bug. The number of duplicates is more interesting that a listing of numbers. User care about the duplicates they reported because they might want a side conversation, maybe Launchpad should show the user a link to the bug he or she reported? A contributor might want to read the the conversations in the duplicates for new information, so Launchpad does need to show a list of duplicates when the user asks for it. The listing of duplicates must indicate which are private. Other data like status and importance are irrelevant because the master bug provides the this information.

When I view a duplicate bug page, Launchpad must make it clear that this bug is a duplicate. I need to see the master bug’s information: affected project, importance, status, milestone, and assignee. I am not sure if the user should see its own affects table; that information would only be important if the bug was unduplicated.

There is a problem if the master bug is private and the user does not have permission to see the master bug. The user cannot see the master bug exists. Launchpad could prevent duplicate master bugs from being private if the project can have public bugs. In the case of projects with default proprietary bugs, the master bug will always be private. When the reporter of the duplicate bug cannot get information, he, and the project contributors are forced to start side conversations. Is it possible to show some of the affects table from the master bug to answer some of the user’s questions? May I know the status and importance of the master bug? May I know the affected project if both bugs have the same affected project?

Conclusion

The Launchpad team will spend about 12 weeks creating the bug linking feature. The feature will emphasise the use cases needed to support two other features in development now, sharing and private projects. Proprietary data has less need for revising the bug affects table, though a unified presentation of linked bug and affects projects might need less effort to create.

The essential points about bug linking is that project needs to manage bug conversations to mange the disclosure of private information. Organisations split work into multiple bugs to mange conversations and organise work between different people. Launchpad could show and summarise the linked bugs so that contributors do not need to switch context to plan work.

Launchpad beta testers are seeing information types on bug reports. Launchpad replaced the private and security checkboxes with an information type chooser. The information types determine who may know about the bug.

When you report a bug, you can choose the information type that describes the bug’s content. The person who triages the bug may change the information type. Information types may also change as a part of a workflow, for example, a bug may start as Embargoed Security while the bug is being fixed, then the release manager can change the information type to Unembargoed Security after the release.

Testing in phases

In the first phase of this beta, Launchpad continues to share private information with bug supervisors and security contacts using bug subscriptions. The project maintainer may be managing hundreds of bug subscriptions to private bugs, and people are getting unwanted bug mail.

In the second phase of the beta, the project maintainer can share information types with people…the maintainer is only managing shares with a few teams and users and people are not getting unwanted bug mail.

Watch the video of information types and sharing to see the feature in use and hints of the future.

Launchpad can now show you all the people that your project is sharing private bugs and branches with. This new sharing feature is a few weeks away from being in beta, but the UI is informative, so we’re enabling this feature for members of the Launchpad Beta Testers team now. If you’d like to join, click on the ‘join’ link on the team page.

What you’ll see

Project maintainers and drivers can see all the users that are subscribed to private bugs and branches. The listing might be surprising, maybe even daunting. You may see people who no longer contribute to the project, or people you do not know at all. The listing of users and teams illustrates why we are creating a new way of sharing project information without managing bug and branch subscriptions.

If you’re a member of (or once you’re a member of, if we want people to join) the Launchpad Beta Testers team, you can find the Sharing link on the front page of your project. I cannot see who your project is sharing with, nor can you see who my projects are sharing with, but I will use the Launchpad project as an example to explain what the Launchpad team is seeing.

The Launchpad project

The Launchpad project is sharing private bugs and branches with 250 users and teams. This is the first time Launchpad has ever provided this information. It was impossible to audit a project to ensure confidential information is not disclosed to untrusted parties. I still do not know how many private bugs and branches the Launchpad project has, nor do I even know how many of these are shared with me. Maybe Launchpad will provide this information in the future.

Former developers still have access

I see about 30 former Launchpad and Canonical developers still have access to private bugs and branches. I do not think we should be sharing this information with them. I’m pretty sure they do not want to notified about these bugs and branches either. I suspect Launchpad is wasting bandwidth by sending emails to dead addresses.

Unknown users

I see about 100 users that I do not know. I believe they reported bugs that were marked private. Some may have been subscribed by users who were already subscribed to the bug. I can investigate the users and see the specific bug and branches that are shared with them.

The majority

The majority of users and teams that the Launchpad project is sharing with are members of either the Launchpad team or the Canonical team. I am not interested in investigating these people. I do not want to be managing their individual bug and branch subscriptions to ensure they have access to the information that they need to do their jobs. Soon I won’t have to think about this issue, nor will I see them listed on this page.

Next steps — sharing ‘All information’

In a few weeks I will share the Launchpad project’s private information with both the Launchpad team and the Canonical team. It takes seconds to do, and about 130 rows of listed users will be replaced with just two rows stating that ‘All information’ is shared with the Launchpad and Canonical teams. I will then stop sharing private information with all the former Launchpad and Canonical employees.

Looking into access via bug and branch subscriptions

Then I will investigate the users who have exceptional access via bug and branch subscriptions. I may stop sharing information with half of them because either they do not need to know about it, or the information should be public.

Bugs and private bugs

I could start investigating which bugs are shared with users now, but I happen to know that there are 29 bugs that the Launchpad team cannot see because they are not subscribed to the private bug. There are hundreds of private bugs in Launchpad that cannot be fixed because the people who can fix them were never subscribed. This will be moot once all private information in the Launchpad project is shared with the Launchpad team.

Unsubscribing users from bugs

Launchpad does not currently let me unsubscribe users from bugs. When project maintainers discover confidential information is disclosed to untrusted users, they ask the Launchpad Admins to unsubscribe the user. There are not enough hours in the day to for the Admins to do this. Just as Launchpad will let me share all information with a team or user, I will also be able to stop sharing.

(Image by loop_oh on flickr, creative commons license)

We’re making changes to the way that bug heat is calculated and displayed in Launchpad.  From 6^th February, bug heat will no longer age/degrade, and the active flame counter symbol will be replaced by a number, next to a static flame.  Here’s why.

Bug heat ageing is the cause of a wide range of timeouts in Launchpad. Every bug’s heat has to be recalculated and updated every day using a series of complex calculations, and when there are around 1 million bugs reports to track, that’s a lot of pressure on the system, consuming a significant chunk of resources.  Turning off bug aging is the simplest way to solve this issue.

 Display

The flame counter symbol, although adding some visual flair (and flare), also needs to update every time the bug age recalculations are made.  The continual stream of updates to the bug rows also results in poor search index performance.

We’ll still have a flame symbol, however it’ll be static, with the bug heat number next to it. Although not as visually dynamic, it’ll be easier to work out bug heat scores more exactly, at a glance.

Although I’m sure some of us will miss this little Launchpad feature, less timeouts is good news for everyone.

The title may sound like a contradiction, but I assure you that it is not. You can now use private teams in social contexts in Launchpad. Private teams can collaborate with public projects and other teams if they choose to reveal the existence of the private team.

1. Private teams can me members of other teams.
2. Other teams can be members of private teams.
3. Private teams can subscribe to bugs, blueprints, branches, and merge proposals
4. Private teams  can be in public project roles,  such as maintainers, drivers, and bug supervisors.
5. You can change the branch owner to be a private team.
6. Private team personal branches (+junk) are always private.

When a member places the private team in a social situation, a the member is asked to confirm that it is okay to reveal the team’s identifying information. This information is the team’s Launchpad Id used in URLs, the displayname, icon, and logo. A user can visit the private team’s Launchpad page and will only see that information. The rest of the page is not shared. Anonymous users cannot see a private team’s page because that user is not being social; logged in users can see the private team’s page

Private team page seen by a non-member

Launchpad did not permit these interactions previously because it was not clear who should know about the team. Someone has to know. If Launchpad permitted private teams to subscribe to bugs or be members of teams without anyone knowing of them, they would be unaccountable. Private teams could spy on organisation, or learn about security vulnerabilities to exploit. Launchpad will not ever permit such asocial behaviour. The resolution for social interactions was to permit other parties to know enough of the private team to make an informed decision. For example, when I choose to make a bug private, I want to know who was already seen the bug through a subscription. I may choose to unsubscribe the private team if I do not trust them.

Private teams may invite exclusive teams to be members. Exclusive teams (moderated or restricted teams) review all members so they are accountable. If a team admin trusts the admins of another team, and that team is accountable, Launchpad permits the other team to be a member. This is actually a rule that applied to all exclusive teams. private teams are always exclusive (restricted membership policy). The only nuance with private teams is when it is a member of another team; the super team may know the members of the private sub team because the super team has the right to audit all its members so that it too can be accountable.

We’ve recently deployed two features that make it easier to find bugs that you’re previously said affect you:

1: On your personal bugs page, there’s now an Affecting bugs that shows all these bugs.

2: On a project, distribution or source package bug listing page, there’s now a “Bugs affecting me” filter on the right (for example, bugs affecting you in the Launchpad product).

Counts of the number of affected users already help developers know which bugs are most urgent to fix, both directly and by feeding into Launchpad’s bug heat heuristic. With these changes, the “affects me” feature will also make it easier for you to keep an eye on these bugs, without having to subscribe to all mail from them.