⇤ ← Revision 1 as of 2008-12-01 13:44:09
3238
Comment:
|
3197
|
Deletions are marked like this. | Additions are marked like this. |
Line 9: | Line 9: |
* '''Launchpad entry:''' none yet * '''Created:''' (date) by (your name here) * '''Contributors:''' * '''Depends on:''' Is this spec dependent on the implementation of another spec? If n/a replace this text with "n/a" |
* '''Launchpad entry:''' https://blueprints.edge.launchpad.net/soyuz/+spec/sourcepackage-licenses * '''Created:''' 2008-12-01 by CelsoProvidelo * '''Contributors:''' JulianEdwards |
Contents |
SourcePackage licenses
Overview
Launchpad entry: https://blueprints.edge.launchpad.net/soyuz/+spec/sourcepackage-licenses
Created: 2008-12-01 by CelsoProvidelo
Contributors: JulianEdwards
Overall Summary
Summary: This should provide an overview of the issue/functionality/change proposed here. Focus here on what will actually be DONE, summarising that so that other people don't have to read the whole spec. Mention tables being created.
Goal/Deliverables: What do we plan to achieve and what actual things will be released/deployed?
We will know we have finished when ... - complete this sentence and leave in bold format.
e.g. We will know we have finished when we have basic pages in Launchpad on login.launchpad.net that allow someone to do the workflows outlined in the UI Mockups spec.
Release Note
This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the first part of our release change log.
It is mandatory.
Rationale
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified.
Use cases
This section should be a bulleted list of use cases which also include the user experience. Try to address who would use this, how they would use it, and what advantage it would be.
Assumptions
A list of assumptions should go here. This should include any assumptions about the users, the workflow, the implementation, the system this will reside on, the hardware requirements, access, etc.. Note that these are assumptions that everyone should believe are "business as usual". If you find yourself writing things which aren't, they are requirements and should be documented in the Implementation section below.
User Interface
This section should cover changes required to the UI, or specific UI features that are required to implement this.
Implementation
This section should describe a plan of action (the "how") to implement the changes discussed. This could include subsections in addition to what is provided in this spec template.
Code Changes
Code changes should include an overview of what needs to change, and in some cases even the specific details.
Schema Changes
What Database changes are you proposing? Do you need a new index created? Proposing a new table? If so, what does it look like?
Migration
Include:
- data migration, if any
- redirects from old URLs to new ones, if any
how users will be pointed to the new way of doing things, if necessary. (If your change is big enough, consider using the rollout template.)
Unresolved issues
In this section list out any issues which are unresolved and will impact or block the implementation of this spec.