PyCon UK 2016 Internaldocs

DATES: 15th-19th September 2016

Dates

  • 2015
  • 2016
    • April 26th - Launch conference, open CFP, start selling tickets, open financial aid applications
    • June 28th - Close CFP, close first tranche of financial aid applications
    • July 26th - Announce programme
    • August 9th - Announce schedule
    • August 13th - Committee meetup in Cardiff
    • September 15th-19th - Conference!

Calendar

Venue

The conference will be held at Cardiff University (on the Thursday) and Cardiff City Hall (from Friday to Monday).

Cardiff University

We have access to the following rooms:

Cardiff City Hall

We have access to the following rooms:

  • Assembly Room
  • Marble Hall
  • Lower Hall
  • Ferrier Hall
  • Syndicate Rooms A, B, C, D, G, H

See here for more about the capacities of each room.

We have provisionally allocated Syndicate Rooms C and D for the teachers’ day on Friday, and the childrens’ day on Saturday.

Tickets

We are selling tickets at two prices: £96 for people who are paying for their own tickets (individual tickets), and £144 for people whose company is paying (company tickets). Additionally, we are selling one-day tickets at £36. These prices include VAT.

We will ask the following questions on the registration form:

  • Name
  • Employer (but only for company-supported tickets)
  • Email address
  • Phone number
  • Accessibility requirements
  • Childcare requirements
  • Dietary requirements

For assessing diversity (is there a better way to phrase that?) we should ask about the following, but make responses optional:

  • Gender
  • Ethnicity
  • Country of residence
  • Age

Tito

We’re selling tickets through Tito.

The tickets page is here.

Refunding tickets

We will offer a full refund on tickets until 1st September, and a 50% refund thereafter.

To refund a ticket from the Tito admin interface:

  • Click “Orders”, search for the ticket-holder’s name
  • Click “Cancel this order”
  • Click “Yes” when asked if you’re sure
  • Click “Refund via Stripe”

Upgrading tickets

We allow people to upgrade their tickets through their purchase of a Ticket Upgrade ticket.

To process a Ticket Upgrade via the Tito admin interface, you find the original ticket, update its type, and then void the Ticket Upgrade. In detail:

  • Click “Attendees”
  • Find the relevant Ticket Upgrade ticket * Tickets can be filtered by type if required * This should have the number of the original ticket that needs to be upgraded
  • Find the original ticket via its ticket number
  • Click “Edit attendee details”
  • Change the ticket type appropriately
  • Add “upgraded” as a tag
  • Save the ticket
  • Find the Ticket Upgrade ticket again
  • Click “Void ticket”, then “Confirm void”, then “No” (in answer to the question about refunds)

Schedule

We’ve committed to the following things, which need to find their way onto the schedule:

  • Django Girls workshop (all day Thursday)
  • Teachers’ day (all day Friday)
  • Children’s day (all day Saturday)
  • A welcome session for first-time attendees (Friday morning)
  • The PyCon UK Society’s AGM
  • Code4Research track (Sat, Sun and sprints on Monday)

Sponsorship

Sponsorship levels

We’re offering sponsorship at the following levels:

  • Gold, £9,995, includes ten tickets and a fifteen-minute sponsored keynote slot
  • Silver, £4,995, includes five tickets and a five-minute sponsored lightning talk slot
  • Bronze, £1,995, includes two tickets

All sponsors will be eligible to have a booth in the Marble Hall from Friday to Monday and take part in the jobs fair.

We will promote all sponsors on social media and in the conference newsletter, and will place sponsor logos on our website and on signs around the conference venue. We will also make space in the conference booklet for advertisements from sponsors.

Process for contacting potential sponsors

All conference organisers are encouraged to contact potential sponsors!

There is a spreadsheet for tracking the progress with contacting sponsors in the conference Google Drive shared folder. Please let Peter or George know if you don’t have access to this.

If you see a company in the spreadsheet where you know somebody who works there (particularly if the status is “no response” or “stale”) please let the person in the handler field know.

Feel free to claim any companies where the handler field is blank by filling out this field.

If you are listed as the handler for a company, please keep the the spreadsheet up to date!

The spreadsheet has the following columns:

Sponsor
The name of the company.
Handler
The name of the person in contact with the company.
Contact
The name of our contact(s) at the company.
Email
Email address for our contact.
Address
Address of the company (for invoicing purposes).
Level
The level of sponsorship (one of gold/silver/bronze). This can be filled in before sponsorship is agreed.
Amount
The amount of sponsorship agreed – this will usually correspond to the amounts under Sponsorship levels. This should be only be filled in once sponsorship is agreed.
Extra
Anything about the sponsorship that we’ll need to bear in mind when putting on the conference, such as “the sponsors are only coming to the jobs fair”, or “the sponsors have requested that we promote their latest campaign”.
Last contact
Date of last contact with company.
Status
See below.
Notes
Any notes about ongoing discussion – use this as you see fit.

The status field may be one of the following:

TODO
The company has not yet been contacted.
Contacted
The company has been contacted, and discussions are ongoing.
No response
The company has been contacted, and no meaningful response has been received.
Stale
The company has been contacted, but discussions have petered out.
Declined
The company has been contacted, and has declined to sponsor the conference.
Invoice required
The company has agreed to sponsor the conference, and an invoice is required.
Invoiced
The company has agreed to sponsor the conference, and an invoice has been sent.
Paid
The company have paid to sponsor the conference.
Do not contact
The company should not be contacted.

Invoicing

Once sponsorship has been agreed with a company, please contact Kristian, who will arrange for an invoice to be sent to the company.

2015 in numbers

Tickets sold

Here is a breakdown of the number of tickets sold for main conference:

Regular 112 £165
Full Price 106 £215
Community 49 £135
Speaker 18 £135
Student/Unwaged 13 £90
Complementary 9 £0
Sponsor 23 £0
Journalist 2 £0
Total 332  

Regular tickets were available until 1/7/15, after which Full Price tickets were available.

Community tickets were supposed to be for those who spoke or who volunteered their time during or before the conference, and were limited in number. Additional Speaker tickets were released after these had been sold. The process for this was pretty unclear, and several speakers ended up paying higher rates without knowing that a lower rate was available.

Student/Unwaged tickets were given to those who applied for them. I’m not quite sure how this was handled.

Several sponsors were eligible for free tickets.

Additionally, here are the other tickets:

Young Person 100 £5
Teacher 42 £50
Scientist 24 £99
DjangoGirls / Transcode 24 £99
Sprint Only 1 £31.42
_images/ticket_sales_2015.png

This data came from ti.to.

Sponsorship

Here’s a breakdown of the sponsorship received:

  • 1 × £10,000
  • 4 × £5,000
  • 2 × £2,500
  • 8 × £1,000
  • 1 × £500

Report of wash-up meeting in Cardiff

14th November 2015

Fifteen of us braved howling wind and driving rain (Daniele and Vince have promised better weather next September) to meet up in Cardiff last Saturday, to look around City Hall, to discuss how the last conference went, and to begin to talk about the kind of conference we’d like to see next year. It was deliberately not a planning meeting.

We were firstly given a tour of the available rooms at Cardiff’s City Hall. We were shown around by Gale, a member of the events team at City Hall. She seemed very competent and accommodating, and not in the least bit fazed by the prospect of hosting several hundred Python people.

You can get a good feel for the aesthetic of the venue (Wikipedia calls it “Edwardian Baroque”) from the virtual tour on the City Hall website. There are several rooms we could use, with the largest being the Assembly Room (which seats up to 600), with several rooms of other sizes. Catering could be done on site in the Lower Hall. It is likely that we’d need to provide our own PA system.

We then had a sandwich lunch at the maths faculty, and spent a couple of hours talking about last year and about possibilities for next year.

Mary began by giving a statement of last year’s accounts. In short, we’re in a very healthy financial position. Full accounts will be circulated once everything has been settled up.

Kristian then gave a short presentation about user stories. A user story is a way of capturing what a user needs in order to achieve a goal, and takes the general form “As $role I want $desire so that $benefit”. There are several technical examples on Wikipedia, and Kristian has written more about this on his blog.

The reason I wanted us to talk about user stories is that I’m not aware of us ever really having discussed the questions “what is PyCon UK for?” and “what do the people who come to PyCon UK (our users) want out of the conference?”. Writing user stories is one way to help us answer these questions, and I hope, over the coming months, to collect and curate a set of user stories from members of the community, relating to their expectations and requirements of the conference.

We then split into groups of three, and spent time reading through the feedback gathered from users after the last conference, and trying to turn some of the feedback into user stories. It was not possible to produce user stories directly from a lot of feedback, but I found that often a piece of feedback prompted us to think more generally about a what somebody needs or wants out of a conference.

Luis is collecting the user stories that we produced, and I hope we can use these to seed a user story database before we start inviting contributions from members of the community.

Daniele then talked about Cardiff as a city for hosting a conference, drawing on his experience of running the Django Weekend in 2014 and DjangoCon EU in 2015. He talked about the kinds of social events that they had hosted (including some evening meals at the Clink and the conference dinner at the National Museum) and about the kinds of things they had done to look after the wellbeing of delegates, including bringing in some counsellors from the University for free consultation sessions.

Daniele talked about how DjangoCon EU aimed to be as inclusive as possible, by doing things such as providing a creche and providing some financial support. He also talked about choosing a programme so that there was always at least one woman speaking during each of the four sessions during the day. (To do this meant rejecting talks from some established and well-known speakers, but as a delegate I thought the average standard of the talks at the conference was higher than almost any other conference I’ve been to.)

He also shared an overview of the DjangoCon EU budget, which makes me confident that we can put on an affordable conference in Cardiff next year.

Zeth then talked about plans for an unconference in Birmingham early next year, as well as his plans to put in a bid to host EuroPython in Birmingham in 2017. It sounds like plans for both of these are at an early stage, and I’ll let him update us as these develop.

We then talked about establishing the PyCon UK Society as a legal entity. Zeth has talked in the past with Van (chair of the PSF) about options for becoming the UK branch of the PSF, but we felt that getting this right might take some time, and that we should get a move on. Kristian has looked into various options for this and will report soon about the best options for next year.

We ended the meeting by brainstorming ideas for “fantasy PyCon UK”. To keep things moving, I suggested that we took it in turns to suggest a short . I didn’t feel this worked brilliantly as a format (I’m sorry about this) but it led to some quite useful discussion about the kind of conference we might want to be involved with. It also provided evidence of Inglesby’s Law: “As a gathering of Python programmers goes on, the probability of the discussion ending up at Python 2 vs Python 3 approaches 1”.

Once again, I’d like to thank everybody who came for giving up their Saturdays and bringing lots of ideas and enthusiasm to the discussion. I’m looking forward to working with all of you over the coming months.

Publicity

Here is an incomplete list of places we should be promoting the conference:

Design Specification

We plan to reuse the structure of last year’s website, but with updated design. In addition, we would like the design to be adaptable for other things, such as:

  • stickers;
  • posters and signage;
  • slides;
  • social media.

So, we’d like:

  • a colour palette that we can use;
  • a main image for the website homepage and our Twitter background;
    • it should be a bit shorter than what we have right now on http://www.pyconuk.org/, which takes up a little too much height;
    • it should include the snake characters in Doctor Who outfits, and the PyCon UK crown;
  • some smaller images, with and without the snakes, that can be used on other pages on the website and elsewhere.

Speaker diversity

PyCon UK 2016 aims to present a high-quality and balanced programme of talks and other sessions (workshops, sprints, panels).

These sessions will represent the diversity of interests within the Python community, and also the diversity of people who are active in the community.

PyCon UK 2015

At PyCon UK 2015, we had approximately 70 talks.

About 57 of the speakers were male, and the vast majority were white. Historically, we have not done as well as we could in attracting proposals from beyond this easy-to-find constituency of speakers.

Target

Our target at this PyCon is to receive at least one-third of our talk proposals from women, and a substantial improvement in the representation of other PyCon minorities amongst the talk applicants.

This is not impossible to achieve, by any means.

PyCon US:

  • 2011: about 1% of speakers were women
  • 2014 and 2015: about one-third were women

DjangoCon Europe:

  • 2014: two our of 32 speakers were women
  • 2105: approximately one-third of speakers were women
  • 2016: approximately one-half of speakers are women

It’s less easy to put numbers to other under-represented groups.

How to meet this target

To achieve the numbers we’re aiming for, we will need to encourage people in under-represented groups to submit more talks.

Specifically, this will involve (all of these things have been tried, tested and successful):

  • having published diversity and accessibility policies
  • making a big deal of the fact that we want a more diverse speaker line-up
  • asking particular people to submit proposals
  • making it clear that speakers who require financial assistance can expect to receive it
  • setting up a speaker mentor scheme to help speakers who’d like it
  • providing and advertising a quiet room at the event
  • providing and advertising a crèche
  • providing and advertising speech-to-text transcription (may depend on budget)
  • stressing that PyCon will be an oaf-free-zone, and that the code of conduct will be taken very seriously
  • making it clear that attendee well-being matters (for example)

Infrastructure

The PyCon UK infrastructure is comprised of the following services:

Website

  • GitHub for code
  • GitHub for hosting
  • Travis-CI for code testing
  • DNSimple for DNS
  • 123-reg is the pyconuk.org domain registrar

Ticketing

  • ti.to

Organisation

  • GitHub for Issues
  • GitHub for docs code
  • ReadTheDocs for docs hosting

SMS App

  • GitHub for code
  • Twilio for SMS delivery

Voting App

  • Heroku for hosting
  • GitHub for code
  • Opbeat for Error tracking

Chat

  • Slack for organisers
  • Slack for attendees

This boils down to the following Vendors:

  • 123-reg
  • DNSimple
  • GitHub
  • Heroku
  • Opbeat
  • ReadTheDocs
  • Slack
  • ti.to
  • Travis-CI
  • Twilio

Pricing

Ti.to

Based on their pricing page and using the dummy values of 300 tickets at £200p/ticket (note: not actual values) we would be looking at paying between £3176.46 and £3600.

GitHub

Free. We should have no need for private repositories as things currently stand.

Travis-CI

Free. We currently have no private repositories and can stay on the community offering.

ReadTheDocs

Free. We’re currently using their free offering which I don’t expect to change.

Heroku & Opbeat

We have yet to discuss whether the Voting app will be needed this year but it’s currently running on free versions of both Heroku & Opbeat.

123-reg & Twilio

Waiting on information.

DNSimple

$50 per year for a single user account, limited to 5 domains. We should only need the one domain.

DNS

Each year’s website has a subdomain under pyconuk.org (eg 2016.pyconuk.org) with a matching repo in our GitHub organisation.

DNSimple is configured with a CNAME for each year hosted on GitHub Pages (2015 onwards). URL records have been set up to redirect pyconuk.org and www.pyconuk.org to the appropriate year subdomain.

Years prior to 2015 have A records pointing them to a server kindly hosted by Zeth.

Passwords

Account passwords are currently in a 1Password vault that only George has access to. This needs to be improved.

Website Deployment

The website can be built and deployed locally by running make deploy. However this is not ideal when using a Pull Request workflow since it requires someone to have a working environment and thus TravisCI has been set up to deploy changes made to master.

For more details on this see the website readme.

GitHub Permissions

Owners are:

  • Charlie
  • Cory
  • George
  • Kristian
  • Owen
  • Peter

Two main teams:

  • Core: Basically everyone
  • pydata: PyData related folk

Giving Push Access

Most of our repos are public so forking and PRing are simple, however on heavier usage repos (main website, ironcage, etc) it can be easier to just allow write access.

Make sure the repo in question is added to the core team here and has Write permissions.

Financial Aid for PyCon 2016

Goals of Financial Aid

The goal of the PyCon UK financial aid program is to ensure that PyCon UK’s delegates and speakers reflect the broader Python community, both in the UK and the world. The Python community is a diverse one, and one of the ways this diversity manifests itself is in a diversity of financial background. Restricting attendance to only those who can pay their own way or who can have their attendance funded by their employer necessarily leads to a conference that is not representative of the wider community.

This means that it is important that we enable both delegates and speakers who would otherwise be unable to attend the conference to attend. The easiest way to do this is with direct grants for financial aid, which can come in various forms. Some of these are fairly classic: direct grants of money, subsidised/free tickets, paid-for accommodation. Some of these are more unusual: funding childcare facilities or having a child-friendly policy, for example.

All of these ideas are in service to the goal that, wherever possible, people who would like to attend PyCon UK 2016 are empowered to attend PyCon UK 2016, regardless of their personal circumstances. Ours is a community of inclusion: applying a financial test for membership runs counter to our principles.

To put this more concretely we have two goals:

  1. Obtain a wide variety of speakers. Speakers are an important resource for PyCon UK, and it should be noted that they do a large amount of unfunded work in order to present. We should enable a wide variety of speakers at PyCon UK, and while we should aim for many of them to be local, we should also endeavour to find some speakers from further afield. Those speakers in particular will likely need financial assistance for travel.
  2. Obtain a wide variety of delegates. Again, our primary focus should be enabling potential delegates from the UK and Europe to attend. However, substantial value is obtained by having delegates from further afield attend, and money should be set aside to assist in their travel.

I’ll break down my proposed approaches for those two groups below.

One thing I am explicitly excluding from this discussion is teachers and the teacher track. This is because historically our funding for teachers has come entirely out of the grant from BAML. My expectation is that this will continue, and that the BAML grant will be entirely earmarked for the teacher track and will not touch the financial aid budget. I’m happy to work with Carrie-Anne on integrating the teacher applications into the same forms etc. as the financial aid stuff, but I don’t expect it to affect my budget at all.

Speakers Tickets

Historically PyCon UK has had a policy of “everybody pays” which applies to both organisers and speakers. This policy has come under fire in some circles recently as failing to adequately take into account the (essentially unpaid) work that speakers do for a conference and the value they add. This unpaid work is necessarily more difficult for those who are already financially limited, which means that it disproportionately affects minority groups.

The “everybody pays” mantra[0] is an important one to both PyCon UK and to the broader Python conferences. The idea of funding speakers is a compelling one, and good cases can be and have been made for funding speaker attendance[1]. However, I do not believe that we should be pioneering such a model at this conference.

Instead, I want to propose a model adapted from that used by PyCon AU in the last few years. The policy would be:

  1. All speakers may apply for financial aid to cover expenses. Speakers will be prioritised over delegates.
  2. Money will be set aside in the financial aid budget to cover free admission for all speakers. That is, all speakers will be entitled to free admission.
  3. However, all speakers will be faced with the choice to pay for their ticket. It will be made clear that if they do, the money for that ticket will go directly and wholly into the financial aid budget, and will be used to cover the costs of speakers less able to pay.
  4. In particular, speakers whose attendance is funded by companies will be encouraged to pay.

The goal with this policy is to make it clear to those considering the CFP that they will be able to attend for free if their talk is accepted: that is, they will not be asked to pay for the right to speak. However, it also has the goal of explicitly indicating to those that can afford to pay that their doing so will directly enable other speakers and delegates. Ideally, this will lead to the impact on the financial aid budget of free tickets for speakers being minimised, or possibly eliminated.

By default, we may want a radio box here for speakers that has got the “pay for ticket” option selected by default. That essentially opts speakers into paying by default, while enabling speakers to opt out.

This policy can be summarised as: “everybody pays, unless you can’t”.

Delegates Tickets

Over the past few years, we have offered a number of subsidised tickets for delegates. Last year in particular offered community tickets, tickets for students, and tickets for those who were unemployed or otherwise had reduced incomes.

My proposal this year is to roll these things together. Complexity makes our lives difficult, and we should aim to have as straightforward a process as possible. For this reason, delegates that need access to reduced-price tickets will be directed to apply for financial aid for their ticket. This will allow us to bring them in to the financial aid process, and ensures that we don’t earmark money for reduced-cost tickets that we end up not using: instead it can be rolled back into financial aid for other attendees.

It will be made clear that students and those on low/no income will be prioritised for heavily discounted tickets. Note that by default financial aid will not offer free tickets, merely heavily discounted ones: this ensures that delegates have some motivation to let us know if they can no longer attend, which will free up their ticket for others.

I also plan to remove the notion of community tickets as a formalised category: it’s not clear that that was a successful approach last year, and it adds additional administrative overhead I don’t really want. I am open to being convinced on this point, but for now I’m assuming that offering a new ticket category is unwise.

The effect of this is that people applying for financial aid need guaranteed tickets, because the financial aid process is going to be slower than the standard ticket sales method. We’ll need to decide as a committee how many tickets to set aside for financial aid, with the understanding that we will over time free them up back to the standard sales channel if they are unclaimed.

Expenses: Travel, Accommodation, and Other

Historically, other PyCons have required itemised breakdowns of these costs. However, many financial aid coordinators in other conferences are coming to the view that this represents unacceptable administrative overhead, and I’m inclined to agree with them. It is generally unwise for us to make anyone, attendees or the committee, categorise expenses. Instead, we should assume that delegates have a good understanding of how to cover their costs.

This means that we’ll ask delegates to apply for a flat sum of money to put towards their expenses. We will make it clear to delegates that the lower this number is the more likely it is that their grant will be accepted in full: for larger sums of money we’re likely to make partial grants rather than full ones. This works because partial grants are more likely to be useful than no grant at all, especially for those travelling from overseas. LVH has suggested a ‘flood fill’ algorithm for funding grants[2], which I think will be useful here.

For the sake of accommodation, we will also volunteer to put financial aid applicants in contact with one another for the purposes of arranging shared accommodation. We will make it clear that sharing accommodation will likely reduce costs, which makes their grant request smaller and more likely to be granted. We will also allow grant applicants to specify constraints on who they’d like to share accommodation with (for obvious reasons).

To be clear: we will not be asking attendees to account for their spending. We will not demand receipts. We will ask for them to return any unspent funds, but I expect that we won’t have much, especially if we tend to partially fulfil grants. It’s my belief that the money saved by undertaking this work does not justify the a) increased workload on volunteers, and b) the feeling of grant recipients that they are being policed and distrusted.

It may be sensible to say that anyone who applies for financial aid, regardless of the success of their application, should be offered a reduced-price ticket. I haven’t decided if we should pursue that direction or not yet, and feedback would be welcome here.

Process

Data Collection

For data collection, we plan to use ti.to alongside the rest of our ticketing function. This helps keep our systems fairly simple, while providing a good centralised location to collect all data about financial aid applicants.

Additionally, thanks to the use of ti.to we can ensure that only administrators can access the personal data of the grant applicants.

Proposed Questions

The proposed questions are below, including the type of answer that can be provided, as will the purpose of the question.

Question Answer Type Purpose
Preferred Name Free text For use when communicating with applicants.
Contact email address Email For use when communicating with applicants.
Requested Grant (in GBP) Currency Will filter into grant process.
Have you already registered for a ticket, or would you like one set aside for you until your grant is allocated? Boolean If attendence is contingent on having a ticket but the delegate cannot afford one without aid, we may need to ‘reserve’ a ticket until the grant is processed.
Applied to speak? Boolean/Number If they have applied to speak, we’d like to know in order to support them. We should aim to have a ‘proposal ID’ the delegate can provide in this field, as well.
Planned attendance days Date If an attendee is planning to attend only part of the conference, that’s useful to know.
Planned attendance tracks Date Useful for identifying teachers etc.
Preferred Payment Method Selector We need to decide how we’re open to paying grants, and allow delegates to select their preference. This may imply further up questions.

Committee

The process of awarding grants will want to be done by a committee. The job of the committee members will be to review grant proposals and to allocate those proposals a ‘score’ that reflects how important their receiving a grant is believed to be. This score will then be modified by a few fixed properties (are they applying to speak etc.), and will then be fed into the grant application algorithm.

If you’d like to be considered to be on this committee, please let me know. I won’t be choosing this committee yet, certainly not before we’ve finalised the process and begun advertising the grants, but I’d like to prepare a list of people who are interested as early as possible.

The committee will be chosen by the beginning of the call for proposals (see Dates).

Key Dates

The financial aid proposal website will be open from the beginning of the Call For Proposals, and will remain open until the close of ticket sales (see Dates). However, to avoid congestion and a heavy workload at the end of the process, there will be several “early rounds” of grant allocation. The goal here will be to encourage people to apply as early as possible.

These dates will be allocated once the dates for CfP and similar have been decided.

Emails to Community

Emails sent to the community should be reviewed before being sent. This is even more important than changes to the website, since emails can’t be fixed before you hope anybody has noticed it!

Save the Date

Some advanced warning: PyCon UK 2016 will take place at Cardiff City Hall from Friday 16th to Monday 19th September, with some additional workshops happening on Thursday 15th.

The conference will be formally announced, including details of tickets, financial aid, and the Call For Proposals, in mid-March.

Follow us on Twitter (@PyConUK) for the latest news.

Launching the conference

Hi everyone,

I’m delighted to announce the launch of PyCon UK 2016!

The conference will run from 15th-19th September at Cardiff City Hall, with a programme of talks, workshops, and other events aimed at the whole Python community.

More details are on the conference website, where you can buy a ticket or submit a proposal for a talk or a workshop.

We have worked hard to ensure the conference is more affordable than recent years. Tickets start at £96 for the weekend, and we are offering financial assistance to help people who would struggle to afford a ticket or other expenses.

The website’s code is on GitHub. If you find any problems, please submit an issue or a pull request.

If you run a local user group, please share this email with your members.

We look forward to seeing you in Cardiff in September!

~ Peter, on behalf of the PyCon UK Committee

Tweetstorms

It’s absolutely not necessary to get every tweet from the @PyConUK account reviewed before tweeting, but tweetstorms probably should be reviewed.

Launching the conference

Feedback From PyCon 2015

Core Issues From 2015

The percentages next to each point in the below list is the percentage of people which shared similar views. The list is in order of the most mentioned, to the least; only the top 10 have been taken.

  1. Talks running over their slots or cutting it fine, not allowing people to change rooms. (18.3%)
    • This comment appeared the most throughout the feedback. It was mentioned that this issue is also escalated when a speaker runs over their time slot. Changing rooms involved interrupting a speaker when entering.
  2. Food quality wasn’t favoured, and there was a lack of healthy snacks. (13.7%)
    • Healthy snacks was mentioned many times, and the general quality of the food at meal times.
  3. Drinks repeatedly ran out (especially water) (10.3%)
    • Variety of drinks was also raised in other bits of feedback. People wanted more options than tea, and coffee. However, they didn’t mention water as another option we had available so maybe this is related to the shortage.
  4. No printed schedules (10.3%)
    • This was an issue for those without smart phones. Some within the feedback mentioned that they would have been happy to pay the printing costs to get a printed schedule.
  5. Signage to rooms wasn’t clear (9.1%)
    • It was said that it was difficult to find rooms which talks were in, and that maybe a map would be a good solution.
  6. 30 Minutes for talks was not enough (9.1%)
    • Talks that were this long seemed either too ambitious, or too much as though it was a README.md without enough depth
  7. Variation of foods at meal times (8.0%)
    • Vegetarian options, and vegan options were seen as limited. Although it was mentioned that the effort was appreciated.
    • Also the variety of breakfast and desert was raised, not as much however.
  8. No information regarding the target audience (Beginner, Advanced, etc) (6.8%)
    • This appeared as though it would have been very useful information to the attendees. It would allow then to go to talks which were closer to their knowledge level
  9. Venue was over capacity (6.8%)
    • This was already known
  10. Length of serving times and queues in the food queue (5.7%)

*Education Track Specifically 2015

  1. Organising the Raspberry PI’s (not enough)
    • Also no option to purchase them

Core Positives From 2015

  1. The friendly atmosphere throughout the conference (37.9%)
    • This was very valued, and mentioned by many people.
  2. Talks (22.9%)
    • The talks were found to be of a high quality, interesting, and enjoyed by many.
  3. Range of the talks and schedule (21.8%)
    • The range of the talks were talked highly of by many people.
    • Attendees’s especially enjoyed how there was a good range of talks which were not just code based.
    • Talks that were appealing to similar interests were not concurrent, allowing people to attend all those which they would like.
  4. Diversity (14.9%)
    • The general diversity of the attendees at the conference was noted, and spoken highly of.
    • Also it was noticed (and appreciated) how diversity mattered.
  5. Good Food (13.7%)
    • The quality and variety of food was enjoyed. Especially the very “British” aspect.
  6. AV (10.3%)
    • The A/V recordings in alt rooms was a good quality.
  7. Kids day (9.1%)
    • This was greatly enjoyed, especially the inclusion into the lightning talks.
  8. Education Track (6.8%)
    • This was found very informative, and added to the diversity at the conference.
  9. Good drinks (6.8%)
    • The drinks being provided (including beer) were appreciated.
  10. Community (6.8%)
    • The entire community throughout the conference was loved. People felt included despite different knowledge levels of coding.

Company

In 2016 we incorporated the PyCon UK Society Limited. so now we have a distinct independent legal entity.

Limited By Guarantee

IANAL etc. but expect everyone you deal with officially (mostly banks) to assume “Ltd.” -> “Limited by Share Capital”. We do not have share capital, we’re Limited By Guarantee.

Non-Profit

In formal legal terms, we’re a straight-forward vanilla company. There’s nothing special in our articles, we’re not a charity, we don’t have anything like a Community Interest Company asset lock.

Just being a legal entity is a dramatic improvement over what we were, involving a fair bit of paperwork. Any further improvements can come later.

However in spirit we’re non-profit; nobody’s drawing any kind of salary, the goal is for all money to be spent on “the promotion of Python in the UK” etc., and this is enough to count for e.g. a Barclays Community account.

TL;DR: We’re non-profit in spirit but not in law; be clear if asked, because “in spirit” is often good enough.

Guidance for speakers

We will need to give guidance to speakers about what to expect.

This will need to include:

  • How long they are speaking for, including time for questions
  • The likely size of the audience
  • How questions will work (including giving them the option of not having questions)
  • What kind of A/V equipment there will be
  • Whether their talk will be filmed
  • How they can get mentorship/advice from established speakers

We can turn this into an email after we’ve notified speakers that they’re speakers

Howto guides

Set up the conference Slack

Organisers

URL: pyconuk-organisers.slack.com

A standard Slack team with no changes to the default settings.

You can see a full list of admins in the Slack admin panel. At time of writing (11 September 2018), the admins were:

  • Charlie
  • Daniele
  • George
  • Kristian
  • Owen
  • Peter

Attendees

This is usually created a week or so before the conference starts.

Thanks to Baptiste Mispelon for his help with getting this Slack set up in 2016.

The slug is pycon-{year}, e.g. pycon-2016.

Admins are usually whoever’s on the organising committee for that year.

Settings
  • Team Signup Mode: Invitation only
  • Default Channels: #announcements, #social
  • Username Guidelines: Default
  • Name Display: Display usernames
  • Require @ for mentions: No
  • Do Not Disturb: 8PM -> 9AM
  • Hide your team URL from external sites’ logs: Yes
  • Calls: No
  • Team Icon: Yellow Python (slack_avatar.png)
  • Team Name & URL: PyCon UK 2016 & pyconuk-2016
_images/slack_avatar.png
Permissions
  • Messaging:
    • People who can use @channel and @here: Team Owners only
    • Show a warning when using @channel or @everyone: Always
    • People who can post to #general: Everyone
    • People who can use @everyone: Team Owners only
  • Invitations: Don’t allow everyone
  • Channel Management:
    • People who can create private channels: Team Owners only
    • People who can create channels: Team Owners only
    • People who can archive channels: Team Owners only
    • People who can remove team members from private channels: Team Owners only
    • People who can remove team members from channels: Team Owners only
  • Message Editing & Deletion:
    • Allow editing: Never
    • People who can delete messages: Team Owner and Admins only
  • Stats: Team Owner and Admins only
  • Custom Emoji & Loading Messages:
    • People who can manage custom emoji: Team Owner and Admins only
    • People who can manage custom loading messages: Team Owner and Admins only
  • Slackbot Responses: Enabled
    • People who can add Slackbot responses for your team: Team Owner and Admins only
  • Public File Sharing: Yes
  • Gateways:
    • XMPP (SSL only): Yes
    • IRC (SSL only): Yes
    • IRC (no SSL): No
Invitations

New members can be invited by Owners or Admins at https://pyconuk-{year}.slack.com/admin/invites.

Slack places limits on invitations when the accepted:sent ratio is low. See here for more details.

Channels

At time of writing (13 September 2018, pyconuk-2018), we had the following public channels:

  • announcements (admins only)
  • av
  • djangogirls
  • feedback
  • general_chat
  • helpdesk
  • introductions
  • recruitment
  • social
  • talks
  • undefined

And private channels:

  • chairs
  • contributors
  • djangogirlscoaches
  • helpdesk-helpers
  • sponsors

The following channels are auto-joined when somebody signs up (configured in Settings > Default Channels):

  • announcements
  • helpdesk
  • introductions
  • social
  • undefined

Note

We have the metadata in Ironcage to detect if somebody is a contributor, sponsor, etc. It would be a nice future enhancement to set up a way to auto-join people to the appropriate extra channels.

Indices and tables