On Wed, Jun 18, 2008 at 7:09 AM, John Pinner <[EMAIL PROTECTED]> wrote:
> 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.
I should explain the 'harm' I guess.
Anytime there is a monoculture enforces on a diverse culture there is
the potential for harm.
I would hate to have all the PyCon XXX websites look like clones of
each other or even be exact clones of functionality. The python
community is quite diverse and different regions have different local
expertise, knowledge, and areas of focus. The websites should reflect
this. Different conferences will have different requirements and the
local volunteers will run things differently. This is fantastic in my
opinion and should be encouraged. As you noted you could not find any
Django experts to help out, but you did have a MoinMoin expert more
than willing to lend a hand. I wanted to go with MoinMoin, but no one
would step forward and help out (so I ended up writing a partial clone
in django of the features we needed; because I knew that). So in that
reguard there is a little NIH, but the alternative is being confined
and restricted by the 'other' codebase, which is much worse.
There is no one web framework, there is no one conference package, and
a goal of having all python conferences use the same package not only
is doomed to failure, but would do harm to the local communities
running those conferences. There is a group which is putting together
a tubogears based conference management system, one using Roundup
(which already has a conference talk proposal system), and two in
Plone. Some people may view this as a duplication of effort, but I do
not. Some people also feel that there should be one and only one
python web framework.
I do think there is room for sharing tools and code for the different
conferences ala carte, but that requires the software to be written
with that in mind. Key is the differentiation between conference
management and software for the conference.
Many of the issues you raised with PyCon-Tech are already solved in
the current version, others will be solved this year, and yet others
may never be solved.
If any local group wants to use this code I am more than willing to
offer my time to help them out.
I am also watching what EuroPython and PyConUK are doing and hope to
use MoinMoin as the core of the 09 website and maybe even use the
registration system (if I can convince the PSF that PyCon US will not
use their bank account). I will need some help to make that happen,
and some of the insane requirements on the registration system may
prevent this.
(things like coupon codes, registering 20 people in one payment,
tutorial attendance/room size cap management, adding 50 different
options to the registration for things like home town, sprint
attendance, hat size and favorite color... *sigh*)
So fair warning, I am going to be asking a lot of questions around
August (I have been holding back as I know everyone is already
swamped).
-Doug
> 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
