JabberIntegration
Differences between revisions 10 and 13 (spanning 3 versions)
|
Size: 2217
Comment:
|
Size: 1901
Comment: New Spec for XMPP messiging
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| ## page was copied from SpecTemplate | |
| Line 3: | Line 4: |
| * '''Launchpad Entry''': UbuntuSpec:foo | * '''Launchpad entry''': UbuntuSpec:foo |
| Line 8: | Line 9: |
| == Summary == | Summarize the change here. |
| Line 10: | Line 11: |
| == Release Note == | If the specification is a long one, add a `<<TableOfContents()>>` here too. |
| Line 12: | Line 13: |
| This section should include a paragraph describing the end-user impact of this change. It is meant to be included in the release notes of the first release in which it is implemented. (Not all of these will actually be included in the release notes, at the release manager's discretion; but writing them is a useful exercise.) | == Release note == |
| Line 14: | Line 15: |
| It is mandatory. | If the specification describes a major change between Ubuntu releases, summarize the change here in a way that would be useful for the sort of people who read release notes. Be as brief as possible, but include anything users might want to do before or after upgrading. |
| Line 20: | Line 21: |
| == Assumptions == | == The rest of the specification == |
| Line 22: | Line 23: |
| == Design == | Replace that heading with headings for each thing you’re changing or specifying. |
| Line 24: | Line 25: |
| You can have subsections that better describe specific parts of the issue. | Checklist: |
| Line 26: | Line 27: |
| == Implementation == | 1. Have you reviewed the bug reports for the relevant package? (Yes, this may take an hour or two. But you might be able to fix multiple bugs with a well-designed change.) |
| Line 28: | Line 29: |
| This section should describe a plan of action (the "how") to implement the changes discussed. Could include subsections like: | 1. If any user interface is involved, is it fully described? Include any wireframes or mockups. |
| Line 30: | Line 31: |
| === UI Changes === | 1. Have you had any new user interface, or new visible text, reviewed by a designer? (Or if you are a designer, have you had it peer-reviewed?) |
| Line 32: | Line 33: |
| Should cover changes required to the UI, or specific UI that is required to implement this | 1. Is the change accessible? (For example, have you specified accessible labels for any graphic-only elements?) |
| Line 34: | Line 35: |
| === Code Changes === | 1. How will users learn the new way of doing things? Describe any help pages required, and any changes to the Ubuntu Web site or installer slideshow. |
| Line 36: | Line 37: |
| Code changes should include an overview of what needs to change, and in some cases even the specific details. | 1. Is any migration of data or settings required? |
| Line 38: | Line 39: |
| === 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. == Test/Demo Plan == It's important that we are able to test new features, and demonstrate them to users. Use this section to describe a short plan that anybody can follow that demonstrates the feature is working. This can then be used during testing, and to show off after release. Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. This need not be added or completed until the specification is nearing beta. |
1. How will the feature be tested? Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage. |
| Line 53: | Line 43: |
| This should highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. == BoF agenda and discussion == Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. |
Highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved. |
Launchpad entry: foo
Created:
Contributors:
Packages affected:
Summarize the change here.
If the specification is a long one, add a <<TableOfContents()>> here too.
Release note
If the specification describes a major change between Ubuntu releases, summarize the change here in a way that would be useful for the sort of people who read release notes. Be as brief as possible, but include anything users might want to do before or after upgrading.
Rationale
User stories
The rest of the specification
Replace that heading with headings for each thing you’re changing or specifying.
Checklist:
- Have you reviewed the bug reports for the relevant package? (Yes, this may take an hour or two. But you might be able to fix multiple bugs with a well-designed change.)
- If any user interface is involved, is it fully described? Include any wireframes or mockups.
- Have you had any new user interface, or new visible text, reviewed by a designer? (Or if you are a designer, have you had it peer-reviewed?)
- Is the change accessible? (For example, have you specified accessible labels for any graphic-only elements?)
- How will users learn the new way of doing things? Describe any help pages required, and any changes to the Ubuntu Web site or installer slideshow.
- Is any migration of data or settings required?
How will the feature be tested? Please add an entry to http://testcases.qa.ubuntu.com/Coverage/NewFeatures for tracking test coverage.
Unresolved issues
Highlight any issues that should be addressed in further specifications, and not problems with the specification itself; since any specification with problems cannot be approved.
Unity8/JabberIntegration (last edited 2013-11-16 18:59:38 by 95-91-236-250-dynip)