|
|
| (4 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| − | =General Requirements=
| + | deleted; see [[Dash_Project/Submission_System]] |
| − | ====Same As Last Year====
| + | |
| − | In the absence of any specific instructions, the website and submission system features this year should be the same as those from last year. Last year's systems worked well enough and were understood by the EclipseCon audience.
| + | |
| − | | + | |
| − | ====Allow Incomplete Entry====
| + | |
| − | As a general rule, we will allow incomplete entry of information. However, if an entry (a user account, a submission, etc) is incomplete it may not be processed until it is complete. Additionally, the system will send reminder emails on a regular basis (every few days) to the user explaining the incomplete state and the consequences of an incomplete entry (won't be reviewed or whatever) and explaining how to complete the entry (return to the submission system, sign in, enter data) or how to withdraw the entry (etc).
| + | |
| − | | + | |
| − | ====Website CVS or Web Page Configurations====
| + | |
| − | The systems must be configured through resources accessible by the SuperUsers. Thus they must be configured either through files checked in to the eclipsecon.org CVS repository or through web pages. This includes submissions types, categories, email templates, workflow, ... everything.
| + | |
| − | | + | |
| − | ====Eclipsecon.org Website Primacy====
| + | |
| − | As much as possible, the text and templates should come from the eclipsecon.org website. For example, all help links should go to eclipsecon.org web pages (and those pages should be configurable as above). For example, all email templates should be to eclipsecon.org web pages with template values (e.g., "{NAME}" and "{SUBMISSION_URL}").
| + | |
| − | | + | |
| − | ====No Popups====
| + | |
| − | The user interface will not have any popups except, if needed, for help and for uploading files.
| + | |
| − | | + | |
| − | ====Enable Mashups====
| + | |
| − | The website <--> submission system web APIs will be documented and made available to the larger Eclipse community for mash-ups, etc.
| + | |
| − | | + | |
| − | ====Terms of Use and Privacy Policy====
| + | |
| − | All website and submission system pages will have a footer that links to the Eclipse Foundation terms of use and privacy policy.
| + | |
| − | | + | |
| − | =EclipseCon Website Features=
| + | |
| − | The EclipseCon website uses the submission system to provide data for the lists, tables, and detail pages. The communication between the website and the submission system must (be):
| + | |
| − | * Quick, thus minimizing latency and bandwidth are important. Redundant information must not be sent (i.e., if someone is an author of two papers, only one bio is sent).
| + | |
| − | * Work remotely because the website is developed on local developer machines and only uploaded to CVS upon release
| + | |
| − | * Easily switched back and forth between the live submission system and the staging/test submission system
| + | |
| − | * Cached for quick response with an easy way for super-users to clear the cache. Additionally, the submission system must be able to clear the website cache when website-visible changes are made to the submission system.
| + | |
| − | | + | |
| − | The 2007 website made the following kinds of queries to the submission system:
| + | |
| − | * all by type
| + | |
| − | * all by category
| + | |
| − | * all on day X
| + | |
| − | * just one
| + | |
| − | | + | |
| − | The submission system must be able to provide the following pieces of information to the website, although not all requests require all this information (the exact information that flows back and forth needs to be optimized):
| + | |
| − | * Title
| + | |
| − | * Authors (names, affiliations, bios, pictures)
| + | |
| − | * Presentation file(s)
| + | |
| − | * Scheduled time and location
| + | |
| − | * Abstract
| + | |
| − | * ISBN numbers
| + | |
| − | * Submission system url
| + | |
| − | | + | |
| − | =Submission Workflow=
| + | |
| − | ===Admin===
| + | |
| − | The super-users must have the ability to edit any field of any user or submission and to delete/deactivate any user or submission.
| + | |
| − | | + | |
| − | ===Users===
| + | |
| − | People will be able to go to the submission system site and create a user page.
| + | |
| − | | + | |
| − | There will be a link on the user page that opens a new page that will preview their user information on the EclipseCon website. The preview page will be a detail page using a fake submission with the [http://en.wikipedia.org/wiki/Lorem_ipsum lorem ipsum text] as title and abstract.
| + | |
| − | | + | |
| − | User account creation must use the email confirmation mechanism for creating accounts in order to prevent spam accounts. In other words, I request that an account be created and enter data. The account is not yet created. I am sent an email with a link. I have to click that link to activate the account.
| + | |
| − | | + | |
| − | When a user account is created, the user is sent a (second) welcome email.
| + | |
| − | | + | |
| − | ===Submission===
| + | |
| − | Registered users can create new submissions. The usual way for people to create their first new submission is to go through the eclipsecon.org page that describes all the categories and then to click on one of the icons on that page - that means that the submission system needs to have urls with ?category=foo&type=bar style parameters to pre-configure the submission form.
| + | |
| − | | + | |
| − | The submission form will have help paragraphs above each text entry area describing and assisting the user in filling out that section. These paragraphs must be configurable (as above) and HTML.
| + | |
| − | | + | |
| − | Submission fields include:
| + | |
| − | * Title
| + | |
| − | * Abstract
| + | |
| − | * ISBN Numbers
| + | |
| − | * Presentation file
| + | |
| − | | + | |
| − | There will be a link on the submission page that opens a new page that will preview their submission on the EclipseCon website. The preview page will be a detail page. The submission database will keep track of whether the user has previewed their submission and if not, will send a reminder email that they might want to do so.
| + | |
| − | | + | |
| − | When a submission is created, an email is sent to all the co-authors thanking them and explaining the rest of the process, upcoming deadlines, etc: "Thanks for submitting to EclipseCon. Here's what's going to happen next: review process, dates. If your talk is accepted, here's what you can expect: speaker agreement, two free registrations, slides due by."
| + | |
| − | | + | |
| − | All of the co-authors on a submission have equal rights to modify the submission. All program committee members have author-rights to modify the submission. Each time the submission is modified, all the co-authors and any people on the cc list are sent a notification email.
| + | |
| − | | + | |
| − | ===Withdraw===
| + | |
| − | All co-authors can, at any time, withdraw or cancel a submission. A submission can be withdrawn at any time before it become ACCEPTed; after being ACCEPTed, it can be CANCELed. The difference is in whether the session is shown on the conference website: withdrawn submissions are not displayed, canceled are displayed with a "canceled" message.
| + | |
| − | | + | |
| − | Submissions that are withdraw/canceled cause an email to be sent to all co-authors and the cc-list.
| + | |
| − | | + | |
| − | ===Comments===
| + | |
| − | At any time during the process (absolutely any time, include before the conference, after the conference, etc), comments can be added to the submission. Comments can only be added by registered users (registered users are those who have created an account on the submission system and thus have a valid and verified email address; what I mean here is that we are not going to allow anonymous comments). When a comment is added, email is sent to all the co-authors and interested parties via the mailing list.
| + | |
| − | | + | |
| − | ===Reviewing===
| + | |
| − | During the review period (end of November, beginning of December for EclipseCon 2008), the program committee members will be reviewing the submissions and making decisions about accepting and declining. A number of mechanisms are needed to support them in this:
| + | |
| − | * tentative accept/maybe/decline - this state is visible to the program committee but not to the general public. This state is used by the program committee to start allocating the submissions into buckets for further consideration.
| + | |
| − | * queries for:
| + | |
| − | ** all or tentative-accept or tentative-maybe or tentative-decline or not-yet-tenative or a subset of all these..
| + | |
| − | ** ..submissions in a category or of a type or in a category of a type or all categories and types..
| + | |
| − | ** ..sorted by submission number or by number of votes
| + | |
| − | * the queries show the number of submissions that are TA, TM, TD, and not yet categorized. In addition, the queries should show the allocated number of slots for the category (fetched from a table on the eclipsecon.org website).
| + | |
| − | * a way to operate on multiple submissions simultaneously, i.e., to mark these N submissions as tentative accept or tentative decline
| + | |
| − | * a way to operate on multiple submissions at the same time, e.g., a list of all the submissions with a vote and comment field next to each row
| + | |
| − | * comments that the program committee add to the submissions during the review process '''are''' visible to the general public, i.e., they are just normal comments
| + | |
| − | | + | |
| − | Neither the program committee nor the community will be using voting this year. It proved to be too difficult to make work effectively (socially).
| + | |
| − | | + | |
| − | ===Conditional Acceptance===
| + | |
| − | On or around December 10th, the program committees (sub-committees) will use the "do accept-declines" button on the website (a button that should have a secondary confirmation step to prevent accidental use). This button will convert:
| + | |
| − | * tentative-accept --> conditional-accept
| + | |
| − | * tentative-maybe --> no change
| + | |
| − | * tentative-decline --> decline
| + | |
| − | * unmarked --> no change
| + | |
| − | | + | |
| − | Conditional acceptance will send an email to all the co-authors explaining that conditional acceptance is "accepted conditional on your filling out the speaker agreement" and then explaining the rest of the process: speaker agreement --> coupon code for registration; dates for uploading presentation; be sure to proof read your submission information again; etc.
| + | |
| − | | + | |
| − | It will also send an email to the cc-list saying "was accepted".
| + | |
| − | | + | |
| − | Note that only around 90% of the program will be chosen by December 10th, thus this process (review, conditional accept, etc) will continue to be used to add late-breaking ideas and talks as late as up to the conference itself.
| + | |
| − | | + | |
| − | The submission system will keep track of the speaker agreement status for all co-authors. Each time a co-author fills out the speaker agreement, an email is sent to all the other co-authors telling them how many have filled out the agreements and how many more must fill out the agreements before coupons are distributed. When the last co-author fills out the agreement, an email is sent to the co-authors with the N free registration coupons and instructions on how to use them (and an explanation that each coupon is only good once). The submission system keeps track of who (which set of co-authors) was sent which coupon code.
| + | |
| − | | + | |
| − | Each person only needs to fill out one speaker agreement no matter how many presentations they are giving. One talk = one agreement; two talks = one agreement; three talks = one agreement; one talk accepted, fill out agreement, then a second talk accepted later = still only one agreement.
| + | |
| − | | + | |
| − | This agreements and coupons scheme will result in multiple coupon codes being sent to authors who have multiple presentations. That's ok, because as long as the submission system keeps the coupon -> ( set of authors ) information and then supplies that information to the coupon checker (an application that the Foundation is writing), all will be well.
| + | |
| − | | + | |
| − | The speaker agreements mechanism needs to accommodate certain big companies (IBM and others) who want to use a blanket speaker agreement rather than individual speaker agreements. People working for those companies will be considered to have automatically filled out a speaker agreement.
| + | |
| − | | + | |
| − | Operations will need a query that returns who has and who has not filled out speaker agreements. Operations will also need a mechanism for sending a reminder email to those who have not filled out an agreement: "you have not filled out an agreement; if you do not do so by date X, we will be forced to cancel your talk and give your slot to someone else".
| + | |
| − | | + | |
| − | The online speaker agreement is text and thus come from a template from the eclisecon.org website. The online speaker agreement will include fields for title, location, time, etc. If a person is giving more than one presentation, they will need to fill out a speaker agreement for each presentation. The speaker agreements may be customized by presentation type, i.e., if there is a custom template, use that, otherwise use the generic template.
| + | |
| − | | + | |
| − | ====Acceptance====
| + | |
| − | When a submission is completely accepted, an email is sent to all the co-authors thanking them and again explaining the deadlines for presentation uploads, etc.
| + | |
| − | | + | |
| − | ===Scheduling===
| + | |
| − | Submissions will have two schedule fields: tentative and permanent. The scheduling tools will operate on the tentative fields; there will be a single "make the schedule permanent" operation that copies the tentatives to the permanents and triggers the sending of emails. This will allow us to examine various schedules without sending out lots and lots of "your talk has changed" emails. There should also be a "revert tentative to permanent" operation that takes the current permanent schedule and copies it into the tentative fields (as the first step of a schedule exploration).
| + | |
| − | | + | |
| − | Scheduling is a separate step from accept-decline, thus scheduling might happen before or after the acceptance emails have been sent. If before, the emails and speaker agreements will include the schedule and location. If after, the initial emails and agreements will include "TBD" and secondary emails will be sent explaining when and where the talk has been scheduled or rescheduled.
| + | |
| − | | + | |
| − | The scheduling tools use all tentative-conditional-permanent accepted talks.
| + | |
| − | | + | |
| − | There are three scheduling tools: a web page list with form fields, an automatic scheduler, and a drag-and-drop scheduler. The eclipsecon.org website has a special mode for the PC members wherein it uses the tentative schedule information to show the tables and lists and detail pages rather than the permanent schedule information. And in this mode it does not cache the queries.
| + | |
| − | | + | |
| − | ====Web Page Form Scheduler====
| + | |
| − | Query of all accepted talks, one row per talks. Drop down fields for the location (get list of all locations from eclipsecon.org website; list of locations will be type-based, i.e., some rooms are for short talks, some for long, etc.) and time slots (get list of all times from eclispecon.org website; list of times will be type-based, i.e., long talk slots are different than short talk slots).
| + | |
| − | | + | |
| − | The form shows the current values (in the drop downs) from the tentative schedule. When the form is submitted, the tentative values are updated. There is a quick no-dups checker that checks that no two talks are scheduled for the same day, time, and room. If so, it highlights the error in red on the form.
| + | |
| − | | + | |
| − | ====Auto Scheduler====
| + | |
| − | An automatic pre-scheduling tool. This tool will automatically tentatively assign talks to slots.
| + | |
| − | * no two talks are in the same time slot
| + | |
| − | * respect any pre-scheduled talks (such as keynotes)
| + | |
| − | * no author is speaking at two places at the same time
| + | |
| − | * tutorials are on Monday; talks are Tue-Wed-Thu (uses the list of locations and times from the eclipsecon.org website)
| + | |
| − | * short talks go in short slots; long talks go in long slots
| + | |
| − | * categories do not overlap (as much as possible)
| + | |
| − | * short talks are grouped by category (as much as possible)
| + | |
| − | | + | |
| − | ====Drag and Drop Scheduler====
| + | |
| − | A javascript drag-and-drop scheduling page or an Eclipse plug-in. Shows all the available slots and allows the user (a PC member) to drag and drop the talks into, out of, and around in the grid. Uses the list of locations and times from the eclispecon.org website. Reads and updates the tentative schedule fields. Show "same author speaking at two events" violations in red. Uses color coding for categories.
| + | |
| − | | + | |
| − | ===Decline===
| + | |
| − | When a submission is declined (finally, permanently) an email is sent to all the co-authors thanking them for their submission and explaining the situation. It also directs them to the submission system for an additional comments.
| + | |
| − | | + | |
| − | ===Run Up To The Conference===
| + | |
| − | ====Operations====
| + | |
| − | The operations staff require a number of email lists so that they can send reminders to authors:
| + | |
| − | * all accepted speakers (all or by type)
| + | |
| − | * all accepted speakers (all or by type) who have not filled out an agreement
| + | |
| − | * all accepted speakers (all or by type) who have not uploaded a presentation
| + | |
| − | | + | |
| − | It would be best to have a super-user configuration web page that allows us to define new mailing lists as SQL queries against the databases.
| + | |
| − | | + | |
| − | ====Attendees====
| + | |
| − | One mailing list per accepted talk. The speaker can use this to send email to interested people. A mailing list icon will appear on the detail page that will take people to the mail list subscription page. Posts will only be allowed by members; all co-authors will automatically be members. The mailing lists will probably have names like ec2008-talk3456@eclipsecon.org.
| + | |
| − | | + | |
| − | The submission system should list the number of non-author subscribers to each list on the submission page. This is for the authors to gauge the probably attendance at their sessions.
| + | |
| − | | + | |
| − | =Post Conference=
| + | |
| − | Within two months after the conference, the submission system should be shut down and the databases converted to static files while still interfacing with the conference website.
| + | |
| − | | + | |
| − | =EclipseCon 2009 Thoughts and Ideas=
| + | |
| − | The EclipseCon 2008 submission system has been a marginal success: it sort of works (people can submit talks), but the user interface is poor and its too slow and the workflow system is inflexible. It did not meet the goals of improving the process for the participants or program committee. Thus we will try again for 2009. This section collects thoughts and ideas for how to make it better:
| + | |
| − | | + | |
| − | * Handle the case of speakers added or removed after a talk is accepted. Currently the speaker agreement/discount coupon workflow does not handle this.
| + | |
| − | * 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.
| + | |
| − | * All reports are available as spreadsheets
| + | |
| − | * 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. ''(+1 from Oisin)''
| + | |
| − | * Tagging based on target audience (e.g. Committer, Integrator, User) and difficulty (Advanced, Intermediate, Beginner)
| + | |
| − | * Live statistics on searches: how many submissions are accepted versus the allocations (this is a program committee function: the general users do not see this)
| + | |
| − | * live statistics on everything: how many submissions are submitted, accepted, declined, etc. for the authors, for the tags, etc. (PC functions)
| + | |
| − | ** DGG: This should include tracking submissions vs. allocations. In 2008, we had two rounds of allocations and I had to modify them a couple of times, so the PC chair should have the ability to specify allocations as input to the stats.
| + | |
| − | * All searches are urls so they can be passed around
| + | |
| − | * Pop-down JS display of abstracts
| + | |
| − | * Drill-down into searches
| + | |
| − | ** Further restrict and also open to all, e.g., further restrict this search to just this author or re-do a search for everything by this author
| + | |
| − | ** Also "take this search and open back up to all authors"
| + | |
| − | * Searches (and all pages) need to be fast
| + | |
| − | * All actions available on search and detail pages (including "accept/decline")
| + | |
| − | * Require that the users preview their submission before it is submitted (using a portal-like workflow system).
| + | |
| − | * Use regular-expressions to scan the submissions, affiliations, names, etc. for common formatting problems such as including affiliation in name, no capitalization, using wiki syntax in abstract, etc.
| + | |
| − | * A better comment system that is web-based instead of mailing list based. ''(+1 from BorisB - please make it more like bugzilla where it is really easy to add yourself to the cc list for individual submissions)''
| + | |
| − | * Program Committee only based comments. These comments would be invisible to individuals that are not on the program committee. Useful for multi-member categories.
| + | |
| − | * Less spam: Wait for five or ten minutes before sending change notification e-mails, and only send one e-mail for multiple changes that occurred within that five-minute period. (BorisB)
| + | |
| − | * More meaningful spam: Each notification e-mail should come with all important information, such as: who made the change and when, old and new values (nicely ASCII-formatted if possible) (BorisB)
| + | |
| − | * Allow more than one search to be active per user/browser: using the 2007 system, for whatever reason, it was not possible to have two different searches open in two browser tabs such that you could work with both resulting lists (reload, sort by column, etc.) (BorisB)
| + | |
| − | * Better default sorting of search results (group by type, then sort by ID) (BorisB)
| + | |
| − | * Make it possible to add a comment at the same time as changing the type from long talk to short talk, and similar important changes to the submission. (BorisB)
| + | |
| − | | + | |
| − | [[Category:EclipseCon]] | + | |
| − | [[Category:EclipseCon2008]]
| + | |
