Implement an open and transparent CfP

[amlcurran]

As discussed with @bontoJR on Twitter, I'd like to suggest an open call for papers for App Builders and SwiftAlps.

I was disappointed to see that App Builders didn't hold an open CfP this year. In general, Swift has significantly more closed CfP conferences (inc App Builders, try! Swift, Swift Alps) than other communities in computing (for example, Android, Javascript, or Ruby). This is something Swift should be attempting to completely remove from the community, in my opinion.

Closed CfP conferences are generally considered (citation needed) harmful to communities for various reasons:

• they are self-selecting, by only allowing "whitelisted" people in to a conference, they get more well-known, and therefore get invited to more conferences. This is evident by seeing the overlap between the speakers of try! Swift and App Builders.
• Closed CfPs are generally selected by a committee (I'd love to know how App Builders selected people, but that information doesn't seem to be available publicly). This means, unless you're personally known by someone on the committee, you are significantly biased against speaking at a conference.
• The requirement for being "well-known" results in a bias towards people who maintain and curate an extensive social media presence. Few people have the time to do this.
• Closed and non-transparent CfPs make it significantly harder to ensure there is no discrimination or unintended bias.
• Often the argument for having closed CfPs is that it maintains "a high quality of conference". I'd argue that sharing knowledge between various corners of the community is more far important than making the conference slick. If you want to increase the quality whilst having an open CfP, consider offering scholarships for public speaking training to accepted speakers.

Open CfPs are relatively easy to implement (there is, for example, a platform which allows you to do so with little configuration, although I can't remember what it is called). UIKonf implements one, and I'm sure they'd be willing to help advance the transparency of the Swift community.

As an aside, for SwiftAlps the reason given for rejecting my interest in being a mentor, was that there is no open CfP, and it would be too hard to implement one given its experimental nature. I explicitly offered, outside of a CfP, but was instantly rejected anyway. From a personal perspective, it sucks to be rejected for a conference when you've applied for one. But it sucks even more if you were never given the chance to apply, and no reason for that decision.

I'd like to point out that App Builders is not alone in these problems, and there are plenty of different issues reducing transparency and community values in the Swift community. I plan on opening conversations around all of these, and I'd really like to help out in any way. You're just the first ones I spoke to 😉

[bontoJR]

Thanks, for the issue, I will reply quoting:

In general, Swift has significantly more closed CfP conferences (inc App Builders, try! Swift, Swift Alps) than other communities in computing (for example, Android, Javascript, or Ruby).

For the record, App Builders is a double track conference, Android and iOS, so it can't be compared to try! Swift or UIKonf, considering the broader target.

Closed CfP conferences are generally considered (citation needed) harmful to communities for various reasons:

I can't disagree here, all the points are more than fair, but I would like to point our experience with the CfP this year. We received, analyzed and reviewed (all the organizers) around 120 submissions, of these submissions, only a few were by first timers (we actually selected one for the Android track). We tried to diversify the selection as much as possible and the result was that we had to re-do the whole process 3 times because 3 people either never replied or were unavailable because they already got accepted in other overlapping events. The process was extremely time consuming this year and frankly, after this year experience, I would probably get rid of the CfP without a second thought, but there's a lot of value in submissions, so I have in mind an idea that can fix the common problems (on the organizers' side) of CfP like:

• multiple submissions: people copy and paste the same title and abstract on different CfP.
• interest on the event: the previous reason makes people less interested in joining the event, the effort to apply is minimal and most of the people are not really interested in the event itself, just to give a talk.
• time-consuming selection: reading all the title and descriptions is time-consuming, especially for me that I do organization during my spare time, which means once out of a full-time job and when my daughter sleeps.

Open CfPs are relatively easy to implement (there is, for example, a platform which allows you to do so with little configuration, although I can't remember what it is called). UIKonf implements one, and I'm sure they'd be willing to help advance the transparency of the Swift community.

The idea of a similar UIKonf approach was already in my mind but has a fundamental flaw: anonymity. It might sound a pretty cool thing (for the record, I got selected in the 2015 edition and to be honest I really performed badly), but has a long list of downsides which are:

• diversity is random: this is something I really care about. I can't sacrifice diversity in name of transparency, it won't happen. Selecting a talk without knowing who is behind just doesn't feel good in my opinion.
• anonymity might fire back: I screwed at the UIKonf, it was bad, but I am lucky enough to work hard to improve and make better. Other people might have stopped after that experience, this might lead to a lost speaker.
• anonymity might not be... anonymous: some title and descriptions can give a lot of hints about who is behind the submission, especially with some topics.
• the process is easy to "hack": pick the most trending process, write a proper abstract, give a shining title and you will probably get most of the votes.
• hidden gems are ignored: there are speakers with great talent, amazing qualities, a lot to say, but poor skills in preparing the abstract and title.

I have a process in mind that might be open, that removes the need for anonymity, describes the selection criteria correctly and that can guarantee the correct balance in terms of diversity. It will be tested for App Builders 2018 and might be a starting point for Swift Alps. I will later describe how the process will work (not in this reply, I need to sleep before 😴).

I explicitly offered, outside of a CfP, but was instantly rejected anyway. From a personal perspective, it sucks to be rejected for a conference when you've applied for one. But it sucks even more if you were never given the chance to apply, and no reason for that decision.

Swift Alps is an event that requires a lot of preparation and effort on the organizational side and can be easily screwed. Attendees pay close to 1000 euro or even more to come (event ticket, flight, train, accommodation and food) and a single mentor being not well prepared or under stress can really make a damage: so here quality is a key component. Not performing well as a speaker is a 30-45 minutes thing, not performing well as a mentor is a 9 hours disaster (from 9am to 6pm).

The last year lineup was filled with people who contributed in creating the format, plus a last minute replacement provided by one sponsor because one of the mentors had a family matter and couldn't join. Considering it was the first edition, I decided to select only people I already knew and trusted and the reason is pretty simple: I am the one who takes the critics if things screw up, just me. The rest of the team are very young amazing guys and they simply need to grow in a stress-free environment, so I am the one taking most of the risks.

If an event goes well, no one comes to thank or to cheer usually (cases are really rare).
If we do a mistake, or something doesn't go as expected, then people queue to claim and considering they pay money to attend, it's really hard to ignore them.

Swift Alps was an experimental format and will have a second edition this year which will consolidate the format. Last year we (organizers and mentors) made some last minute changes in the format to make attendees feeling better, this year we will have some extra changes to fix some of the issues of last year, they might work or not, so considering the format is still a WIP, I can't really say how a CfP would work and what criteria should be used for a selection, considering the technical part is not the most important in Swift Alps... once the format won't change, an open selection process will be definitely part of it.

This is my honest point of view, pretty sure it will raise some critics, but I am really open to hearing them. 😄