Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Dash Project/Submission System"
(New page: =Requirements= ==Use Cases That Must Be Covered== =History= For EclipseCon 2004 and 2005 and Eclipse Summit Europe 2006 and 2007, we used email submissions. For EclipseCon 2006 and 2007,...) |
(→Use Cases That Must Be Covered) |
||
| Line 2: | Line 2: | ||
==Use Cases That Must Be Covered== | ==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 and before/after all the agreements have been signed. | ||
=History= | =History= | ||
Revision as of 14:14, 1 May 2008
Requirements
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 and before/after all the agreements have been signed.
History
For EclipseCon 2004 and 2005 and Eclipse Summit Europe 2006 and 2007, we used email submissions. For EclipseCon 2006 and 2007, we used a customized bugzilla written by a contractor for a submission system. For EclipseCon 2008, we used a custom php program written by a contractor.
Using emails has many problems, not the least of which are that it does not provide visibility to the authors and that it is a huge amount of administrative drudge work. The bugzilla system was pretty good because the developers are familiar with bugzilla, but our increasingly different (non-bug) workflow required an increasing number of customizations. The custom php program was started with great hopes (new! improved!) but the contractor was unable to deliver.