#europython minutes 23rd January 2006

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

#europython minutes 23rd January 2006

holger krekel
Hi folks,

here are my brief notes/minutes about the EuroPython meeting
today, hope i got everything correctly.   Next Meeting is

    6th February 2006, 5pm CET  (60 minutes max)

and will be moderated by Aiste - send her or the europython
list your agenda topics.

cheers,

    holger


EuroPython Orga Meeting 23rd January 2006
----------------------------------------------

Time & Location: #europython 23rd Jan 2006, 5pm-6pm CET

Attendees: Paul Everitt, Michael Hudson, Benedikt Hegner,
           Holger Krekel (moderation), Aiste Kesminaite,
           Jacob Hallen, Alexander Schremm (xorAxAx),
           Christian Scholz (MrTopf), Harald Armin Massa (ghum)

the meeting was ad-hoc moderated by holger.

* Discussion about "Zope" track

  Paul suggests to go for a "Web Frameworks Track" instead
  of limiting it to Zope.  He thinks that this should
  help to get more cross-pollination going within the
  python web framework communities.  There would likely
  be a quota on Zope talks then.  The ideas were welcomed
  by the attendees and will likely be followed up
  on the mailing list and on the upcoming track chair
  meeting.
   
* conference fees
  Benedikt sent a mail to the EuroPython list short before
  the meeting about price calculations.  Apart from the
  fact that a some people want higher speaker prices
  the prices are reasonable.  The fee calculations should
  be decided upon at the next EuroPython Meeting.

* deadlines
  The meeting came up with the following rought timeline:

  15th February  Call for Proposals
  March          Opening online Registration (Payment issue pending!)
  31st March     Deadline for proposal submissions
  30th April     Prelininary Program with accepted talks
  19th May       Closing Early Bird registration

* Renaming EuroPython to Pycon idea
  Holger mentions the idea of renaming EuroPython to Pycon.
  The idea is generally welcomed but a number of people think
  that we should not tackle this for 2006.  Everybody agrees
  that heading for some more discussions with organisers
  from non-europe Python conferences e.g. at Pycon 2006
  makes sense.  The guiding idea is to have a worldwide
  naming/context umbrella for Python conferences.

* next dates:
 
  31st January 5pm Track-Chair Meeting (moderation + agenda: Michael)
  6th February 5pm  EuroPython Meeting  (moderation + agenda: Aiste)


somewhat open topics:

* decision/procedures on conference software (favourite seems
  to be Benedikt's CERN solution for now)
* followup on payment procedures/accounts (IBAN + Creditcard
  payment possibilities desired)
* Website ???
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: #europython minutes 23rd January 2006

Nicolas Chauvat
On Mon, Jan 23, 2006 at 06:19:48PM +0100, holger krekel wrote:
> * Renaming EuroPython to Pycon idea
>   Holger mentions the idea of renaming EuroPython to Pycon.

-1*10

>   The idea is generally welcomed but a number of people think
>   that we should not tackle this for 2006.  Everybody agrees
>   that heading for some more discussions with organisers
>   from non-europe Python conferences e.g. at Pycon 2006
>   makes sense.

+1

>  The guiding idea is to have a worldwide
>  naming/context umbrella for Python conferences.

Why would that be necessary ? IMHO, having two names for two very
distinct events is perfect. At the moment you know that PyCon means US
and EuroPython means Europe. I would welcome PyAsia or LatinaPy,
etc. and try to get there. But if every Python Conference is named
PyCon, you'll have:

A: Will I meet you at PyCon 2007 ?
B: Which one, the one in Europe or the one in the US ?
A: EuroPyCon.

--
Nicolas Chauvat

logilab.fr - services en informatique avancée et gestion de connaissances  
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: #europython minutes 23rd January 2006

Paul Everitt
In reply to this post by holger krekel

On Jan 23, 2006, at 6:19 PM, holger krekel wrote:

> * Discussion about "Zope" track
>
>   Paul suggests to go for a "Web Frameworks Track" instead
>   of limiting it to Zope.  He thinks that this should
>   help to get more cross-pollination going within the
>   python web framework communities.  There would likely
>   be a quota on Zope talks then.  The ideas were welcomed
>   by the attendees and will likely be followed up
>   on the mailing list and on the upcoming track chair
>   meeting.

To add some more background on this point, Zope would like to be less  
of an island in the Python community.  I think Zope has much to  
offer, especially in Zope 3, where interesting parts can be used in  
isolation.  I also think Zope has lots to gain from Python and other  
Python web frameworks.  There's tons of exciting stuff going on in  
the Python web frameworks space.

Finally, I think Python itself is facing strong competition in Python  
web frameworks.  We (the Python web frameworks) should recognize this  
and work together more to tell a better story.

Having a Zope mini-event inside the EuroPython main event has worked  
well for a number years.  I think times have changed, though, and we  
should all hang out together and listen to what the others have to  
offer.

--Paul
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: #europython minutes 23rd January 2006

Paul Everitt

Oops...

On Jan 23, 2006, at 6:44 PM, Paul Everitt wrote:

>
> On Jan 23, 2006, at 6:19 PM, holger krekel wrote:
>
>> * Discussion about "Zope" track
>>
>>   Paul suggests to go for a "Web Frameworks Track" instead
>>   of limiting it to Zope.  He thinks that this should
>>   help to get more cross-pollination going within the
>>   python web framework communities.  There would likely
>>   be a quota on Zope talks then.  The ideas were welcomed
>>   by the attendees and will likely be followed up
>>   on the mailing list and on the upcoming track chair
>>   meeting.
>
> To add some more background on this point, Zope would like to be less
> of an island in the Python community.  I think Zope has much to
> offer, especially in Zope 3, where interesting parts can be used in
> isolation.  I also think Zope has lots to gain from Python and other
> Python web frameworks.  There's tons of exciting stuff going on in
> the Python web frameworks space.
>
> Finally, I think Python itself is facing strong competition in Python

^^^^ Omit the second "Python".

--Paul

> web frameworks.  We (the Python web frameworks) should recognize this
> and work together more to tell a better story.
>
> Having a Zope mini-event inside the EuroPython main event has worked
> well for a number years.  I think times have changed, though, and we
> should all hang out together and listen to what the others have to
> offer.
>
> --Paul
> _______________________________________________
> EuroPython mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/europython
>

_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: #europython minutes 23rd January 2006

Tarek Ziadé-3
In reply to this post by holger krekel
holger krekel wrote:

>* Renaming EuroPython to Pycon idea
>  Holger mentions the idea of renaming EuroPython to Pycon.
>  The idea is generally welcomed but a number of people think
>  that we should not tackle this for 2006.  Everybody agrees
>  that heading for some more discussions with organisers
>  from non-europe Python conferences e.g. at Pycon 2006
>  makes sense.  The guiding idea is to have a worldwide
>  naming/context umbrella for Python conferences.
>  
>
-1 unless it's named EuroPycon

The worldwide naming/context is already present: Python (or Pycon)
This would be very confusing imo to have two events with the very same name

Tarek

--
Tarek Ziadé | Nuxeo R&D (Paris, France)
CPS Plateform : http://www.cps-project.org
mail: tziade at nuxeo.com | tel: +33 (0) 6 30 37 02 63
You need Zope 3 - http://www.z3lab.org/

_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: #europython minutes 23rd January 2006

holger krekel
On Mon, Jan 23, 2006 at 19:13 +0100, Tarek Ziadé wrote:

> holger krekel wrote:
>
> >* Renaming EuroPython to Pycon idea
> >  Holger mentions the idea of renaming EuroPython to Pycon.
> >  The idea is generally welcomed but a number of people think
> >  that we should not tackle this for 2006.  Everybody agrees
> >  that heading for some more discussions with organisers
> >  from non-europe Python conferences e.g. at Pycon 2006
> >  makes sense.  The guiding idea is to have a worldwide
> >  naming/context umbrella for Python conferences.
> >  
> >
> -1 unless it's named EuroPycon
>
> The worldwide naming/context is already present: Python (or Pycon)
> This would be very confusing imo to have two events with the very same name

We didn't yet motivate the idea much here on the list
and neither at the meeting.  Basically it's an idea that relates to
PR/marketing.  Having Pycon US, Pycon Europe, Pycon Brasil etc.
would show that Python has a world wide connected developer community.
It's certainly not about having the exactly same name.  Btw, people
already expressed at the meeting that they would only consider it
if the US guys would append some regional suffix as well.

Anyway, let's not go wild at the idea for 2006 unless we want
to definitely exclude the consideration at all ... but that
didn't appear so at todays #europython meeting, at least.  
Actually the "Zope" webframework renaming was supposed
to be the thread-spawning discussion :)  

cheers,

    holger
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: #europython minutes 23rd January 2006

Joachim Schmitz
In reply to this post by holger krekel
holger krekel wrote:
> Hi folks,
<snipp>

> somewhat open topics:
>
> * decision/procedures on conference software (favourite seems
>   to be Benedikt's CERN solution for now)

I can offer to port my conference-product, which was used for EPC2002,
to EPC2004 to CPS. The Call-for proposals part can be ready 15.2.2006.

> * followup on payment procedures/accounts (IBAN + Creditcard
>   payment possibilities desired)

Independent which conference system will be used I can offer to
integrate the WorldPay-Creditcard system which was used on all EPC's
into whatever registration system is used, as long it is WEB-based.

> * Website ???
Wouldn't it be best to reuse the WEB-site from last year. Certainly,
there has to be a lokal administrator for it.


--
Mit freundlichen Grüßen                                Joachim Schmitz
......................................................................
AixtraWare eK ..Joachim Schmitz ..www.aixtraware.de ..t: +49-2464-8851
Hüsgenstr. 33a .....d-52457 Aldenhoven .............f: +49-2464-905163
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Python conference software

Aroldo Souza-Leite
Hi list,

a Python software solution for the Europython conference would be cool.
If there is someone (Joachim Schmitz) prepared to configure it using the
experience of the last conferences, it seems to me that this little bit
of Python sectarianism won't keep us from concentrating on the
conference content.
Joachim, if you think I can help more than disturb in any task, please
tell me.

Cheers.

Aroldo.

Joachim Schmitz schrieb:

>holger krekel wrote:
>  
>
>>Hi folks,
>>    
>>
><snipp>
>
>  
>
>>somewhat open topics:
>>
>>* decision/procedures on conference software (favourite seems
>>  to be Benedikt's CERN solution for now)
>>    
>>
>
>I can offer to port my conference-product, which was used for EPC2002,
>to EPC2004 to CPS. The Call-for proposals part can be ready 15.2.2006.
>
>  
>
>>* followup on payment procedures/accounts (IBAN + Creditcard
>>  payment possibilities desired)
>>    
>>
>
>Independent which conference system will be used I can offer to
>integrate the WorldPay-Creditcard system which was used on all EPC's
>into whatever registration system is used, as long it is WEB-based.
>
>  
>
>>* Website ???
>>    
>>
>Wouldn't it be best to reuse the WEB-site from last year. Certainly,
>there has to be a lokal administrator for it.
>
>
>  
>

_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Michael Hudson
Aroldo Souza-Leite <[hidden email]> writes:

> Hi list,
>
> a Python software solution for the Europython conference would be cool.
> If there is someone (Joachim Schmitz) prepared to configure it using the
> experience of the last conferences, it seems to me that this little bit
> of Python sectarianism won't keep us from concentrating on the
> conference content.

FWIW, CERN's indico conference software is written in Python too (and
is open source, gpl I believe).  I also failed in my attempt to
install it, though...

Cheers,
mwh

--
  CLiki pages can be edited by anybody at any time. Imagine the most
  fearsomely comprehensive legal disclaimer you have ever seen, and
  double it                        -- http://ww.telent.net/cliki/index
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Jacob Hallén-2
onsdag 25 januari 2006 10.16 skrev Michael Hudson:

> Aroldo Souza-Leite <[hidden email]> writes:
> > Hi list,
> >
> > a Python software solution for the Europython conference would be cool.
> > If there is someone (Joachim Schmitz) prepared to configure it using the
> > experience of the last conferences, it seems to me that this little bit
> > of Python sectarianism won't keep us from concentrating on the
> > conference content.
>
> FWIW, CERN's indico conference software is written in Python too (and
> is open source, gpl I believe).  I also failed in my attempt to
> install it, though...

When making the choice of registration software, there are some rather
important points to consider.

1. The software has to work on the day we start taking registrations.

This may sound self evident, but we have had problems in the past. Using
something that has been tested saves a lot of grief.

2. The software needs to do a good job in supporting all the actors using the
system. This means that speakers and attendees should have an easy time
registering. The track chairs should be able to view and handle all the talks
in their tracks. The schedulers needs to have support for scheduling. The
registration administrators must have access to many different views and a
powerful search interface. Last year I was able to place a payment by
searching for all attendees from the UK who had ordered a T-shirt and for
whom a payment was not yet registered. There were many other such incidents
where the search interface saved many hours of work.

3. Producing quality outputs is essential. There are 3 major products and some
minor ones needed.

a) Invoices.

You must be able to produce invoices in accordance with legal requirements.
The smallest amount of work for the organisers is generated if attendees can
print their own invoices. Don't expect everyone to manage to print an invoice
at registration. You need an interface so they can come back and make a
separate printout. They need fields for entering an organisation number and
other reference information on the invoice. You must put the attendee
information in a place that is not part of the address fields, or some
organisations will complain. You must have complete payment information on
invoices.

b) Badges.

A lot of work went into making name tags that are actually readable and that
contain useful information. I decided to go for name, organisation, email
address and country (plus attendee category) as useful information to put on
the badge. Email address was made in a smaller and harder to read print,
because I wanted that bit of information to be a bit harder to access. If the
badge holder wants to give it out, he/she can point to the badge.

All the major fields require scaling, as some individuals have very long names
or organisation names, while most people have reasonably short ones.
Adjusting everyone for the longest names means that everyone gets badges that
are impossible to read.

c) Programme

Making a printable programme with all necessary content is not a trivial
exercise. So far we have been relying on the software of Reportlab for this
task. It has the nice feature of allowing each attendee to print a customised
programme.

d) Statistics

You should be able to generate statistics lengthwise and crosswise. How many
staff, track chairs, speakers, students, early birds, on-sites, no-shows,
people from different countries etc.

e) Talk materials

You need places to store these and make them available to attendees and to the
general public.


Moving to a solution that doesn't support these things would be a regression,
as would having a registration procedure that does not build on the lessons
we have learned in previous years of Europython. Getting it right was
actually hard work.

This said, I'll be just as happy not doing registration with the CAPS system,
as it would require a bit of work from me. However, I think that the CAPS
system encapsulates the lessons we have learned in a way that the other
proposals are unlikely to do.

For the website with information about the conference, what we had the last 2
years was hopelessly over-engineered. There is need for some fairly advanced
templating, which allows for the display of banner ads, unified dropdown
menus and such, but the content management behind has really been in the way
of collaborative work on the website. The ideal solution from my horizon
would be a very small directory tree with a simple include mechanism and
files written in either xhtml or Rest. The webserver would handle the
includes, the Rest translations and finally fill in the dynamic content
before serving up a webpage. Doing Plone or CPS for handling a site of about
25 web pages is as impractical as shooting mosquitos with an anti-aircraft
gun.

Jacob Hallén
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Steve Alexander-3

> For the website with information about the conference, what we had the last 2
> years was hopelessly over-engineered. There is need for some fairly advanced
> templating, which allows for the display of banner ads, unified dropdown
> menus and such, but the content management behind has really been in the way
> of collaborative work on the website. The ideal solution from my horizon
> would be a very small directory tree with a simple include mechanism and
> files written in either xhtml or Rest. The webserver would handle the
> includes, the Rest translations and finally fill in the dynamic content
> before serving up a webpage. Doing Plone or CPS for handling a site of about
> 25 web pages is as impractical as shooting mosquitos with an anti-aircraft
> gun.

The Ubuntu linux distribution has recently moved its website from Plone
to a MoinMoin wiki, with some customized moin style files.

I think a MoinMoin wiki meets the basic needs you outlined above.

--
Steve Alexander
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Jean-Marc Orliaguet
In reply to this post by Jacob Hallén-2
Jacob Hallen wrote:

>
>This said, I'll be just as happy not doing registration with the CAPS system,
>as it would require a bit of work from me. However, I think that the CAPS
>system encapsulates the lessons we have learned in a way that the other
>proposals are unlikely to do.
>
>For the website with information about the conference, what we had the last 2
>years was hopelessly over-engineered. There is need for some fairly advanced
>templating, which allows for the display of banner ads, unified dropdown
>menus and such, but the content management behind has really been in the way
>of collaborative work on the website. The ideal solution from my horizon
>would be a very small directory tree with a simple include mechanism and
>files written in either xhtml or Rest. The webserver would handle the
>includes, the Rest translations and finally fill in the dynamic content
>before serving up a webpage. Doing Plone or CPS for handling a site of about
>25 web pages is as impractical as shooting mosquitos with an anti-aircraft
>gun.
>
>Jacob Hallén
>  
>

There are 120 pages on the current europython site (not 25). Doing that
on a wiki with banners, menus, ... is not completely as trivial as you
suggest (see for instance what you'll get with a wiki
http://wiki.python.org/moin/PyCon2006 )

Concerning registration most conferences I've attended handled
registration via email or via fax (cf
http://www.python.org/pycon/2006/register.html) or via simple HTML/CGI
forms. They certainly use some desktop software to organize talks,
attendees, schedules, but I don't see the value of doing this through
the web. It is definitely overkill and cumbersome as it proved out to be
during last year's conference.

/JM
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Jacob Hallén-2
onsdag 25 januari 2006 19.29 skrev Jean-Marc Orliaguet:

> Jacob Hallen wrote:
> >This said, I'll be just as happy not doing registration with the CAPS
> > system, as it would require a bit of work from me. However, I think that
> > the CAPS system encapsulates the lessons we have learned in a way that
> > the other proposals are unlikely to do.
> >
> >For the website with information about the conference, what we had the
> > last 2 years was hopelessly over-engineered. There is need for some
> > fairly advanced templating, which allows for the display of banner ads,
> > unified dropdown menus and such, but the content management behind has
> > really been in the way of collaborative work on the website. The ideal
> > solution from my horizon would be a very small directory tree with a
> > simple include mechanism and files written in either xhtml or Rest. The
> > webserver would handle the includes, the Rest translations and finally
> > fill in the dynamic content before serving up a webpage. Doing Plone or
> > CPS for handling a site of about 25 web pages is as impractical as
> > shooting mosquitos with an anti-aircraft gun.
> >
> >Jacob Hallén
>
> There are 120 pages on the current europython site (not 25). Doing that
> on a wiki with banners, menus, ... is not completely as trivial as you
> suggest (see for instance what you'll get with a wiki
> http://wiki.python.org/moin/PyCon2006 )

I count 25 distinct pages that are viewable by visitors to the site, plus a
few off-site links. I don't know what the other 95 pages do. They seem to be
overhead to me.

I'm not suggesting that building the website is completely trivial.I'm saying
that the solutions we have seen so far have made the job more difficult than
it needs to be. Laura Creighton and I were the main content providers both
for the 2005 and the 2004 conferences. We found that Plone imposed a number
of limitations on the overall look of the website, and that it had a
cumbersome interface for entering content. CPS fixed the limitations of the
overall look, but imposed arbitrary limitations on page design (for instance,
I could not scale pictures as I liked). It also has a workflow model that is
unsuitable for close collaboration on individual pages,as you are supposed to
develop pages in your own sandbox and then publish them. We ended up building
everything in the published space and giving full privileges to everything to
everyone wanting to do any modifications.
 
> Concerning registration most conferences I've attended handled
> registration via email or via fax (cf
> http://www.python.org/pycon/2006/register.html) or via simple HTML/CGI
> forms. They certainly use some desktop software to organize talks,
> attendees, schedules, but I don't see the value of doing this through
> the web. It is definitely overkill and cumbersome as it proved out to be
> during last year's conference.

For these conferences, how did they produce badges? How did they produce
invoices? How much time did they spend on handling administrative matters?
How many problems tracking payments did they have? What sort of organisation
did they have backing the conference (perhaps that organisation already had
an accounting system and a secretary doing a whole lot of typing)? Did they
actually take into account the individual preferences of the attendees, or
did they just create a schedule on speculation? Were the organisers, each
with his own needs for information, spread over a whole continent? How did
they distribute proceedings? How much did their overheads cost?

What did you consider to be cumbersome with the handling of talks and
scheduling during last years conference?

Jacob Hallén
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Jean-Marc Orliaguet
Jacob Hallen wrote:

>onsdag 25 januari 2006 19.29 skrev Jean-Marc Orliaguet:
>  
>
>>Jacob Hallen wrote:
>>    
>>
>>>This said, I'll be just as happy not doing registration with the CAPS
>>>system, as it would require a bit of work from me. However, I think that
>>>the CAPS system encapsulates the lessons we have learned in a way that
>>>the other proposals are unlikely to do.
>>>
>>>For the website with information about the conference, what we had the
>>>last 2 years was hopelessly over-engineered. There is need for some
>>>fairly advanced templating, which allows for the display of banner ads,
>>>unified dropdown menus and such, but the content management behind has
>>>really been in the way of collaborative work on the website. The ideal
>>>solution from my horizon would be a very small directory tree with a
>>>simple include mechanism and files written in either xhtml or Rest. The
>>>webserver would handle the includes, the Rest translations and finally
>>>fill in the dynamic content before serving up a webpage. Doing Plone or
>>>CPS for handling a site of about 25 web pages is as impractical as
>>>shooting mosquitos with an anti-aircraft gun.
>>>
>>>Jacob Hallén
>>>      
>>>
>>There are 120 pages on the current europython site (not 25). Doing that
>>on a wiki with banners, menus, ... is not completely as trivial as you
>>suggest (see for instance what you'll get with a wiki
>>http://wiki.python.org/moin/PyCon2006 )
>>    
>>
>
>I count 25 distinct pages that are viewable by visitors to the site, plus a
>few off-site links. I don't know what the other 95 pages do. They seem to be
>overhead to me.
>
>I'm not suggesting that building the website is completely trivial.I'm saying
>that the solutions we have seen so far have made the job more difficult than
>it needs to be. Laura Creighton and I were the main content providers both
>for the 2005 and the 2004 conferences. We found that Plone imposed a number
>of limitations on the overall look of the website, and that it had a
>cumbersome interface for entering content. CPS fixed the limitations of the
>overall look, but imposed arbitrary limitations on page design (for instance,
>I could not scale pictures as I liked). It also has a workflow model that is
>unsuitable for close collaboration on individual pages,as you are supposed to
>develop pages in your own sandbox and then publish them. We ended up building
>everything in the published space and giving full privileges to everything to
>everyone wanting to do any modifications.
>
>  
>

Images are scaled down to a certain limit to avoid breaking the page's
design, the size might have been increased at will.

Concerning the workflow, you misunderstood how it works hence you draw
hasty conclusions. You are not supposed to create documents "in your own
sandbox". Documents are created inside common workspaces. Contributors
who have access to the workspaces can share documents as on a wiki,
before publishing them.


>>Concerning registration most conferences I've attended handled
>>registration via email or via fax (cf
>>http://www.python.org/pycon/2006/register.html) or via simple HTML/CGI
>>forms. They certainly use some desktop software to organize talks,
>>attendees, schedules, but I don't see the value of doing this through
>>the web. It is definitely overkill and cumbersome as it proved out to be
>>during last year's conference.
>>    
>>
>
>For these conferences, how did they produce badges? How did they produce
>invoices? How much time did they spend on handling administrative matters?
>How many problems tracking payments did they have? What sort of organisation
>did they have backing the conference (perhaps that organisation already had
>an accounting system and a secretary doing a whole lot of typing)? Did they
>actually take into account the individual preferences of the attendees, or
>did they just create a schedule on speculation? Were the organisers, each
>with his own needs for information, spread over a whole continent? How did
>they distribute proceedings? How much did their overheads cost?
>
>What did you consider to be cumbersome with the handling of talks and
>scheduling during last years conference?
>
>Jacob Hallén
>  
>

I don't know how others do, they certainly use excel, MS word.

I got the impression that it was an alpha version which was running last
year, considering all the manual fixes that were done once the
registration had opened. The security was very low since anyone could
edit other's presentations.

I'm simply saying that all the manual work that you did to get the
system running might as well been spent on some desktop application
instead. You may have spent more time building and fixing the system
than the time that would have been needed to do the administrative work.

/JM
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Dario Lopez-Kästen
In reply to this post by Jacob Hallén-2

uh, this discussion, IMNSHO, is rapidly becoming non-interesting. And I
am a bit upset at seeing the same discussion popup again and again.

So, can we please just decide on what software to use? I am not
interested in, at least as I perceive it, this covert blame-game that is
currently going on.

What happened, happende, let's not let it happen again. The problems we
had we had were had for specific reasons - most of them had nothing to
do with the technology.

Bottom line: is the software ready or not?

We need NOT to integrate the website with INFORMATION on the conference
with any other conference reg.system, automated or manual. I've managed
larger conferences that EPC without any automated systems. ust a website
with info (edicted with a texteditor).

So, how much time do folks that have interests in EPC using their
software need to set up working environments so that the rest of us can
evaluate?

Perhaps there are more people than just Strakt and CERN interested in
having their software evaluated?

We need to have a decision on this soon. And please - let's keep the
requirements at a sensible and practical level.

Is 10 days enough time for the interested parties to set their systems up?

/dario

--
-- -------------------------------------------------------------------
Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.
Lyrics applied to programming & application design:
"emancipate yourself from mental slavery" - redemption song, b. marley
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Laura Creighton
In a message of Thu, 26 Jan 2006 15:56:51 +0100, Dario Lopez-Kästen writes:
>
>uh, this discussion, IMNSHO, is rapidly becoming non-interesting. And I
>am a bit upset at seeing the same discussion popup again and again.
>
>So, can we please just decide on what software to use? I am not
>interested in, at least as I perceive it, this covert blame-game that is
>currently going on.

This is not blame.  This is a complete and unreconciable difference of
opinion as to what is desirable in the way to do work.  There is an
important difference.  There is a reason why Python has dozens and
dozens of webframeworks and workflow systems.  People who start off
using any one often end up really unhappy because the design of the
system does not match the way that they want to structure the work.
And when they get really unhappy, they go off and write their own
system.

>What happened, happende, let's not let it happen again. The problems we
>had we had were had for specific reasons - most of them had nothing to
>do with the technology.

They had everything to do with the technology, and whether the
technology made it possible for them to do what it was they wanted to
do in the way that they wanted to do it, or whether some things
'just couldn't be done' or 'were easier to do manually' and so on
and so forth.  These are the very working conditions that make people
decide that one technology does not suit their needs and go get, or
write another one.

But given our diverse community, it is not surprising that we cannot
find a fit which suits everybody.  Consider CherryPy, to pick
something that we aren't using, and as far as I know are not
considering using, so should not unduly stress people out.  I have
heard both of these comments about CherryPy's likeness to PHP.  It is
'a major strength that allows people to work in ways they prefer and
enjoy', or 'an abomination, like the PHP it resembles, that makes it
working with it an intolerable experience'.  There is no hope in
getting these two reviewers to meet in some happy middle.  You might,
if you worked hard at it, create a work experience that both of them
dislike, but pleasing them both is impossible.

There is a reason why we have so many webframeworks, and that does
not reflect badly on us.  People really, really, really do care about
how they work, and really prefer to do things in ways that other people
hate.  Indeed, the same feature _often_ works that way.  

>Bottom line: is the software ready or not?
>
>We need NOT to integrate the website with INFORMATION on the conference
>with any other conference reg.system, automated or manual. I've managed
>larger conferences that EPC without any automated systems. ust a website
>with info (edicted with a texteditor).

What is relevant is whether the people who plan to manage EP2006 want
integration, most definitely do not want integration, or do not care.

>So, how much time do folks that have interests in EPC using their
>software need to set up working environments so that the rest of us can
>evaluate?

I think that, should there be any evaluation to be done, only the
people who have already planned to do a lot of work in organising the
conference should do it.  Otherwise we risk getting a system based on
the needs and desires of irrelevant people.

So if CERN is full of people who are already familiar with the
CERN system and prefer to use it because it is what they know and are
familiar with, then that would be reason enough for me to conclude
they should use it.  My problem is that so far I haven't heard from
any knowledgable CERN system people.  The people who were pushing
it, were doing so, despite being unfamiliar with it.  This is
Proof by 'it must work, lots of people have used it'.

But if there is one thing we have figured out, in enormous detail, is
that 'working for lots of people' does not imply 'working for you' or
even 'having what you would consider the most elementary and
necessary features implemented'.  People implement features in
accordance to what they consider 'essential' and the variation
among different tools is large.

>Perhaps there are more people than just Strakt and CERN interested in
>having their software evaluated?
>
>We need to have a decision on this soon. And please - let's keep the
>requirements at a sensible and practical level.

This is the problem.  What one person considers 'an unreasonable
requirement' somebody else considers 'an essential requirement'.

>
>Is 10 days enough time for the interested parties to set their systems up
>?
>
>/dario

What I would like to see is a discussion, or a report, or something
from the CERN Europython organising team as to what it is that they
want, in freatures, usability, whatever-.  Now it may be that they are
feeling inhibited in discussing it, because they would in general
discuss this in French.  I'd say, discuss or post it in French.  I'd
just like to make sure that you know what you want, ahead of time,
and, should you prefer to use one system or another, that you have
some reason for using it beyond 'it was developed here and we feel we
have to use it' or 'why not?', or 'somebody told me it was cool'.

Because I have already gone through the 'we should use some system
because somebody else likes it' route.  And the 'I never thought about
it much, but surely any system would work in some reasonable way, they
way I consider reasonable ... it ought to have the appropriate
capabilities, even though I have never used it, just because' route.
This is an invitation to an unbelievable amount of stress.  You can
make yourself sick over this.  I want to spare you all this agony.

I really and truly believe that the conference organisers should use a
system they like and enjoy using. If you don't have a candidate,
possibly because you have never used a system and you want to go try
the Strakt system, to see if you like it, then we can set something
up.  If you already have some other system you know and love, this is
fine with me too.

The other thing this report would be useful for is to locate: 'who
besides Benedikt is organising this thing'?  Even with track chairs,
Europython is way to much work for one person to handle the 'onsite
preparation details'.  If Benedikt needs help, then we need to hear
about this as soon as possible.

take care all,
Laura



_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Jean-Marc Orliaguet
Laura Creighton wrote:

> .....
>
>
>But given our diverse community, it is not surprising that we cannot
>find a fit which suits everybody.  Consider CherryPy, to pick
>something that we aren't using, and as far as I know are not
>considering using, so should not unduly stress people out.  I have
>heard both of these comments about CherryPy's likeness to PHP.  It is
>'a major strength that allows people to work in ways they prefer and
>enjoy', or 'an abomination, like the PHP it resembles, that makes it
>working with it an intolerable experience'.  There is no hope in
>getting these two reviewers to meet in some happy middle.  You might,
>if you worked hard at it, create a work experience that both of them
>dislike, but pleasing them both is impossible.
>
>There is a reason why we have so many webframeworks, and that does
>not reflect badly on us.  People really, really, really do care about
>how they work, and really prefer to do things in ways that other people
>hate.  Indeed, the same feature _often_ works that way.  
>  
>


But finding a framework that pleases everyone has never been the goal.
The important point has been to get a site up and running that
*visitors* are pleased with. That Plone's or CPS' workflow model do not
fit your frame of mind is of very little interest.

we had a student who came one afternoon and created the "getting around
göteborg" pages
(http://www.europython.org/sections/location/getting_around_the_g/bp_to_ep)
and it took 5 minutes before he could start using the software.

Which is why I still don't understand what you are bitching about
concerning the site .. If you can't learn different ways of working with
software than the ones you are used with, then I would say that it is a
problem of yours in the first place.

/JM

 
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Christian Scholz
Hi!

Just a note from sort of an outsider..

I don't know what actually went wrong with the systems used before
(though I would be interested in what sort of things these systems could
not provide. But this only via PM to not bloat this thread).
But IMHO things should calm down here again. I think most of the systems
can be tailored in a way that a) the editors can work with them and b)
the visitors can use. The latter should be even more subject to some
designer/visual communicator than to a programmer. The programmer should
just make it fit. Speaking of the first thing in an ideal situation
there should be some analysis before in what they need and so on.

As it seems that Benedikt (and who else?) proposed their system as they
are used to it I don't see any problem in why not just using it.
Information about the conference in general never seemed that much and
can in the worst case simply be done in simple HTML. But again here
should these people decide who actually do the editing. As stated above
I think that the appearance to the visitor should be tweakable with
nearly every system. And somehow combining different system should also
be no problem (e.g. using some Apache rewrite rules, iframes or whatever).

So it might be of interest

a) who will actually be providing the information
b) what system do they prefer to use and (if no system is preferred)
c) what are the requirements

maybe also

d) what system parts must be there? (information, registering, talk
database etc.)

Don't know if that mail helps but I was just wondering that choosing the
system for the website is the main problem ;-)

-- christian

--
Christian Scholz/COM.lounge
[hidden email]
http://mrtopf.tv
http://comlounge.net
http://dev.comlounge.net

_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Laura Creighton
In reply to this post by Jean-Marc Orliaguet
In a message of Thu, 26 Jan 2006 21:30:37 +0100, Jean-Marc Orliaguet writes:

>Laura Creighton wrote:
>
>> .....
>>
>>
>>But given our diverse community, it is not surprising that we cannot
>>find a fit which suits everybody.  Consider CherryPy, to pick
>>something that we aren't using, and as far as I know are not
>>considering using, so should not unduly stress people out.  I have
>>heard both of these comments about CherryPy's likeness to PHP.  It is
>>'a major strength that allows people to work in ways they prefer and
>>enjoy', or 'an abomination, like the PHP it resembles, that makes it
>>working with it an intolerable experience'.  There is no hope in
>>getting these two reviewers to meet in some happy middle.  You might,
>>if you worked hard at it, create a work experience that both of them
>>dislike, but pleasing them both is impossible.
>>
>>There is a reason why we have so many webframeworks, and that does
>>not reflect badly on us.  People really, really, really do care about
>>how they work, and really prefer to do things in ways that other people
>>hate.  Indeed, the same feature _often_ works that way.  
>>  
>>
>
>
>But finding a framework that pleases everyone has never been the goal.
>The important point has been to get a site up and running that
>*visitors* are pleased with. That Plone's or CPS' workflow model do not
>fit your frame of mind is of very little interest.

You see, this is a fundamental point of disagreement.  In my frame of
reference, the tools that matter most are the tools that are used by
the conference organisers to organise the conference.  Then come the
tools that help people produce content.  Then come usability issues
for the webvisitors, including, but not restricted to the tools that
make the website searchable.  If all of these work well, the visitors
will get an experience which they enjoy, without being aware of where
the work has gone into making the experience enjoyable.

On the other hand, if the way of working is too hard, or too unpleasant,
then the people who were signed up to do it will go away or do less or
be busy with other problems in the workflow to get involved with more
complicated things.  The visitors will be unhappy, but in a way that
'putting the website first' will not address.

>we had a student who came one afternoon and created the "getting around
>göteborg" pages
>(http://www.europython.org/sections/location/getting_around_the_g/bp_to_e
>p)
>and it took 5 minutes before he could start using the software.

yes. This is one of my great failures.  There were supposed to be
six of them.  But 1 dropped out for unknown reasons, and the
other 4 all cited 'I don't want to use this software' as a
reason why they just mailed me what they could, and left things in
my lap.

This happened a lot.  People who were supposed to find things
'easier to use than pure Zope' found them 'restrictive enough
that I would prefer not to'.  Europython potential volunteers
apparantly contain a set of people who like to take things
exactly as they are handed to them, and those who find that
computing is all about 'the customising of life to suit'.

>Which is why I still don't understand what you are bitching about
>concerning the site .. If you can't learn different ways of working with
>software than the ones you are used with, then I would say that it is a
>problem of yours in the first place.
>
>/JM

yes, I understand this.  But the problem isn't that I 'cannot learn
different ways' as might be witnessed by all the work I have done no
matter what system.  My problem is not that I cannot do it, but that
I cannot get the functionality I want out of it to make the
experience pleasant.  Or efficient.  

I am also a LISP programmer bigot.  I completely reject the
notion of separating 'code' from 'data'.  I am also an emacs rather
than vi person.  I hate the notion of modes altogether, which I
believe is related to my notion that the separation of code from
data is evil, but am not certain.

That I expect more from a system than what I get,
and I expect different from a system from what I get, does not
imply 'oh she could get it if only she knew it better' but
instead that the whole goals of the system are different than
the ones I have in my mind when I wanted one.

My experience in using Plone exactly matches the person who was
unhappy she they bought an automobile when she really wanted a
motorboat believing what she was told that 'after all they are both
transportation'.  It doesn't mean that Plone makes a bad automobile.
It does mean that the conversion of an automobile into 'something that
floats' will not be easy.

What I want to ensure is that the next organising body, should it
want a thing that floats, gets one that does so.  Or whatever the
heck it is that it wants.  What I want to destroy is the idea that
'pretty much any system will be ok, because they do not matter
a lot'.

Laura
_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
Reply | Threaded
Open this post in threaded view
|

Re: Python conference software

Jean-Marc Orliaguet
Laura Creighton wrote:

>In a message of Thu, 26 Jan 2006 21:30:37 +0100, Jean-Marc Orliaguet writes:
>  
>
>>
>>But finding a framework that pleases everyone has never been the goal.
>>The important point has been to get a site up and running that
>>*visitors* are pleased with. That Plone's or CPS' workflow model do not
>>fit your frame of mind is of very little interest.
>>    
>>
>
>You see, this is a fundamental point of disagreement.  In my frame of
>reference, the tools that matter most are the tools that are used by
>the conference organisers to organise the conference.  Then come the
>tools that help people produce content.  Then come usability issues
>for the webvisitors, including, but not restricted to the tools that
>make the website searchable.  If all of these work well, the visitors
>will get an experience which they enjoy, without being aware of where
>the work has gone into making the experience enjoyable.
>
>On the other hand, if the way of working is too hard, or too unpleasant,
>then the people who were signed up to do it will go away or do less or
>be busy with other problems in the workflow to get involved with more
>complicated things.  The visitors will be unhappy, but in a way that
>'putting the website first' will not address.
>
>  
>

This does not seem very professional from those who are saying that they
want to contribute in the first place. If you sign up to do a job, you
can't just blame it on the software as an excuse for not doing what you
said you would be willing to do.
 
Providing software is not the same thing as getting commitment from
contributors.
 

>>we had a student who came one afternoon and created the "getting around
>>göteborg" pages
>>(http://www.europython.org/sections/location/getting_around_the_g/bp_to_e
>>p)
>>and it took 5 minutes before he could start using the software.
>>    
>>
>
>yes. This is one of my great failures.  There were supposed to be
>six of them.  But 1 dropped out for unknown reasons, and the
>other 4 all cited 'I don't want to use this software' as a
>reason why they just mailed me what they could, and left things in
>my lap.
>
>  
>

This is the problem with volunteering, and open-source projects in
general: you are free to quit when things are no longer fun.

You should be made it clear that the job was not about evaluating
software but about using it.

>This happened a lot.  People who were supposed to find things
>'easier to use than pure Zope' found them 'restrictive enough
>that I would prefer not to'.  Europython potential volunteers
>apparantly contain a set of people who like to take things
>exactly as they are handed to them, and those who find that
>computing is all about 'the customising of life to suit'.
>
>  
>

The solution is about setting rules. If some people consider that
organizing a conference is mainly about trying different frameworks
maybe they should consider doing something else as a hobby?

>>Which is why I still don't understand what you are bitching about
>>concerning the site .. If you can't learn different ways of working with
>>software than the ones you are used with, then I would say that it is a
>>problem of yours in the first place.
>>
>>/JM
>>    
>>
>
>yes, I understand this.  But the problem isn't that I 'cannot learn
>different ways' as might be witnessed by all the work I have done no
>matter what system.  My problem is not that I cannot do it, but that
>I cannot get the functionality I want out of it to make the
>experience pleasant.  Or efficient.  
>
>I am also a LISP programmer bigot.  I completely reject the
>notion of separating 'code' from 'data'.  I am also an emacs rather
>than vi person.  I hate the notion of modes altogether, which I
>believe is related to my notion that the separation of code from
>data is evil, but am not certain.
>
>That I expect more from a system than what I get,
>and I expect different from a system from what I get, does not
>imply 'oh she could get it if only she knew it better' but
>instead that the whole goals of the system are different than
>the ones I have in my mind when I wanted one.
>
>My experience in using Plone exactly matches the person who was
>unhappy she they bought an automobile when she really wanted a
>motorboat believing what she was told that 'after all they are both
>transportation'.  It doesn't mean that Plone makes a bad automobile.
>It does mean that the conversion of an automobile into 'something that
>floats' will not be easy.
>
>What I want to ensure is that the next organising body, should it
>want a thing that floats, gets one that does so.  Or whatever the
>heck it is that it wants.  What I want to destroy is the idea that
>'pretty much any system will be ok, because they do not matter
>a lot'.
>
>Laura
>  
>

I agree, but if you are supposed to use a piece of paper and a pen to
write an essay, are you going to complain about how bad the tools were
for writing and how much better a typewriter would have been as an
excuse for not having written the essay?

/JM

_______________________________________________
EuroPython mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/europython
12