SummitChanges

Differences between revisions 1 and 11 (spanning 10 versions)
Revision 1 as of 2010-02-04 00:16:35
Size: 598
Editor: unassigned
Comment:
Revision 11 as of 2010-02-10 22:38:29
Size: 4041
Editor: c-76-112-233-201
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Summit System Assessment =  * '''Launchpad Entry''': UbuntuSpec:foo
 * '''Created''': <<Date(2005-10-25T15:45:54Z)>>
 * '''Contributors''':
 * '''Packages affected''':
 * '''See also''': SpecTemplate
Line 3: Line 7:
== Current System Assessment == == Summary ==
Line 5: Line 9:
=== Problems === The "summit system" we use for the Ubuntu Developer Summit needs to be fixed.
Line 7: Line 11:
Functionality: == Rationale ==
Line 9: Line 13:
 * Conflicts with multiple people scheduling - seven people scheduling can cause conflicts.
 * Blueprints should not be used to schedule sessions - blueprints are for specs not sessions, and don't apply to roundtables and private sessions.
 * BoFs can't have attendee subscribers - adding BoFs and roundtables cannot use the collision system for attendees.
The summit system is showing it's age, as we increase the number of sessions, tracks, and people who schedule things it gets slower and more cumbersome to use.
Line 13: Line 15:
Development / Deployment: == Use Cases ==
Line 15: Line 17:
 * ISD have limited capacity and limitations around release.   * Matt is a track lead and runs into Joe in the hallway. Joe wants a session to be added to the schedule but doesn't need a blueprint. This is impossible to schedule.
  * Amber has been tagged as a volunteer videographer for UDS but doesn't know how it matches her schedule. The summit system automatically tags and shows her which sessions she needs to videotape.
Line 17: Line 20:
=== Benefits === == Scope ==
Line 19: Line 22:
== Next Steps == These fixes are for UDS-M, anything after is out of scope.

== Design ==

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.

=== Implementation Plan ===

TBD

== Implementation ==

== Outstanding Issues ==

 * Schedule session button:
   * Allow a scheduler to schedule a session on the fly without having to register a blueprint so people can schedule BoFs quickly.
   * [[attachment:summitbutton.png|Mockup]]
   * Clicking on the button will spawn a lightbox with 2 fields, title and description for the session and an ok/cancel button. [[attachment:summitbutton2.png|Mockup 2]]
     * Clicking on ok will accept the session and then add it to the sidebar, where the scheduler can schedule it.
     * Clicking cancel will take the user back to the normal view.
   * When the session is on the sidebar it can be dragged into a time slot.
 * A field for "crew" and "videographer"
   * So we can use the system to schedule crew with the conflict resolution.
   * The role is then integrated into the person's personal view so it's on their schedule.
 * Design review
   * Input from the design team as Mark has ideas on what he wants the schedule to look like design-wise
   * Needs to look as professional as our main website, since partners and upstreams come to UDS.
 * "Big screen friendly"
    * When on display at UDS we need to have a clock on the schedule that won't scroll off so people can see where we are in the schedule. A [[http://people.csail.mit.edu/rahimi/marcus-bains-line/|Marcus Baines Line]] would be great.
    * Ensure the page elements show up even on scroll, list of rooms, time slots, etc.
 * iCal Support
    * Needed so we can have the IRC bot announce sessions in the channel
    * So people can use their phones for the schedule.
 * Auto-generate the time slots.
    * We run a SQL query to generate blank slots to drop sessions in, this is annoying, and making them by hand is time consuming.

 * Performance review - ISD added memcached support which improved the performance considerably. We need to find a way to generate the schedule without hammering launchpad over and over.
 * Archive old UDS schedules.

----
CategorySpec
  • Launchpad Entry: foo

  • Created: 2005-10-25

  • Contributors:

  • Packages affected:

  • See also: SpecTemplate

Summary

The "summit system" we use for the Ubuntu Developer Summit needs to be fixed.

Rationale

The summit system is showing it's age, as we increase the number of sessions, tracks, and people who schedule things it gets slower and more cumbersome to use.

Use Cases

  • Matt is a track lead and runs into Joe in the hallway. Joe wants a session to be added to the schedule but doesn't need a blueprint. This is impossible to schedule.
  • Amber has been tagged as a volunteer videographer for UDS but doesn't know how it matches her schedule. The summit system automatically tags and shows her which sessions she needs to videotape.

Scope

These fixes are for UDS-M, anything after is out of scope.

Design

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.

Implementation Plan

TBD

Implementation

Outstanding Issues

  • Schedule session button:
    • Allow a scheduler to schedule a session on the fly without having to register a blueprint so people can schedule BoFs quickly.

    • Mockup

    • Clicking on the button will spawn a lightbox with 2 fields, title and description for the session and an ok/cancel button. Mockup 2

      • Clicking on ok will accept the session and then add it to the sidebar, where the scheduler can schedule it.
      • Clicking cancel will take the user back to the normal view.
    • When the session is on the sidebar it can be dragged into a time slot.
  • A field for "crew" and "videographer"
    • So we can use the system to schedule crew with the conflict resolution.
    • The role is then integrated into the person's personal view so it's on their schedule.
  • Design review
    • Input from the design team as Mark has ideas on what he wants the schedule to look like design-wise
    • Needs to look as professional as our main website, since partners and upstreams come to UDS.
  • "Big screen friendly"
    • When on display at UDS we need to have a clock on the schedule that won't scroll off so people can see where we are in the schedule. A Marcus Baines Line would be great.

    • Ensure the page elements show up even on scroll, list of rooms, time slots, etc.
  • iCal Support
    • Needed so we can have the IRC bot announce sessions in the channel
    • So people can use their phones for the schedule.
  • Auto-generate the time slots.
    • We run a SQL query to generate blank slots to drop sessions in, this is annoying, and making them by hand is time consuming.
  • Performance review - ISD added memcached support which improved the performance considerably. We need to find a way to generate the schedule without hammering launchpad over and over.
  • Archive old UDS schedules.


CategorySpec

SummitChanges (last edited 2010-02-11 06:31:37 by c-67-164-44-209)