Site Re-skin:
New look & feel for 2014
Financial Aid:
Last year the PSF handed out over $100,100 in financial aid. The 300 applications were managed manually using email and spreadsheets. This year we'd like build-in support for financial aid application processing in the main PyCon website. The financial aid application process should be similar to the talk submission process:
- Applicants should sign up for a PyCon account to apply for financial aid
- All non-sponsorship accounts should be able to submit an application for financial aid
- An email confirmation should be sent to the applicant after submitting a financial aid application
- The system should facilitate a financial aid committee similar in functionality to the current talk review committee
- The financial aid committee should be able to review and comment on the applications
- Applicants should be able to edit their submission based on feedback from the committee
- Applicants should be able to see their application status via the PyCon website
- Gender will need to be collected for financial aid applications for room-sharing purposes
- The financial aid application should include a section asking about their goals and involvement in the Python community
- The financial aid application should include $$$ amount requests for: hotel, flights, and registration
- The financial aid application should include dates for their hotel stay
- You should be able to pair aid recipients for room-sharing based on their hotel dates and gender
- Ideally we would be able to register these pairs for hotel rooms easily using the PyCon site
- Admins should be able to filter applications based on their talk/tutorial/poster acceptance status
- Admins should be able to accept a financial aid application and enter the amount awarded (for hotel, for flights, for registration)
- Admins should be able to decline a financial aid application and enter a reason
- The system should email the applicants their accept and decline results
- The financial aid application process should have configurable start and end dates
- Applicants should be encouraged not to register for the conference
- The financial aid application should indicate registration status (not registered, registered as a student/early-bird/etc)
- The system should allow admins to indicate how the money will be dispersed (cash, pre-paid visa, paypal, etc)
- The system should be able to transfer funds electronically to aid recipients when possible
- Accepted applicants should be emailed a discount code for tutorials
- Accepted applications should be emailed a discount code for registration
- Ideally the system would be able to refund registration in cases where the grant should cover registration
- Applications should be able to be marked as paid once the grant has been dispersed
- Financial aid applications should open when registration opens: September 1st, 2013.
Tutorials:
Tutorial needs, in order of importance. Below are more details on two of the items.
- Communication between instructions and students
Add a means for communication from teachers to students via website pages with email notifications. See below for further analysis and some possible solutions
- Tutorial Registration Numbers
Add a means for tutorial instructors to securely check the number of students enrolled for their tutorial, in addition to a more general report of all tutorial registrations by tutorial that organizers can check.
Fix tutorial caps so they leave space for sponsors and ideally are visible to registrants.
- Tutorial-Specific Proposal Form
The current proposal system is tailored for talks and falls short supporting tutorials in several areas. See more details below.
- Uploads of Handouts and Slides
Accept handouts for printing to be uploaded to the PyCon website attached to the tutorial proposal a couple of weeks before the tutorial, insteda of manual collection via email. Allow multiple attachments, some to be printed others not. This could be extended for collecting talk slides and posters.
- Prerequisites as part of Registration
When students register for a tutorial, show them the prerequisites for it as part of the registration process. This assumes it's a separate field.
Allow for a Student Survey to the registration process for specific tutorials for collecting information such as what te student hopes to learn. This could be useful more generally, e.g. for soliciting volunteers, collecting preferences on tracks, etc.
More details: Communication between instructions and students
One of the pain points in past years has been communication from teachers to students in the weeks or days leading up to tutorials.
Tutorial proposals usually list some prerequisites, but many tutorials require significant and complicated software installs on student laptops, or other preparation by students, in order to maximize the benefit of the time in the tutorial. Often the detailed instructions aren't ready or finalized until shortly before the tutorial, and sometimes teachers want to remind students to prepare for the tutorial as it approaches.
What is needed primarily is a means for teachers to communicate information to students while maintaining the confidentiality of student email addresses from the teacher and from each other. A nice-to-have would be a way for students to reply to the teacher's communication, or possibly to other students, without exposing their email addresses.
One solution to the primary requirement would be:
- Create a page on the PyCon website for each tutorial with write permission granted to the teacher of the tutorial.
- Add a means to notify the tutorial's registrants either of each edit made to the page, or perhaps only when the editor of the page publishes a change that is intended to trigger notification. The most straightforward notification method would be email to the address supplied by registrants, although other means such as RSS or Twitter could be considered.
- When a user registers for a tutorial, they are automatically subscribed to changes to the tutorial page. In addition, to support registrations that happen after the page has been edited, if the page already exists or has triggered previous notifications, a notification should be sent to the registrant about the page change or publish event.
Pros:
- It follows a well-known pattern of subscribing to website page changes, and might leverage existing software plugins for that.
- It may support a more general page subscription feature.
- It creates an archive of tutorial preparation instructions for the tutorial, and one that lasts beyond the tutorial days.
Disadvantages:
- If a teacher wants to send multiple discrete message, the interface of a single page may not be intuitive to teachers or students. Consider the use case of an initial communication, followed by a new registrant, followed by an updated communication. It may not be obvious to the teacher how to structure the page or edits to the page to communicate well both to those who received notifications of both versions, and also to those who only received the later version. The revision history of a page would help.
- It's a less well-known pattern than email.
More details: Tutorial-Specific Proposal Form
The current proposal system is tailored for talks and falls short supporting tutorials in several areas.
- Choosing a 30 or 40 minute time slot
- One dimensional "Audience Level", does intermediate mean Python ability or domain-specific (e.g. statistics) ability.
- "Extreme" option, not useful for tutorials.
- The "Abstract" section is very broad. It might make sense to split it into several fields at the system level instead of trusting proposers to corretly follow the instructions at https://us.pycon.org/2012/tutorials/proposals/.
- It may be nice to record Tutorial Assistants with the other tutorial information, although some won't be assigned until much later.
General Admin Usability:
- Finding a particular proposal is really tedious. The various proposal admin pages should list the proposal title (sortable), presenter name (sortable), and include the ability to search by presenter name or proposal name.
- The various user picklists in the admin panel look like this, making it really hard to find and select the correct user, especially since there are 2000+ users. All user picklists in the admin panel should use the format: "first name and last name (username)" and be sorted by first name, last name, username.
Related: last minute speaker changes were hard. It was very difficult to add a speaker or change a speaker on a poster inside the admin proposal detail view. Posters that had multiple speakers were very difficult to alter as well. On the poster detail view the speaker attribute had a single item drop down. I'm not sure what would be the best or easiest way to change it but some alteration to the speaker area on the proposal would be really helpful.
- Finding a particular presentation is also difficult. The presentation admin list is currently a mix of posters, talks, and tutorials. The admin list should contains sortable columns for presenter name, presentation title, and presentation type. You should also be able to filter by type, and search by title etc.
- You should be able to mass email the following targeted groups:
- All accepted poster presenters
- All accepted talk presenters
- All accepted tutorial presenters
- All tutorial attendees (scoped to a particular tutorial)
Sponsorship Admin:
- The sponsorship admin list should be sorted by name, not be limited to 100 per page, and include a sortable visual indicator for each sponsorship benefit (completed, missing, not applicable) as well as the sponsorship level, admin contact name, and an active or not indication.
- You should be able to email all sponsors that are missing required content
- You should be able to easily export a zip of all sponsor web logos in the following format, so that they can be imported into the mobile guide etc
web_logos/
platinum/
company_name1/
file_name
company_name2/
file_name
gold/
company_name3/
file_name
company_name4/
file_name
silver/
company_name5/
file_name
company_name6/
file_name
...
- You should be able to easily export a zip of all sponsor print quality logos in the following format, so that they can be sent to the print team.
print_logos/
platinum/
company_name1/
file_name
company_name2/
file_name
gold/
company_name3/
file_name
company_name4/
file_name
silver/
company_name5/
file_name
company_name6/
file_name
...
Green Room Perspective:
- An update to the schedule UI which makes it obvious which slots are missing volunteers (runners and chairs). Should be able to filter by speaker, by runner, by session chair, by day. Example use cases:
- Alice wants to volunteer, and it needs to be very easy for her to figure out where she can help.
- David is running session staff, and he needs to know which sessions are missing staff so he can badger his friends.
- A JSON API which returns the entire schedule, including the room name, speaker name, talk title, runner name, and chair name for each talk.
- We need to have also a field for any special request made by the speakers for their talks (A/V requirement, multiple microphones, a table...) cause right now we are using a google doc but we need a better centralized place for that.
- A way for the speakers to upload their slides on the website, like that we'll just exporte them directly on speakerdeck with a magical script after
Talks:
A better editor for talk proposals. The current format is something that's "almost markdown" but tons of speakers really struggled with getting formatting right. WYSIWYG would be good, or "real markdown" -- as long as there's a preview.
Other Events:
Last year we used Eventbrite to track attendance for things like young coders and the education summit. It would be nice to have these events use the PyCon registration system instead. Ideally, we would be able to easily add new events without a lot of code etc.
Localization:
The main site content should be 100% available in both French and English. The CMS is exempt from this requirement.
Talk Management
- we should be able to store the status of talks (accepted, rejected, in thunderdome, etc.)
- we should be able to store IRC logs and votes about a talk
- talks, tutorials, posters, and lightning talks should be separate entities
- reviewers (program committee members) should be able to tag talks with zero or more arbitrary tags
- we should be able to filter talks by tag
- we should be able to specify what the fields for talk submission are, and they should be able to differ by type (talk, tutorial, etc.)
JSON API:
A real API: read and write. Some easy format like JSON -- to access all the various proposal, speaker, sponsors, talk data etc (anything that might need be imported into another system like the mobile application, or used for reporting). Read is more important than write. Write is a nice to have.
For talks: We should be able to update the status of a talk, as well as store information about it (e.g. votes in IRC). We could provide the data points we want stored, or we should just store an arbitrary JSON block.
Merge:
Merge the pycon2013 branch back into Symposion master.
Lightning Talks:
Make lightning talks a first-class proposal/scheduled type. Should be 90% similar in functionality to talks, tutorials, and posters.
On Site Volunteering Management:
Integrate into Conference Site
In past years, we've had Session Staff volunteers tied to registration ID, and done on the site. Other volunteering linked off site, this past year perhaps most usably to google docs. It would be simpler for volunteers to do this directly from the conference site.
- add schedules per http://bit.ly/PyCon-2013-Registration-Volunteer (see all tabs at bottom)
- additionally, add tutorial support & UnCommittee (tutorial setup, new-to-pycon) signups;
- Volunteer schedule (table) creation should be easy to do / add / modify on the fly (at the conference) for staff w/ admin on the site (but without requiring any more than edit rights);
Registrant's schedule should show their volunteering committments also;
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent