A blind review of papers in any language will unnaturally favour native speakers of that language.
I'm pretty sure I can be more eloquent and convincing in a proposition written in Italian than in English, even if my written english is perfectly ok for communicating, I certainly am at a disadvantage compared to all the native speakers when it comes at getting selected for an english text.
How do we plan to account for such bias? Will I be allowed to write the paper in Italian?
I think this issue while very real is not unique to us or Dev Summit. Most (all?) prominent professional conferences in our space are in English which means that non native speakers are disadvantaged to some degree. One way to solve for this is to ask a native speaker colleague to go over your paper and adjust the language if needed. We will also offer this support through the Dev Summit organizing committee.
Somewhat related: I saw one proposal from a non-English speaker which was quite terse (compared to Writing Tips/Examples at least), presumably because writing English is hard. It seems hard to balance "write close to 500 words in order to adequately support your idea" with "write just a handful of words so that translation to English is not a burden". The natural tendency is to assume that the terse position paper has a shallower understanding of the problem.
To _joe_'s point: I think I would prefer that submissions be in the submitter's native language and be long/complete/demonstrate knowledge of the various sides of a particular argument, rather than be made terse and incomplete by the English requirement. After all, machine translation software is pretty good. The Program Committee can be given the text in the original language along with a machine translation (or the submitter could optionally submit their own translation), and a native speaker for language X could be consulted for those that made an initial cut or raised translation issues. The program committee may specifically wish to select participants outside the usual English-language community to ensure diversity of thought; exposing the native language of the submission would be helpful in that regard.
Just to argue the other side as a devil's advocate for a moment, if the presentation/discussion at the Summit is going to be in English, then fluency in English may be a valid selection criterion.
Switching back to advocatus Dei, if viewpoint diversity is to be achieved one should evaluate proposals in their native language, as proposed above, but then separately arrange for translation assistance at the in-person summit for those participants who request it. For example, an eloquent eswiki user with a compelling position paper could be paired with an Spanish-speaking facilitator who could translate for that participant on-the-fly in group discussions (sometimes even those who understand English well appreciate assistance *speaking* English, especially extemporaneously.)
A couple thoughts on this.
First, it is undoubtedly the case that our movement is dominated by the use of English in ways that are some times much more insidious than having English as the working language of the Dev Summit. For example when we talk about making content available in places where Wikipedia is not prominent like the Global South we often times mean making English content available as opposed to content in the local language(s) because we assume that people who will access our projects will speak English anyway. This kind of "linguistic imperialism" is far more insidious. One of our greatest challenges as a community and as a movement is to become truly multilingual.
Second, bear in mind, that the ability to express oneself elegantly and succinctly and correctly in English is not equal even amongst native English speakers. This is particularly pronounced in technical communities and something that our Program Committee is well used to and I trust them to make the needed allowances when selecting papers.
I am fluent enough to present at the WMDS; still I'm at a big disadvantage compared to native english speakers when it comes to what basically is a writing contest. THe problem being this is a contest to get one of the 40 slots, I'm pretty sure anyone judging the propositions will favour the better written (as in: more eloquent) ones.
I have nothing against using the de-facto lingua franca of software development at the conference
To be clear, _joe_, I wasn't speaking of you above. I saw a proposal from a different developer whose themes I actually support strongly, but which was quite brief, presumably due to non-fluency. (Although maybe they were just taking the 100 word minimum literally?) I agree that as written this terse proposal might lose the "writing contest". OTOH, I trust the intentions of the Program Committee are to evaluate based on ideas not expression, so I'm mostly worried about correcting for unconscious bias.
Anyway, the terse format is Topic:Ty0ou7wd41nw6esh in case you would like to consider that yourself. I agree terse/not-terse is probably an orthogonal issue.
As I see it, there are three orthogonal issues:
1) "writing contest" aspect, favoring fluency (mitigation: program committee could try to guard against)
2) terser submissions from those less fluent (mitigation: position paper examples can give everyone a higher bar to aim for)
3) how to make less-fluent participants equal partners in summit discussions (proposed mitigation: language facilitators)
The submission process is not meant to be a "writing contest."
To clarify, the focus is on ideas, not who can write the most fluently or the most in general. It is my understanding that the program committee will not favor longer submissions over shorter submissions.
The range of word count 100 - 500 words allows for submissions of quite different lengths, which should receive the same consideration. In my opinion, if the call says 100 - 500 words, it means 100 - 500 words without preference for a longer or shorter submission.
I'm happy to clarify this on the writing tips page. The intention is to welcome folks who may not be comfortable writing in English or unfamiliar with writing these kinds of statements.
We invite non-native speakers to reach out for additional support, which we are happy to provide.
@Cscott I personally like the shorter, more structured format, which you shared. Often, having a structure like that makes it easier to put ideas into words.
@SRodlund (WMF) I understand this is not a "writing contest", but take this scenario into consideration: a native and a non-native speaker write about exactly the same ideas. In a blind review, how probable is it that the better written essay gets picked? And that would happen just because it will sound more convincing, more eloquent.
So while it's not intended as a writing contest, it is also that, given the number of slots is fixed. And at this kind of race native speakers are favoured, as anyone who's a non-native speaker trying to get his submission accepted at a scientific conference knows. There is copious literature on the subject, too.
@GLavagetto (WMF) [I am a bit late to this game.] I see your point (and btw, I do think making the process blind will be really hard in practice: many of us discuss and document things that we think about openly and regularly and the people in the committee are people that we have relatively regular interactions with. It will be hard for them not to associate specific statements to specific people, at least if the ideas come from within our community.). Here is one thing to consider in this specific case: it helps that the PC is comprised of primarily non-native English speakers because that will make them potentially less likely to respond to the fluency/smoothness in the language.
As a related note: I'm a supporter of non-blind reviews in cases where we're not talking about pure science publications where you can verify claims with pen and paper. In many fields, verifying claims or results is pretty much impossible in practice and for a reviewer who has a very limited time for the review. In such fields, the reputation of the author(s) matters and that should have influence on the decision to accept a manuscript or not. (And there are major conferences in my field, such as World Wide Web conference, that do single-blind review where the reviewers see the name of the authors before accepting to review.)
Agree with both Sarah and Giuseppe. This is a topic that would be best for Victoria to comment on as we are following this process as defined by her.
I would just say that just because we are doing something this way this year does not mean that we can't significantly change things next time around. At the very least I can assure you that I am dedicated to:
a) experimenting with new ideas like this one (or others) at least once
b) seriously making changes based on lessons learned feedback after we truly give it a chance if things did not turn out well
Again, it is not ultimately my decision anyways, but I think that this year's timeline constraints do not allow for any major changes to the process.
At the very least I will work with Sarah to come up with some guidance for the Program Committee to help them avoid some of the traps of the language bias issues. Unless I am mistaken 9 out of 11 of our program committee members grew up in countries where English was not the main language so at least our committee will already be sensitive & have personal experience with this.
What will matter at the end of the day is the power of the ideas in the papers - not the fluency of expression. We are all engineers and hence well accustomed to terseness and economy of expression. And as Rachel points out above, most of the PC members are not in fact native speakers.