Dash Project/Submission System

Requirements

The program committee keeps a private list of potential features [1]. When the program committee decides that a feature should be real, they move it to this public list.

By Role

• All users will need to login with a bugzilla account or a committer account. If the user does not yet have an eclipse bugzilla account, they will be directed to create one.
• Each user has one or more roles. Roles include: author on talk X, program chair, PC member on category Y, operations, super user.
• Roles can be set and modified by the conference chair and superuser.
• All users have the option of providing a bio and a picture. Authors will be requested/required/nagged to create these, others will not.
• The bio edit page will have a “preview” button that will open a dummy presentation on the EC website with a fake title and abstract (with lorem ipsum text) and their real submitted picture and bio. This will allow users to see how they will be presented to the world.

Submitters

• Any user can create a new submission.
• Submissions can be created from a template url a la bugzilla.
• Each submission has a unique url that can be emailed around.
• A submission can have any number of co-authors. If the co-author already has an account, they can be selected from a drop-down or ?.
• If the co-author does not have an account, the system records their email address and sends them an email inviting them to create an account and complete the submission. The co-author does not show up on the submission until they do so.
• Require submitters to preview their submission before it goes “live” in submission system. If not then, at least before they get their coupons.
• Use regular expressions to scan the submissions, affiliations, names, etc. for common formatting problems such as including the affiliation in name, no capitalization, using wiki syntax in abstract, etc.
• Have a “not attending” option for authors so that we can distinguish between not attending and not yet registered.
• When a submission is created, the “Thanks” email is sent to all the co-authors telling them what to expect, the various deadlines, the speaker agreement, etc.
• Authors (and PC members, etc) can withdraw/cancel their submissions. (We differentiate between removing oneself as an author from a talk that has other authors and canceling a talk completely.) Talks are marked as either withdrawn or canceled. Canceled talks show up on the program listing and grid marked as “canceled” - withdrawn ones do not. A talk is withdrawn up until it is advertised publicly on the website, if withdrawn after that it is marked “canceled”.
• Signed speaker agreements are always accessible even after they have been signed (they will be linked from the talk page and from the personal page). Unsigned ones that are waiting to be signed also, of course. In other words, the author should be able to get to his/her agreements either through the emailed urls or via links on their submission or their personal page.
• If an author wants to send an email to the people on the talk's cc list, he or she adds a comment to the talk.
• The submission system shows the AV setup and repeats that message a number of times in the reminder emails. It includes “if you have special requests, please send email to operations@”

Community

• Tagging? Tag with Eclipse projects involved in the submission, technologies involved in the submission, the kind of submission (research, experience, project report, how to), etc.
• Tagging based on target audience (e.g. Committer, Integrator, User) and difficulty (Advanced, Intermediate, Beginner)
• Comments can be posted to any submission.
• Can add yourself to the cc list of any submission or any category or any type or everything. Even better if the user is logged in the “add myself as cc” should just be a button because we already know their email address.
• The list of submissions and comments is also available via RSS feeds.
• Wait five or ten minutes before sending change notification e-mails and roll up all changes in that time into a single email. Reduce spam!
• Notification emails should come with all information including who made the change, when, old values, new values, etc. In ASCII.
• The public view of a person's bio information (public = via the portal) should include a list of all their submissions, accepted ones first, declined ones second.

Program Committee

• Live statistics on slot allocation used and remaining; talks submitted, accepted declined; same for each tag - as a header or footer to all searches.
• All actions (including accept/decline) need to be available every place a reference to a talk appears. On the detail page for that talk; with each row in a search result; etc.
• Searches that work like the commits explorer: once you have a page of results, easy to click into further refinement, easy to click to larger scope. For example: click on an author to restrict the search to the original search + author=this author – click next to a talk talk to become “the original search but for all talk types”. Another click (not sure how this is going to work on the UI) to change the search to “everything by this author”. Etc.
• All search terms are in the url thus one can have multiple searches open simultaneous in multiple browser tabs. No cookies or session variables.
• Default sorting of search results: by type, then by id. Click to manipulate the sorting.
• Pop down javascript of the abstract.
• All important changes (change from long to short, etc) should include a comment thus it has to be possible to add a comment at the same time as making these changes.
• Program committee can do tentative accept/decline or actual accept/decline. There are also "tentative pending" and "pending" state for those on the bubble. The tentatives are made permanent when the big button is pressed.
• Accept/decline can include a room and time if desired or it can be left to later.
• Ability to operate on multiple submissions simultaneously such as "mark these N as declined"

Program Chair

• Allocate and reallocate slots.
• Algorithm for preliminary scheduling: do an auto-fill with user-definable constraints (minimal category overlap, even category distribution throughout the week, forced talk ordering, no speaker overlap, minimal categories that always end up in parallel.) Then the program committee can tweak from there.
• Scheduling tool uses rooms and times and slots from operations: those are the only slots that can be used. Both for drag and drop scheduling and regular form-based scheduling.
• Acceptance email includes the schedule if the schedule is set, otherwise TBD and another email is sent later.
• Scheduling tool checks for overlapping speakers.

Operations

• Admin portal box. Reports include:
  • Coupon checker reports
  • Speaker agreements: this report should list each session title, what type of session it is, when/where it’s scheduled, who the main submitter is, the additional presenters, whether an agreement has been signed or not, when they were accepted, when the last reminder went out, when it was completed, and any special things the speakers had the option to note (like video waiver, etc)
  • All authors: name, link to bio, email, sessions (hyperlinked)
  • All sessions: session, title, date, time, room, type, category, authors
  • Search box
• Specify the number of slots by specifying the rooms, times, and slots in those rooms. Slots are assigned to different types - long, short, reception, etc. - and those kinds are used in the scheduling tool.
• Super users will have all privs and actions
• Talk grids are downloadable as Excel spreadsheets (same layout).
• Produce MSW-style staging guide document.
• Text document download of special event descriptions.
• List of status of all speaker agreements: signed/unsigned.
• A “resend invitation to sign speaker agreement” next to each speaker agreement. Thus if operations finds that person X has not signed their agreement, then can click the button to resend the email.
• Place for the +1/0/-1 evaluation totals to be entered for each submission online and in real time. Then the totals can show on the conference website. Should also have a page for entering batches of these totals, in other words do not require ops to go to each detail page to enter the numbers – they will probably have a stack of envelopes to go through and want to enter them quickly.
• Operations can push a button to say “as of this date, notify us of any changes”. It may even be automatically enabled when certain reports are downloaded (although that would make testing the reports difficult, hmm). The notifications will be daily and will include: session, title, date, time, room, type, category, atuhors. Obviously those are also the fields that need to be monitored.
• Each submission should have a field for AV setup. If blank, it uses the default. Only operations can set this field (authors cannot).
• Speaker agreement comes from conference website template
• Operations can send emails to various groups such as "to all speakers who have not signed an agreement: if you do not sign your agreement by date X, your talk will be dropped from EclipseCon"

Other Items

Use Cases That Must Be Covered

• Primary contact who is not one of the speakers (not the usual case, but we should handle it).
• Defining the order of speakers shown on the website (this is important for travel approval for some companies) (and important for correct credit for others)
• Handle a change in speakers at any point in the process, including after the talk has been accepted, after all the agreements have been signed, after speakers have registered. Upon a change, make sure that all the agreements are signed, coupons distributed/disabled, etc. to return the talk to the previously achieved state.
• Contact person, primary author, and co-authors all must be able to change equally easily.
• Different kinds of submissions need to have different workflows. For example, some need speaker agreements and some do not. Some are controlled by operations and some are controlled by operations and some by Wayne. Etc.

Universal Features

• In the absence of any specific instructions, the submission and website features should be the same as in 2007/2008.
• Submission numbers and author numbers (if there are numbers) should be visually distinct. For example, if we use four digit numbers for submissions and three digit numbers for authors, those are visually distinct. Or “Snn” for submissions and “Ann” for authors. Or...
• Search should search authors, titles, and abstracts.
• All reports that are available as lists or tables on the website must also be downloadable as spreadsheets (CSV or XLS).
• All searches and reports are defined in urls so that they can be copy-pasted, emailed, IMed, and generally passed around.
• Searches that show lists of titles should have JS hover that popups the submission abstract.
• All pages that show interesting data should be linked to other interesting data. By this I mean that if a title is shown, it should be a link to the detail page for that talk. If an author is shown, it should link to the person's detail page. If a category is shown, it should link to a search for that category. Etc.
• All emails should include the url to the relevant submission(s) and/or user(s). Make the emails one-click to results.
• All transactions are logged and a complete audit trail of every submission.
• Email template from conference website a la 2008
• Super-user/conference chair definable workflows for each kind/type/category. Only the pre-defined workflows can be chosen.
  • Talks: submit, review, specified sub-PC tentative accept/decline, big button (there might be many big buttons, one for Scott, one for Donald, etc), agreement, coupon
  • Misc: submit, sub-PC accept/decline

Operational Details

• Cache pages. Making a change to the database should clear the cache.