Project Bug Configuration
A single page (with an overlay) to configure a project's bug tracker and roles.
As a project owner
I want a single screen to configure bug tracking information
so that I can be certain that I provided all the information need by contributors
The first role we are considering is a project owner, but we may mean project registrant in the case where a user will gift the project to the Registry Admins. We will consider changing permissions on this information so that any community member may set this information if it is missing, or correct it in cases where the project is owned by the Registry Admins.
Rationale
Project owners and registrants do not know how to register a bug tracker; the feature is hidden. Users must visit multiple pages to provide this information and they often miss pages or fields. Potential contributors report bugs, and ask questions looking for this information, or ask someone with permission to find where the information can be set. The bug tracker and supervisor information is needed by Ubuntu to forward bugs upstream.
This feature provides a single page with all the information need to configure bug tracking, and allow contributors to forward bugs. This page can be accessed from the project index and the bug page. It may be possible to include this link from the source package page.
Stakeholders
Project owners who want to provide the information to potential contributors.
Ubuntu members who want to register the upstream project to report a bug.
MotUs who want to provide the information about the project that is the origin of a release.
Constraints
The new form UI must collect all the information needed to connect communities/contributors on a single page.
This new UI must not drive users to provide wrong information to satisfy the form. The current form requires that the user enable launchpad bug tracking to provide the bug supervisor (upstream contact). Users register duplicate bug trackers because the remote project field is not next to the bug tracker field Users list the upstream bug tracker in the project description because they cannot locate the form
Workflows
User will access the form from the Involvement portlet and from the project's bug page. Fields that are subordinate to the choice of bug tracker are enabled when the choice is made, and they are validated based on the choice.
NOTE: "Bug Supervisor" description text should explain that there is a very strong connection between this role and receiving email.
NOTE: The remote_product attribute needs a constraint to ensure it is sane and the UI should help the user find it.
- BUGZILLA, RT, and SAVANE use remote_product in filing and search urls.
- SOURCEFORGE uses remote_product to get group_id and atid; the remote_product field is set by the sfremoteproductfinder script that copies product.sourceforgeproject.
- updateremoteproduct script sets the remote_product from data learned from a bug watch.
Success
We know we are done when there is a link on the project index page and bug page to a page that allows the user to provide all the information needed to for other communities to contribute.
We will be successful if we see an uptrend in projects with bug tracker information. We expect fewer requests to register bug trackers.
Release Note
Launchpad replaces insane list of bug trackers with a chooser, and lets you register one without promising your first-born child to a troll.
Launchpad no longer requires black magic to configure bug tracking information. The bug tracker configuration page allow users to provide all the needed information in a single form. You can register a new bug tracker if too.
Thoughts?
I am hungry.