If you're like me and you pack light and do laundry, you might be wondering whether Parc 55 has a laundry room. As far as I can tell they only have that very expensive valet laundry service, but there are two laundromats 2 blocks away, one of them even has good ratings :)
Talk:Wikimedia Developer Summit/2018
Is it just how things turned out? Or did we only invite people from Google? I don't think it looks that great if all of our guests come from one corporation that some see as potentially harmful to our movement.
I am not sure @Legoktm, but interesting question. I will ping Victoria to make sure she sees this.
Yes, it's a good question and we went back and forth on it trying to figure out what to do. Google asked us to send engineers from their Knowledge Graph and Data teams along to the Summit as they had done in the past. Of course this Summit is different so the answer was not obvious. In the end, we decided to let them participate with a small contingent of engineers (3) as "special guests". This is part of our effort to build a technology partnership with them which I believe can be very beneficial for us in the future. The tech roundtables that we are starting with them next week are also part of that effort. The goal is for us to a/find out what technologies they have that we can learn from and borrow to support our mission - such as machine learning, content translation etc and b/ to help them make more efficient use of our APIs. We will evaluate the practice of inviting "special guests" to future summits based on what we learn from this coming one.
Thanks for the response. So the answer is basically "Google invited themselves" :/
@Legoktm maybe the more complete answer is: The specific teams in Google invited themselves and we didn't send active invitations to other Tech companies who use our data/API heavily and may have wanted to attend. For example, the knowledge base team in Apple, I bet, would be interested to have someone in the summit if the consumers of our data and API are going to be represented.
One thing we do need to keep in mind is how we aggregate the input from "special guests". Basically, this input will not be representative of our total data/api consumer population and we need to remember that due to the relatively closed nature of the summit and the way people got added, the discussions can be skewed heavily. I suggest at the note taking level, we keep the notes from special guests separate and handle those separately in the future.
The call for submissions currently says, "Position papers will be published for other Wikimedia Developer Summit 2018 participants to view in advance of the event." Will the general public also be able to read position papers in advance of the event? Will there be a mechanism for comments and rebuttals?
I am sure there will be on wiki discussions - and they will be explicitly encouraged.
As a follow-up: it would be nice if the community at large got a chance to read and respond to the various proposals before the committee made their decision, even if the window for review was necessarily very short. Perhaps some position paper the committee thought wasn't very strong would get a surprising amount of community response, or something which looked strong got a quick and devastating rebuttal from members of the community who would be affected. Or perhaps nothing significant would be said at all -- regardless, community participation would make the position paper selection process process closer to an selection of representatives by the community (mediated by the program committee). As Boss Tweed said, "I don't care who does the electing, so long as I get to do the nominating." It would be great if the community were involved in the "nominating" process of position paper review.
We are held to pretty intense non-flexible deadlines for coming up with a final participant list this year and it is unlikely that all position statements will be published for everyone in Wikimedia to read, review and comment on. We do have a good mix of people on the Program Committee and accepted position papers for all participants will be published on the event page under the participants section.
This year is a first test of this new model - you better believe that we:
a) will learn a lot of lessons this time around
b) will change for next time based on feedback and what works and what does not work.
c) are doing our best to be as fair as possible, ensure diversity, but also at the same time not attempt a really complicated process of review for the first year of this event.
Why won't rejected position papers be published?
Edit: To clarify, I think in many ways what we reject is more intresting than what we accept. I already have a fairly good idea about the types of ideas that WMF usually goes for; I want to see the crazy ideas that everyone rejects but are potentially unrecognized great ideas.
I think this is an interesting point, that we could definitely consider... I'll put it on the agenda.I
I don't think we can change the rules at this point. People submitted statements on the assumption that if they were rejected, they would remain private.
Reaching out to everyone individually to get permission could be a lot of work. Of course, anyone could choose to publish their own rejected submission.
I'm kind of confused where in the rules it said they would remain private if rejected. I was assuming that rejected papers would be public up until Rachel's comment, and the rules if anything seem to suggest that (All they say is "Position statements will be published for other Wikimedia Developer Summit 2018 participants to view in advance of the event."). Furthermore, its pretty common in the Wikimedia community for rejected things to be public (rejected wikimainia submissions, rejected grant applications).
Oh, I seem to be confused or mistaken. I'm pretty sure a draft of that paragraph said something like "Accepted position statements will be published", so my reply was based on that memory (or false memory). I agree that the current wording does not seem to imply privacy of rejected statements. At this point, I'll withdraw and let @Rfarrand (WMF) answer.
Subsequent to posting my previous comment, i submitted my paper, and the wording on the google form does kind of imply what you are saying.
Well, nothing's stopping us from creating a wiki page for folks to *voluntarily* post their rejected position statements. If the rejection notices aren't sent yet, they could include some brief text explaining the ambiguity in the initial prompt, and encouraging folks to post their position statements to Wikimedia Developer Summit/2018/Other proposals or something like that.
So the current plan is to publish both the list of participants and their position papers in advance of the event?
Yes
Is there a published timeline for what happens after position papers are submitted? When can submitters expect to be notified of acceptance/rejection, when are the topics going to be set, etc?
To be clear, I know that "position papers -> themes -> topics/sessions" and also Topic:Tz0nc7sq4h93uvwe gives steps forward. I'm asking about externally visible actions and timelines, so that (on behalf of everyone who submitted) we know when we'll find out the next thing (whatever that is).
I have heard a rumor that the selection of participants will be done in early November.
I have heard a rumor that the selection of participants will be done this week.
Optimistically, the selection could be done as early as this week. Personally, I think next week is a more likely target, but that's still not a commitment. Officially the committee has to decide by early November.
Very little of our work happens individually. Often, ideas and positions and proposals and followup work happens collaboratively. For example, while I might be submitting a position paper at this dev summit, it is not the case that those ideas are entirely mine. My position has evolved as a result of work I have done and will be doing with others. I think, accordingly, multi-person position papers should not be ruled out in future editions if this format is continued.
This is particularly an issue for any third-party organisations who might be involved - the organisation might have a position they want to submit, but is the only way to do this by just each individual submitting their own, despite their main reason for doing this in the first place that it's for their work/organisation, and the points are largely those of the organisation anyway?
One would think it would make a lot more sense for the organisation (or relevant parts, at any rate) to be encouraged to collaborate internally, submit a group position, and then if accepted, simply send a single representative thereof.
On that note, issues regarding a lack of support for third-party organisation was exactly the position we wanted to submit from ShoutWiki. But, er, this?
Hi all. I was a bit confused about what happens to the position statements once they are submitted ("why" we are asked to provide a position statement). Victoria and I had a very quick chat about it and she suggested that I share what I understood from that call here, in case it helps anyone else working on their statements now. These are my understanding of the conversation:
- One goal for asking potential participants to provide statements is to have some way of assessing whether participants have spent some time on the draft of the strategy, thought about it, and reflected on how technology can help us in that strategic direction.
- The other goal for asking for statements is to design the program. What happens with the position statements is completely up to the PCs, however, one can imagine a couple of scenarios: your position statement is accepted and it's the only position statement on this topic. it's also big enough to justify a dedicated session. In that case, you're probably going to be asked to run a session on that topic (how will the session exactly be is TBD, likely between you and the PCs.). Your position statement is accepted and there are some other position statements that are thematically/technically close. Such position statements will form one session. In this case, one or more authors may be asked to run a session jointly.
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.
In the "Number of participants" thread, @Cscott proposed publishing an example paper so people can get an idea of what exactly is expected of them.
@Rfarrand (WMF) pointed out that there were concerns that publishing an example would impact the way others wrote theirs.
I would like to second cscott's request for an example, so I've split it into a separate, non-resolved thread. I'm hopeful we can find some kind of compromise with an example that doesn't influence others too much, but provides guidance on structure and focus of the papers.
To kick-start the process, I've gone ahead and written three examples at Writing Tips/Examples. I have no idea if these examples match the expectations of the Program Committee or not, but hopefully it can at least spur some discussion.
(Incidentally, this should also serve as an illustration of the fact that a single person may well be able to argue multiple positions. So maybe I have this all wrong. Please write better examples to replace mine if so!)
We will go ahead and publish a few examples. Thanks @Cscott for making a start.
@VColeman (WMF)have the examples been published somewhere?
I would have liked to see a reference to the strategy that we are organizing to support. I think the best link is https://meta.wikimedia.org/wiki/Strategy/Wikimedia_movement/2017/Direction because the parent page is more of a cover page. I hesitate to Be Bold here because it looks like a small group of people owns the main page. If any of you could add a reference to the strategy, that should be useful to others, I think.
This seems to get off to a bad start. The notion of "First Name" and "Last Name" is highly culturally-specific. Some people have only a single name, which will be upsetting since both "first name" and "last name" are required fields. Some have three or more. Even I have a "first name" which I don't actually go by and usually initialize.
Why do we need to break down names anyway? Just have a single "Name" field and be done with it.
Thanks! Good point. It is helpful to be able to search / sort participants by both first and last name. Can't change now as it will mess up the form results formatting. We have done this format in the past without issue / confusion. I will add a note to the form under last name saying "last name / surname"
Perhaps "First / given name(s)" and "Last name(s) / surname(s)"?
And if you have only one name?
Put a - or something? (It's not that people don't get creative in these cases, unless we assume that "The one... The only..." is Seddon's real name.)
My point is just that these choices broadcast to prospective applicants how we feel about diversity and how US-centric we are. A little bit of care can make us seem more welcoming.