Hello Jacob :-)

I'm currently part of the web team for the EP2014 and have attended EuroPython conferences for the last 4 years. I also helped on the web team for the last couple of PyCon.DE conferences.

Thank you for these details from the EPS' point of view. They are much appreciated :-) There have definitely been some friction points over the last couple of months but it seems to me like everything has become much more calm and quiet over the last month (at least from what I can gather by not noticing all that my burner roofs anymore ;-)).

I just wanted to contribute a little bit to the whole "software" topic since some of the statements issues here might be interpreted in a wrong way:

The point about the software being used for EP2014 indicates that this software is completely new, which isn't true. It has been used and updated over the last couple of years for the PyCon.DE conference series. It definitely needed and still needs a lot of work to use it for a EuroPython conference, but I'm certain that this would be the case for any software in preparation for a new conference year. We had some issues with previous year's software which were discussed in other mail exchanges between the EPS and the local organizer group, so I don't really want to reiterate them here.

That being said, I totally agree that there should be a software component to the conference package as handed out by the EPS and it would help if you could reuse that explicit knowledge from previous years. The problem with the current approach (speaking totally for myself here and not as part of an organization or group) is, though, that such a software should not be written as part of the preparation for a specific event. The timeframe there is usually far to tight to create anything that might be usable for anything but the local team. We saw some of this in the previous year's software as we see it in this year's. Me having worked on this software for the last 2 years definitely helps here when it comes to adapting it to the EP format which probably was one of the reasons why we eventually decided to go with the PyCon.DE software.

That being a "flatout" refusal is slightly exaggerated. We thought quite long and hard about it and most of use at least skimmed over the code to see how easy it would be to adapt to what we had in mind. But as said before, this has already been discussed in a more appropriate forum.

So my proposal would be to create some kind ... let's call it a "task force" (that sounds exciting ;-)) with volunteers from as many previous EP conferences to come up with a set of requirements and ideally also a base-implementation that can then really be used by local organizers :-)

From my perspective (and speaking only for myself here) the requirement to use the previous software at this point is unrealistic if there are alternatives the local group has more local knowledge with.

If you've read all the way down to this point: Thank you very much :-)

-- Horst





On 31 Jan 2014, at 19:34, Jacob Hallén wrote:

I am writing this from the sidelines, since I am not actively participating in the EPS board work, though I am formally treasurer for the EPS. This has given me access to what is going on, but I don't have a deep emotional involvement in the ongoing discussions and negotiations. I'm still writing tis in "we"
form, since I feel a responsibility for the future of EuroPython.

I have been involved in the setup of all new locations for EuroPython and this is the first time we have run into real difficulties in the collaboration with
the local organization.

In the Call for Participation that was the basis for the selection of a new site for Europython, there was a requirement for the cost of attendance. It turns out that the promised figures from the Berlin team can't be met and that
cost of attendance will take a serious jump, compared to Florence.

This is a serious problem for the EPS, because our explicit goal is to arrange a really affordable conference. We are now looking at conference fees that are 5 times higher than the ones for Göteborg and it is starting to hurt. Worries about getting enough participants and getting a reasonable mix of people has gotten the EPS board more involved in pricing issues than they would like to be. This is not only a concern for the conference this year, but for future conferences. A large number of the attendees have come to EuroPython for many years. If they are scared off by the price this year, they are less likely to
come back in the future.

This may be the first EuroPython where I won't be able to afford going.

There was another requirement in the CfP, for the local organization to use the conference system that was used and developed by the people in Florence. As Paul Boddie correctly guessed, this is a way for the EPS to enable future local organizers to work with exiting tools, instead of having to invent their own. What happens when people invent their own is that we lose functionality and make conference participants fight buggy software. We actually had a working conference system with voting on talks, accommodation booking and all
sorts of features in 2005, but it was abandoned by the people at CERN.

It came as a surprise and chock to the EPS when the Berlin team flat out refused to use the system that has been developed by the Italians. They argue that the system is not of production quality. I can't really say much about that, since I haven't seen the code, but there were resources available from the Italians to improve the system and to help with setting it up for the
Berlin conference.

The EPS has ended up accepting that the Berlin organizers build their own system, but having a system that a new conference organizer can just start
using is still a strategic goal.

The final issue is that the Berlin team designed a new conference logo. At the same time they decided that they wanted to market the conference as EP14.
This is not acceptable to the EPS. We feel that it is important that
EuroPython is called EuroPython. We have accepted the logo under the condition that EuroPython is spelled out underneath it, wherever it is used. We have also required that URLs, Email addresses and other communication channels use the EUroPython name and not ep14. This has met severe and (in my opinion) pig-
headed resistance from some of the local organizers.

Having worked with past organizers, I know that every one of them would have
quickly and fully complied with our request.

---

The first two points I have mentioned have been resolved with the local organization, but the outcome is not what the EPS would like it to be. The third issue seems to be mostly sorted out, though there may still be some
holdover left.

This means that there is a working collaboration between the EPS and the local
organizers, though there are still points of friction. I hope the
collaboration climate can be improved and I am sure that the local organizers
are working on it. The EPS board certainly is.

I think much of the controversy could have been avoided if we had had direct
communications with more people on the ground in Berlin before the
preparations for the conference started.

The announcement of a CfP for 2015 should be seen in this light. There are a couple of important goals for the EPS that can be better fulfilled by putting out a CfP, based on the things we have learned from the previous process. The
winning bid may still come from Berlin, but this time with a clearer
understanding of expectations.

Now, the EuroPython Society is an open membership organization. If you think the board is mishandling or misjudging the situation, you are free to join and
change the way the society operates.

Jacob Hallén

_______________________________________________
EuroPython 2014  Berlin, 21th27th July
EuroPython mailing list
EuroPython@python.org
https://mail.python.org/mailman/listinfo/europython
_______________________________________________
EuroPython 2014  Berlin, 21th27th July
EuroPython mailing list
EuroPython@python.org
https://mail.python.org/mailman/listinfo/europython

Reply via email to