Hello, Doug is right.
2008/6/17 Douglas Napoleone <[EMAIL PROTECTED]>: > On Tue, Jun 17, 2008 at 6:24 PM, Paul Boddie <[EMAIL PROTECTED]> wrote: >> Hello, >> >> Here's a message from Ville Säävuori about the conference schedule which >> didn't make it to the list for some reason. I can't see whether there was a >> moderation problem in this case, but I'll gladly do moderation on this list >> if someone will let me into the moderators club. >> >> Paul >> >> P.S. There's a large e-mail from Jacob waiting in the moderation queue for >> the >> EuroPython list because it's a very big message containing some kind of >> template. I've left it in the queue so far because I don't want to either >> send a big message to lots of potentially angry people or to send a message >> without the main payload to such people. Maybe we can upload the template to >> the site. >> >> ---------- Forwarded Message ---------- >> >> From: Ville Säävuori <[EMAIL PROTECTED]> >> Date: 16. kesäkuuta 2008 klo 0.44.07 >> To: [email protected] >> Subject: Re: [Europython-improve] iCalendar of the conference schedule >> >> Hi all, >> >>>> The only PyCon-Tech *code* it uses is the CSS, plus many *ideas* >>>> which using PyCon-Tech last year gave us. >> >> The output is very well formed and therefore also quite easily >> parseable. Paul already provided us a simple script for parsing the >> schedule into an ical-file, and I would like to reproduce my app >> from last year and make all data available in easily searchable and >> mobile-ready form. The example parser from Paul is basically all I >> need for putting this data into database. >> >> My ideas for the schedule data have already been mostly implemented >> in the new PyCon-Tech code. I would like to have *my* conference >> schedule (to not impose these ideas on anyone who doesn't like them) >> have following functionality: >> >> - possibility to log in with OpenID (to customize things) >> - possibility to select sessions that I want to attend >> - possibility to browse this selection (== my customized schedule) >> in a format tailored for a mobile reader (for example smartphone/ >> iphone) >> - simple search functionality for session and presenter details >> - more ways to browse the data trough cross-linking and tagging >> (browse by topic, level, author) >> - a possibility to comment sessions >> >> These are exactly the same ideas I already implemented last year (at >> first just for my own purposes, but eventually as a public site). >> >> [about structured data] >>>> Well, it was talked about, but nobody actually did anything ;) >> >> I'm willing (and very likely to) to do this again and share it as a >> complementary service for anyone who likes to read the schedule in a >> customized format. I understand that organizers have lots of things >> on theirs hands as the conference is getting closer so I don't want >> to be a burden to anyone with these ideas -- especially if someone >> thinks that they are bad or unnecassary. But I also am gladly >> willing to help to integrate these to the official site if needed. They are nice ideas, and very useful to the delegates, but the organisers (especially so near to the conference) have to have more limited objectives: * We need a schedule published on the website, so potential delegates can see what they're getting before registering. * We need to be able to print the schedule, to post around the conference venue, and to put in the delegates swag bags. * We need the schedule to be readily accessible during the conference, in case changes have to be made. and not a lot else. I'd be very happy to work with Ville on adding his functionality, but my time between now and Vilnius will be very limited: if you tell me what you need I'll see what can be done. Also, if we add it for PyCon Uk as well it will be good practice for EP next year. >> (I also want to point out that I implemented previously mentioned >> functionalities last year with Django in _one evening_ taking >> advance of the structured data provided, so I am not talking about a >> monumentally huge commitment.) >> >>>> I'm down to give a talk on the conferencing software at Vilnius, >>>> maybe >>>> it would be a good idea to get together and build in the iCal stuff >>>> for next year. >> >> I'm getting a slight feeling of NIH-syndrome here, since, AFAIK, >> PyCon-Tech system already produces iCal syndication. Would it be OK >> to just try to work on that codebase for next year or are their >> needs totally different from EPs? > The PyCon-Tech code needs a major overhaul. It suffered from massive > feature creep, and multiple CSS redesigns. In case anyone thinks that > PyCon-Tech should have been used for EuroPython this year, the answer > is no. ('Hell no' would be more accurate). I dont think it was a NIH > issue as much as a NTC (not that crap) issue. There is also the issue > of integration with the wiki to make things seemless. I'd confirm this. Last year, for PyCon UK, we tried to avoid NIH, and used PyCon-Tech for the talks submissions and scheduling. Doug was very helpful, but we hit a number of problems, including: * We had to do a lot of hacking on the code because it was (obviously) intended for PyCon US only. For example, messages about Texas kept cropping up. * It suffered from creeping featurism: there were lots of 'nice' extras which we had trouble getting to work, in the end we binned some of them. This (feature creep) is a perennial problem when us geeks get let loose on a system. * At the outset, none of us knew Django, We had been promised help from a Django expert, but in the end it didn't materialise (another geek problem). * There were issues with the stability of the system: we have to face it that systems like Django are very dependent upon the versions of Django/Apache/modpython etc. On a server which has many other applications running you may not be able to change to the version of modpython which Django needs, for example. These issues showed up when some speakers (by definition computer-literate) were unable to make talk submissions and/or upload files and the organisers had to step in and do it for them: by pasting from their emails. * They can be performance issues with many delegates hitting the website during the conference as their schedules are generated dynamically. As a result of this, we've gone back to basics in the way I described earlier: the ultimate objective is to have all the data (let's face it, there's not a lot of it) stored in Python pickles as a lowest common denominator for data interchange. That way any Python programmer of reasonable competence can work on it, without having to know about Django, tg, or whatever happens to be flavour of the month. The schedule is a static webpage. Not very fashionable I know, but practical. > My goal is to have the schedule code split off and as a separate > django app from the rest of PyCon-Tech (actually my plan which has > already started is to break it up completely to the point where only > the proposal system and worst case registration still remain). If that > can be done cleanly, then using the schedule system as a plugin wsgi > app (which will be supported shortly in django) will make generic > integration possible. (the javascript cruft will be broken up and > configurable with the default configuration being 'off' as well). All > of this would have been done this past year, but registration hell > consumed me. > > I see no reason to have one all encompassing conference system, and > the potential for much harm if that does happen. I don't know about harm, but it would be a guarantee of the aforesaid creeping featurism. What we're trying to do with EuroPython and PyCon UK this year is to end up with core registration and talks systems which future EP organisers can pick from and build into their conference websites as/if they wish. This year, the EP site has been done by Paul as a moinmoin wiki, which seems to have been very successful, the main PyCon UK site is static with a wiki and blog attached, but they are both using the same core registration software, and (in the end and somewhat hurriedly) the same talks software. > With that said, some > sharing of resources including code is a good thing (tm) where > applicable. +1 Best wishes, John -- _______________________________________________ Europython-improve mailing list [email protected] http://mail.python.org/mailman/listinfo/europython-improve
