launchpad development|
Size: 3296
Comment:
|
Size: 3808
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 13: | Line 13: |
| '''As a ''' $PERSON<<BR>> '''I want ''' $FEATURE<<BR>> '''so that ''' $BENEFIT<<BR>> |
'''As a ''' Ubuntu package maintainer/MOTU/helpful person<<BR>> '''I want ''' to create a project to link it to an Ubuntu package, and specify as much information as possible<<BR>> '''so that ''' Ubuntu can better interact with upstreams.<<BR>> |
| Line 17: | Line 17: |
| ''Consider clarifying the feature by describing what it is not?'' | This feature is not about the actual data gathering, the extant forms are sufficient. It is about providing guidance to users to know what is missing and to make links to the forms. |
| Line 27: | Line 29: |
| The users interested in a given project will benefit because they will be able to perform more tasks on a well-provisioned project. The project maintainers will benefit because it'll be obvious to them what remains to be done and how to go about performing those tasks. | The users interested in a given project will benefit because they will be able to perform more tasks on a well-provisioned project. The project maintainers will benefit because it'll be obvious to them what remains to be done and how to go about performing those tasks. Launchpad engineers less frequently suffer the stress of seeing "This project does not use Launchpad". |
| Line 33: | Line 35: |
| Ideas have been floated on the launchpad-dev mailing list. Actual stakeholders, project maintainers who are only casual uses of Launchpad, have not been contacted. | Ideas have been floated on the launchpad-dev mailing list. Stakeholders are Launchpad users who either register projects or seek to improve knowledge about projects in Launchpad. Individuals include: 1. Jelmer - frequently registers projects, has MOTU ties 1. Curtis 1. Jonathan |
Project Configuration Presentation
Registering a project in Launchpad should be as lightweight as possible, requiring the user to provide the minimal amount of information to get the project up and running enough to perform the initial task at hand. After that first effort there are many aspects of the project that still need to be specified for it to be a completely specified project. The maintainer of the project must be shown which parts are not yet specified and provide links to various configuration pages. The maintainer should be able to tell at a glance from the project index page how far along the project configuration is and the tasks remaining.
As a Launchpad user
I want create a project representing an upstream
so that I can link a bugtask to the project.
As a project maintainer
I want to see unconfigured aspects of my project
so that I can setup the project to use more Launchpad features.
As a Ubuntu package maintainer/MOTU/helpful person
I want to create a project to link it to an Ubuntu package, and specify as much information as possible
so that Ubuntu can better interact with upstreams.
This feature is not about the actual data gathering, the extant forms are sufficient. It is about providing guidance to users to know what is missing and to make links to the forms.
Rationale
Why are we doing this now?
We are undertaking the task now as part of the bridging-the-gap initiative. There are many projects in Launchpad that are insufficiently provisioned in that the upstream bug tracker has not been specified, the answer tracker hasn't been set-up, translations are unavailable, etc. The full potential of Launchpad is not being realized for these projects because the maintainers either don't know what they are missing or they don't know how to perform the configuration tasks.
What value does this give our users? Which users?
The users interested in a given project will benefit because they will be able to perform more tasks on a well-provisioned project. The project maintainers will benefit because it'll be obvious to them what remains to be done and how to go about performing those tasks. Launchpad engineers less frequently suffer the stress of seeing "This project does not use Launchpad".
Stakeholders
Who really cares about this feature? When did you last talk to them?
Ideas have been floated on the launchpad-dev mailing list. Stakeholders are Launchpad users who either register projects or seek to improve knowledge about projects in Launchpad. Individuals include:
- Jelmer - frequently registers projects, has MOTU ties
- Curtis
- Jonathan
Constraints
The new behavior must:
- Show maintainers the set of features that are configured and those that are not configured,
- Provide clear links to the setup pages of unprovisioned features,
- Show non-maintainers the set of active features (enabled) and inactive features (disabled).
It must not:
- Provide configuration links to users without the necessary permission.
- Kill bunnies.
Subfeatures
None
Workflows
Product index page with separate setup portlet
Product index page with one involvement portlet
Success
How will we know when we are done?
How will we measure how well we have done?
Thoughts?
Put everything else here. Better out than in.
