-
Notifications
You must be signed in to change notification settings - Fork 21
scratchpad
I'm logging progress on this scratchpad and hopefully it can turn in to the basis for an intro to setting up a conference site using symposion and we can share it with other conferences.
pycon's readthedocs http://pycon.readthedocs.org/en/latest/ They are on a different version of symposion but docs are handy.
http://symposion.readthedocs.org/en/latest/
schedule app
I wrote a management command to regenerate schedules. I hate checking in flawed things, but I am being pragmatic. and maybe people will learn from the mistakes.
oh the tables. tracing logic to see how schedule objects are rendered in a grid is painful. We can contribute some improvements to the docs a lot here.
- duplicate slotkinds at hte same time cause a span, so this is good if you want osmething like keynote to show for the entire row
- staggered talk times are tricky. see #127.
- while trying to work through creating and destroying schedules to see how staggered slots are rendered, I forgot how I made accepted proposals becomes presentations. I ack-grepped the symposion code as a reminder. It's management command, promoteproposals.
- the dropdown edit interface for schedule slots are controlled by whether the slotkind is a presentation or not. in our fork where we've merged hte edit form, this is hard coded. in the branch I'm working on and will merge to our master, it is controlled by a field on the slotkind model.
ugh.
the django admin control of this is very tedious. based on the urls.py in the vanilla symposion repo it looks like /schedule//edit/ should work but I wasn't sure how to get that working and asked on the symposion mailing list. after that, I noticed a pull request from the pyohio fork with some documentation about the schedule app with builder functionality that works with csv files.
I spent time merging that pull request in to our fork (you can't just merge that pull request, you need to pick up some other changes from the pyohio fork -- and then edit them since vanilla symposion doesn't work with django > 1.4 and when we started the scipy conf app we based it off vanilla symposion -- I do not recommend this for next year).
Now that I have that merged. I'm working on figuring out exactly which columns in the csv file correspond to which models so that I can be sure to have enough data in the database for the csv file to be consumed. right now I'm getting some key errors. btw, working out what you need to have to exist for a presentation to exist is a pain. here is a picture.
model dependencies
+----->section (conference app)
| ^
| |
| +
| schedule (schedule app)
| ^
| |
| |
| +----+----+----+
| + + +
| slotkind day room
| ^ ^ ^
| +--------+ | proposalbase (proposal app)
| + + ^
| slot slotroom |
| ^ |
| | |
| + |
+-+presentation+-----------------+
oh the horror!
when we provisioned things we did not think to check the database encoding and our columns have latin1 encoding rather than utf8.
this means we munge names. I have to figure out how to change the encoding without destroying anything. that's in progress.
- Voting does have as much resolution as we wanted. We've got a monster combo of google form and symposion. this isn't a nice user experience.
- a defect having to do with some ungodly trinity of encoding, mysql, and something that wasn't working a couple of years ago for another conference but which got fixed GRARRRR is causing much pain.
We used the default templates that come with symposion for reviews and proposals, and when we wanted customizations we copied the basic templates over to our repo. This isn't documented, and it could be a good candidate for some documentation that explains to conference organizer who use symposion how customization works.
also, for next year, maybe we could start by copying all of the templates so that new contributors to the scipy conference site don't need to make the extra leap of understanding that they need to copy templates. I know there are trade offs for that, so it is something to think about and not a firm recommendation.
- enable proposal submission by changing the related Proposal Section closed attributes.
- Q: how to have someone be able to create reviewers without also requiring super user privs A: https://github.com/scipy-conference/SciPy-2014/issues/19
- document how to flip the site from not accepting talks to accepting talks (based on reading the symposion template, it looks like having no Proposal kinds is sufficient but also changing proposal section might do. need to experiment. haven't read the synposion templatetags and things)
definitely need more documentation here. this is in too much flux to say much for now.
gotchas
- we didn't set SITE_ID automatically when deploying things, so we ended up using the default site, local
- when running locally I'm (Sheila) usually using django's runserver and not nginx/gunicorn and supervisor.
- we've (Andy, Sheila) experimented with using a vagrant box set up like the prod and staging envs.
note: Much of this I learned from Michał Karzyński's blog post on Setting up Django with Nginx, Gunicorn, virtualenv, supervisor and PostgreSQL.
Staging is a community rackspace VM pointed to by http://conference-staging.scipy.org/ (this is actually wrong, I should get the new url)
The site is checked out in ~scipy/site/SciPy-2014.
at one point this was partially done in a bootstrap script partially done in the fabric script, things are still in flux and we'll eventually get everything in one place and done consistently.
bootstrap.sh was a half-baked script that provisions a vagrant box similarly/hopefully how we've got the rackspace environment set up. it's a bit out of date -- Andy created https://github.com/scipy-conference/conference-box to have the most up to date bits and that can get updated as appropriate; however, I think we'll be settling on having a provision task in fabric. It's partially done at the moment.
Thankfully, Matt wrote https://github.com/scipy-conference/SciPy-2014/blob/master/fabfile.py gotchas
- working out how to handle env.user, and also how to target different envs. Matt set up some tasks named after our envs, and the big block of comments at the top of the fabfile explain how to use this
- we didn't comment much at the beginning and would read the source code to know which globals to change, etc. This was tricky when more people started using the script.
a directory structure like this in the site user home directory.
[scipy20131204] [scipy@scipy-staging:~]$ tree -L 2 .
.
├── README
├── site
│ ├── bin
│ │ └── runserver.sh called by supervisor to start site
│ ├── logs gunicorn and access logs
│ ├── SciPy-2014 git repo
│ └── site_media collectstatic here
└── venvs
└── scipy20131204 create a virtualenv for every release
The scipy user needs to be able to use virtualenvwrapper.sh by fiat, so along with whatever else you want in .bash_aliases, include:
if [ -f /usr/local/bin/virtualenvwrapper.sh ]; then
. /usr/local/bin/virtualenvwrapper.sh
export WORKON_HOME=${HOME}/venvs
fi
note: actually, I'm not sure virtualenvwrapper is need. I've only used it when sudo su-ing to the site user. I'll probably recomment dropping this.
We weren't sure how we should set up static files. The problem with rending images & js was that the permissons on the /home/scipy/site/site_media directory were bad and we chmod'd it manually as a workaround. STATIC_ROOT in local_settings.py is set to /home/scipy/site/site_media. Permissions will probably have to be changed each time the static files get generated
Matt eventually worked this out and the real solution is in the fabric file.
Emails weren't going out and that was due to missing settings as well as ignorance about django-mailer for scheduling mails. In staging I updated settings and set up a cron job as detailed in #6. kick me if I don't add information about email to the eventually to exist docs.
gotchas:
- we didn't automated the process of adding a cron job and when we deployed to prod we didn't send mails at first.