OneToOneLiveSupport

Differences between revisions 3 and 4
⇤ ← Revision 3 as of 2007-05-06 11:08:00 →
Size: 4826
Editor: 195
Comment:
← Revision 4 as of 2007-05-06 13:43:34 → ⇥
Size: 1846
Editor: 195
Comment:
Deletions are marked like this. Additions are marked like this.
Line 34: Line 34:
This specification covers feature specifications for Ubuntu and Launchpad. It is not meant as a more general specification format. This will use the recently open-sourced qunu (http://qunu.org) code which facilitates this.
Line 38: Line 38:
A specification should be built with the following considerations:

  * The person implementing it may not be the person writing it. It should be clear enough for someone to be able to read it and have a clear path towards implementing it. If it doesn't, it needs more detail.

  * That the use cases covered in the specification should be practical situations, not contrived issues.

  * Limitations and issues discovered during the creation of a specification should be clearly pointed out so that they can be dealt with explicitly.

  * If you don't know enough to be able to competently write a spec, you should either get help or research the problem further. Avoid spending time making up a solution: base yourself on your peers' opinions and prior work.

  * Specifications should be written in clear, concise and correct English. If you're not a native speaker, co-editing the spec with somebody who is might be a good idea.

Specific issues related to particular sections are described further below.

=== Summary ===

The summary should not attempt to say '''why''' the spec is being defined, just '''what''' is being specified.

=== Rationale ===

This should be the description of '''why''' this spec is being defined.

=== Scope and Use Cases ===

While not always required, but in many cases they bring much better clarity to the scope and scale of the specification than could be obtained by talking in abstract terms.

==== Use Cases ====

Use cases are positive statements which (loosely) conform to a pattern like

  * A person and their role
  * The objective they want to achieve
  * The steps they go through
  * The positive result

Specifically, describing the current unsatisfactory state of affairs is not a use case; that belongs in the Rationale section.		 Using the code from qunu.org an ubuntu-hosted site should be setup to house the web based support system.
Line 77: Line 42:
This section is usually broken down into subsections, such as the packages being affected, data and system migration where necessary, user interface requirements and pictures (photographs of drawings on paper work well).  * Implement the qunu.org code on a hosted site
 * Promote the service to community members
Line 81: Line 47:
To implement a specification, the assignee should observe the use cases carefully, and follow the design specified. He should make note of places in which he has strayed from the design section, adding rationale describing why this happened. This is important so that next iterations of this specification (and new specifications that touch upon this subject) can use the specification as a reference.

The implementation is very dependent on the type of feature to be implemented. Refer to the team leader for further suggestions and guidance on this topic.
Line 87: Line 50:
The specification process requires experienced people to drive it. More documentation on the process should be produced.

The drafting of a specification requires English skills and a very good understanding of the problem. It must also describe things to an extent that someone else could implement. This is a difficult set of conditions to ensure throughout all the specifications added.

There is a lot of difficulty in gardening obsolete, unwanted and abandoned specifications in the Wiki.
Line 95: Line 53:
We'll have a first public session on this on the first Monday in UBZ. To be discussed at UDS-Sevilla

In Progress

Summary

New users to Ubuntu often need support but are confused and overwhelmed by the current support offerings including irc, mailing lists and forums. This specification details a One on One Live support model allowing volunteers to nominate themselves for support to individuals.

Rationale

IRC (specifically the #ubuntu channel) can be overwhelming for new users.

Mailing lists have a barrier to entry (email address and accessible email, subscription process).

Forums also have a similar barrier to entry.

Mailing lists and forums both have no guarantee of an instant response. Whether the response is a fix or not, users often feel more confident when talking to an individual in real time.

LoCo and LUG meetings are great ways to talk to people, but don't tend to happen very often.

Use Cases

  • Alice is a new Ubuntu user, but would like some help getting her system configured.
  • Bob has been using Ubuntu for a while but has come across a tricky problem that he would like to talk over with someone.

Scope

This will use the recently open-sourced qunu (http://qunu.org) code which facilitates this.

Design

Using the code from qunu.org an ubuntu-hosted site should be setup to house the web based support system.

Implementation Plan

  • Implement the qunu.org code on a hosted site
  • Promote the service to community members

Implementation

Outstanding Issues

BoF agenda and discussion

To be discussed at UDS-Sevilla

CategorySpec

OneToOneLiveSupport (last edited 2009-01-16 13:39:22 by students)