我如何使用众包来帮助喀拉拉邦洪水救援行动。

by Arnav Bansal

通过Arnav Bansal

我如何使用众包来帮助喀拉拉邦洪水救援行动。 (How I used crowdsourcing to help Kerala floods rescue operations.)

一夜之间，我建立了一个网站，让人们发现紧急请求 (Overnight, I made a website that let people discover urgent requests)

In August 2018, floods decimated the state of Kerala. One-sixth of its population was directly affected. The state incurred property damage worth $3B.

2018年8月， 洪水淹没了喀拉拉邦。 其人口的六分之一受到直接影响。 该州遭受了价值$ 3B的财产损失。

I’m Arnav, an 18-year-old from Bangalore who finished school this March. As the floods were happening, I came across the Kerala Rescue Project. This was a movement of volunteer developers solving tech challenges associated with the Kerala Floods using the web.

我是Arnav ，今年18岁，来自班加罗尔，今年3月毕业。 随着洪水的发生，我遇到了喀拉拉邦救援项目 。 这是志愿者开发人员使用网络解决与喀拉拉邦洪水有关的技术挑战的运动。

The website provided important services. It collected help requests from victims. It helped volunteers and rescuers locate them, and find relief camps. It provided visualizations for disaster response forces.

该网站提供了重要的服务。 它收集了受害者的帮助请求。 它帮助志愿者和救援人员找到他们，并找到了营地。 它提供了灾难响应部队的可视化效果。

As I explored the project on GitHub and Slack, I found a specific problem I felt I could solve.

当我在GitHub和Slack上探索该项目时，我发现了一个我可以解决的特定问题。

请求过多 (Too many requests)

Following a massive once-in-100-years flood, there were a large number of requests for help.

每100年一次大规模的洪灾之后，就出现了许多寻求帮助的请求。

I watched new requests arrive every time I refreshed an API endpoint on the rescue website. When I first discovered it, I spent nearly half an hour just reading through people’s requests.

每当我在救援网站上刷新API端点时，我都看到新的请求到达。 当我第一次发现它时，我花了将近半小时来阅读人们的要求。

They were distressing. Requests about old people, sick and injured people, pregnant women, and infants. Some reporting buildings on the verge of collapse or flood waters rising. Some were from people living elsewhere, unable to reach relatives in Kerala.

他们很痛苦。 有关老年人，患病和受伤的人，孕妇和婴儿的要求。 一些报告建筑物濒临倒塌或洪水泛滥。 有些人来自其他地方的人，无法接触喀拉拉邦的亲戚。

But the distressing ones were amidst a sea of requests that didn’t seem to be immediate or had little data.

但是令人苦恼的是在大量请求中，这些请求似乎不是立即的，也几乎没有数据。

And those were just the ones in English. I couldn’t read requests written in Malayalam (the language of Kerala).

这些只是英文的。 我看不懂用马拉雅拉姆语(喀拉拉邦的语言)编写的请求。

That led me to wonder: how were requests being prioritized? I asked around. Sure enough, people remarked that this was a real issue.

那使我想知道：如何优先处理请求？ 我问了一下。 当然，人们指出这是一个现实问题。

理解数据 (Making sense of the data)

I thought of two approaches to figuring out the urgency of requests.

我想到了两种解决请求紧急性的方法。

自然语言处理(NLP) (Natural Language Processing (NLP))

Words like ‘Urgent’, ‘Infant’, ‘Pregnant’, or ‘Trapped’ indicated urgency, and could be used to classify requests.

诸如“紧急”，“婴儿”，“怀孕”或“受困”之类的单词表示紧急程度，可用于对请求进行分类。

But the data had several problems: requests were in English and Malayalam. And sometimes, Malayalam was written with in the English alphabet.

但是数据有几个问题：请求使用英语和马拉雅拉姆语。 有时，马拉雅拉姆语用英语字母书写。

Many were written in a hurry.

许多人写得很匆忙。

Some suggested translating requests to English first, before applying NLP. But translation is lossy, and I was certain that this wouldn’t work.

有些人建议在申请NLP之前先将请求翻译成英文。 但是翻译是有损失的，我确信这是行不通的。

And finally, I felt that urgency was largely contextual. Would NLP handle it well? Existing sentiment analysis can tell you if the text is positive, negative, happy or sad. But it doesn’t measure urgency.

最后，我觉得紧迫感很大程度上取决于具体情况。 NLP会处理好吗？ 现有的情绪分析可以告诉您文本是肯定，否定，快乐还是悲伤。 但这不能衡量紧急程度。

And there wasn’t time to develop a new model. Especially, given the language problem.

而且没有时间开发新模型。 特别是考虑到语言问题。

众包 (Crowdsourcing)

I was certain that people would volunteer some time to identify urgent requests.

我确信人们会自愿花一些时间来确定紧急请求。

They’d make sense of information suggesting urgency that computers aren’t good at.

他们会从信息的意义上暗示计算机不擅长的紧迫性。

I imagined a website that’d fetch and show requests from the rescue website. Volunteers would rate urgency on a scale that went from not urgent to critical (values 0 to 3), with an option for spam (–1). They could skip requests if they didn’t know the language.

我想象有一个网站会从救援网站获取并显示请求。 志愿者会以从不紧急到严重(从0到3)的等级来评估紧急程度，并选择垃圾邮件(–1)。 如果他们不懂该语言，他们可以跳过请求。

So I got to work.

所以我开始工作。

实作 (Implementation)

I first thought about building the crowdsourcing feature into keralarescue.in

我首先想到了将众包功能构建到keralarescue.in中

The project was open source. Many were building separate-but-linked tools into the same platform. It made sense for me to build right into it.

该项目是开源的。 许多人正在将单独但链接的工具构建到同一平台中。 对我来说，正确地融入其中是很有意义的。

But I had some worries:

但是我有一些担心：

1. I wasn’t certain whether the idea would work. I didn’t want to leave dead-weight on the platform that many depended upon.
   我不确定这个想法是否可行。 我不想让许多人依赖的平台沉重负担。
2. The platform was written in Django, using PostgreSQL. I’ve little familiarity with those, and I didn’t want to experiment-learn.
   该平台是使用PostgreSQL用Django编写的。 我对这些内容不太熟悉，并且我不想尝试学习。
3. The review system would get in the way of iterating quick.
   审查系统将阻碍快速迭代。

So I decided to create my tool independent of the main platform.

因此，我决定独立于主平台创建工具。

If it worked, I’d get them to merge my data. If it failed? Eh.

如果可行，我会让他们合并我的数据。 如果失败了？ 嗯

开夜车 (Midnight oil)

It was already around 1 AM. I set a goal to have my site up within five hours, so it’d be ready when people woke up.

已经是凌晨1点了。 我设定的目标是在五个小时内建立我的网站，以便在人们醒来时就可以使用。

My idea was to use the API endpoint from keralarescue.in to display help requests. Of course, I cached it at my end, so as not to burden the main website.

我的想法是使用来自keralarescue.in的API端点来显示帮助请求。 当然，我在结束时将其缓存，以免增加主网站的负担。

I began developing the platform. I started by creating data models. Then, I worked on functions and API endpoints. Finally, I started work on the front end. My stack included Firebase and VueJS, for quick prototyping reasons.

我开始开发平台。 我首先创建数据模型。 然后，我研究了函数和API端点。 最后，我开始在前端工作。 出于快速原型制作的原因，我的堆栈包括Firebase和VueJS。

I planned to use Wilson confidence intervals to evaluate scores. (Used for the confidence sort on Reddit) They’re an improvement over simple averages, as they account for the number of ratings.

我计划使用Wilson的置信区间来评估分数。 (用于Reddit上的置信度排序 )相对于简单的平均数，它们是一种改进，因为它们考虑了评分的数量。

But I was in a hurry, so I decided to implement this later. Without data, this wasn’t of much use.

但是我很着急，所以我决定稍后再实施。 没有数据，这没什么用。

‘Simplicity’ is a cliche. But I found that it works. Things seemed to improve when I cut out complexity. I wrote simple data models. I dropped reCAPTCHA and authentication, making the assumption that I wouldn’t attract malicious users.

“简单”是陈词滥调。 但是我发现它有效。 当我减少复杂性时，情况似乎有所改善。 我写了简单的数据模型。 我放弃了reCAPTCHA和身份验证，并假设我不会吸引恶意用户。

By around 8 AM, my prototype was ready. And I was ready to drop asleep. I posted a link on GitHub, and went to bed just as the first pageview rolled in on Google Analytics.

到大约上午8点，我的原型已经准备就绪。 我准备入睡。 我在GitHub上发布了一个链接，就在第一个综合浏览量在Google Analytics(分析)上就寝了。

I had no trouble falling asleep.

我没问题入睡。

让人们加入 (Getting people on board)

I had users.

我有用户。

When I woke at noon, I checked analytics before anything else. ~30 visits. And I had two users currently online. From the state of Kerala. Woah.

中午醒来时，我首先检查了分析。 约30次造访。 我目前有两个用户在线。 来自喀拉拉邦。 哇 ！

The feedback was positive. And I’d gathered quite a bit of data. I continued to improve my platform over the day.

反馈是积极的。 而且我收集了很多数据。 我每天继续改善自己的平台。

• I dropped the spam option. I learnt that people weren’t sure which requests were spam. Many were missing information. Those could be completely valid requests from people in a hurry, or people who weren’t good with tech.

  我放弃了垃圾邮件选项。 我了解到人们不确定哪些请求是垃圾邮件。 许多人缺少信息。 这些可能是匆忙的人或对技术不好的人提出的完全有效的要求。

• I implemented the Wilson score. I created an API endpoint that returned the confidence value between 0 and 1 based on all user ratings collected so far. The idea was to get keralarescue.in to use this endpoint to update its dataset periodically. The value could be used to sort, and find the most urgent requests

  我实施了威尔逊评分。 我创建了一个API端点，该端点根据到目前为止收集到的所有用户评分返回了0到1之间的置信度值。 想法是让keralarescue.in使用此端点定期更新其数据集。 该值可用于排序和查找最紧急的请求

• I added a page to display urgent requests. I wanted to make this tool useful as soon as possible.

  我添加了一个页面来显示紧急请求。 我想尽快使该工具有用。

At about 4 PM, I decided to announce it on Slack and Github.

大约在下午4点，我决定在Slack和Github上宣布它。

This turned out to be an inflection point, and for the next few hours, the site had 20–30 users online. They were from all over India, and also the US. The users from Kerala continued to work late into the night, sorting requests at 2 AM.

事实证明，这是一个转折点，在接下来的几个小时中，该站点有20-30个在线用户。 他们来自印度各地，也来自美国。 来自喀拉拉邦的用户一直工作到深夜，直到凌晨2点才对请求进行分类。

I noticed that people were slower at rating requests than I’d anticipated.

我注意到人们对评级的要求比我预期的要慢。

The next evening, I would learn why.

第二天晚上，我会学习为什么。

分类组 (The triage group)

By the next day, I’d finished most dev work. Lots of people started contacting me. They liked my project — especially the simple interface.

到第二天，我完成了大多数开发工作。 很多人开始与我联系。 他们喜欢我的项目，尤其是简单的界面。

In the evening, I received a DM on Twitter from someone named Nishanth, asking if my website could be used to triage requests. We got on a call, and I described how crowds could help determine the urgency of requests.

当天晚上，我在Twitter上收到了一个名为Nishanth的人的DM，询问我的网站是否可以用于分类请求。 我们打了个电话，我描述了人群如何帮助确定请求的紧急性。

He added me to a hundred-member group on WhatsApp. It turns out, these great folks had been using my website in a completely different way.

他将我添加到WhatsApp的一百人小组中。 事实证明，这些伟人以完全不同的方式使用我的网站。

They were actively calling up requesters, and getting updates on their situation. They were rating urgency based not on the text content, but from actually conversing with affected people. WOAH.

他们正在积极地召集请求者，并获取最新情况。 他们对紧急程度的评价不是基于文本内容，而是基于与受影响人群的实际交谈 。 哇。

I realized that my database contained more valuable information than I’d thought. We were directly helping volunteers reach victims. Messages thanking me for my work were rolling into my phone.

我意识到我的数据库包含了比我想象的更多的有价值的信息。 我们直接帮助志愿者接触了受害者。 感谢我的工作的消息正传到我的手机中。

丢失数据源 (Losing the data source)

Back in the main project, people were gearing up for a big event. The government of Kerala was going to announce the rescue website publicly. Heavy traffic was to be expected.

回到主要项目中，人们正在为大型活动做准备。 喀拉拉邦政府将公开宣布救援网站。 预计交通繁忙。

The main website was providing a lot of functionality. Heat maps of requests, donations, relief camps, volunteer coordination, announcements, you get the gist.

主要网站提供了很多功能。 请求，捐赠，救济营，志愿者协调，公告的热图，您就能掌握要点。

I’ve developed serious respect for the dev-ops team, because as the traffic hit the site, they worked overnight to scale it.

我对开发团队非常敬重，因为随着流量涌入该网站，他们通宵工作以扩大规模。

All seemed to be working, except for one thing: they took down the API endpoint I was dependent upon.

除了一件事，其他所有东西似乎都在工作： 他们删除了我所依赖的API端点。

Now, I knew that the endpoint I was using was not going to scale. It returned all requests at once. Towards the end of its life, it was returning a 10 MB dataset. It was made for development, and not production use.

现在，我知道我正在使用的端点无法扩展。 它一次返回了所有请求。 快要结束了 生活中，它返回的是10 MB的数据集。 它是为开发目的而不是为生产目的而设计的。

Fortunately, my site already had a caching mechanism, so it remained operational.

幸运的是，我的站点已经具有缓存机制，因此它仍然可以运行。

I got into contact with the team. They were building an alternative. But they had lots left to build, so I tried not to push.

我与团队取得了联系。 他们正在建立替代方案。 但是他们还有很多需要建设，所以我尽量不要推动。

My site continued to run without issue, and the triage groups (there were multiple by this point) continued to operate, albeit without new data.

我的站点继续正常运行，并且分类组(此时有多个分类)继续运行，尽管没有新数据。

新功能？ (New features?)

At this point, I started thinking about ways to improve.

在这一点上，我开始思考改进方法。

The immediate problem was the influx of large amounts of new data when the alternative route became available. And what other improvements could I make?

紧迫的问题是，当替代路线可用时，大量新数据涌入。 我还能做哪些其他改进？

I thought through some features.

我考虑了一些功能。

• Cohorts based on time: Assign a certain percentage of users to handle the newest requests exclusively. Likewise, assign users to sections of older requests.

  基于时间的同类群组 ：分配一定比例的用户以专门处理最新请求。 同样，将用户分配给较早请求的部分。

• Bloom filters: They are a space efficient way to test set membership. I could use bloom filters for so many things: ensure we exhausted all requests, and limit repeat visits.

  布隆过滤器 ：它们是测试集成员资格的节省空间的方法。 我可以将Bloom筛选器用于很多事情：确保我们用尽了所有请求，并限制了重复访问。

• Status updates: I could build a feature for people to update the status of requests. It was a trivial build, and people were asking for it. But people working on the main platform told me that they were building one already.

  状态更新 ：我可以构建一个供人们更新请求状态的功能。 这是一个微不足道的构建，人们正在要求它。 但是在主平台上工作的人告诉我，他们已经在构建一个。

• Websockets: I could stream new requests to the website in real time as they arrived. Combined with status updates and time cohorts, we’d get detailed information about requests as soon as they arrived.

  Websockets：当新请求到达时，我可以将其实时流式传输到网站。 结合状态更新和时间队列，我们​​将在请求到达后立即获得有关请求的详细信息。

I had a lot of competing ideas, and I wasn’t sure what could be implemented in time to be useful.

我有很多相互竞争的想法，但我不确定什么可以及时实施才有用。

结语 (Wrap-up)

The API endpoint returned the next day. It was paginated now, returning 300 requests at a time. I quickly wrote a script to download and maintain a local cache using the new API.

API端点在第二天返回。 现在已分页，一次返回300个请求。 我Swift编写了一个脚本，以使用新的API下载并维护本地缓存。

The number of calls and messages I was receiving reached a new high. Having never been employed before, this was new terrain. Devs working on the main platform were contacting me. They were working on integrating the crowdsourced data — both the urgency ratings, and the status updates that we were collecting.

我收到的电话和短信数量再创新高。 以前从未雇用过，这是新领域。 正在主要平台上工作的开发人员正在与我联系。 他们正在努力整合众包数据-紧急等级和我们正在收集的状态更新。

As the day ended, the folks on the triage groups felt a shift.

一天结束时，分流小组的人们感到了转变。

Most victims they were calling reported being rescued recently. It turns out, the rescue missions on the ground had kicked in.

他们所称的大多数受害者最近都被救出。 事实证明，地面救援任务已经开始。

This was great news. At about 5 AM, I got on a call with Nishanth. He was in touch with government officials overseeing rescue operations. We packaged data from the website and spreadsheets, and handed it over.

这是个好消息。 大约凌晨5点，我与Nishanth通话。 他与监督救援行动的政府官员保持联系。 我们打包了网站和电子表格中的数据，并将其移交给了我们。

As I write this, flood victims have been rescued and transported to relief camps. There are new challenges involving logistics between camps and aid arriving from around the country.

在我撰写本文时，洪水灾民已经获救，并被运送到救济营。 难民营之间的物流和来自全国各地的援助物资面临着新的挑战。

经验教训 (Lessons)

• Simplicity: Many people messaged me that they liked my site. I’m no designer, but my decision to keep UX simple helped people get on board quicker.

  简洁性 ：许多人告诉我他们喜欢我的网站。 我不是设计师，但我决定保持UX简单易行，这有助于人们更快地上手。

• Computing is cheap: All of this was hosted on Google Cloud Platform. It cost me less than a dollar, covered within my free tier credits. If I had known how cheap it would be, I’d have built an application heavy on the backend.

  计算很便宜：所有这些都托管在Google Cloud Platform上。 我花了不到一美元，涵盖了我的免费等级积分。 如果我知道它会有多便宜，那我会在后端构建一个繁重的应用程序。

• Pivoting: I wish I’d completely pivoted to a detailed triage platform. The volunteers came up with a makeshift solution, but in hindsight, I would rather have shipped the platform with those features.

  透视 ：我希望我能完全转向一个详细的分类平台。 志愿者提出了一个临时解决方案，但是事后看来，我宁愿为平台提供这些功能。

• Networks are important: People wanted to help. The initial group of 30 grew over two days to a group of 230, as people called upon their friends and acquaintances. Folks joined in from Kerala, the rest of India, and from around the world.

  网络很重要 ：人们想提供帮助。 当人们拜访朋友和熟人时，最初的30人小组在两天内成长为230人。 来自喀拉拉邦，印度其他地区和世界各地的人们也加入了进来。

I’ve met many amazing people. I’ve learnt a lot, technical and otherwise. Through all this, the most incredible feeling was that of being on the same page as thousands of other people.

我遇到了很多很棒的人。 我学到了很多东西，无论是技术方面还是其他方面。 通过所有这些，最不可思议的感觉是与成千上万的其他人在同一个页面上。

If my work merits an article, the project I was a part of deserves a book.

如果我的工作值得写一篇文章，那我参与的项目就值得一本书。

As for me, I’m getting in contact with people involved in disaster response to learn from their experience and expertise.

对于我来说，我正在与参与灾难响应的人们联系，以从他们的经验和专业知识中学习。

A bit more about me: I’m on a gap year to delve into crypto economics. I picked up web development skills back in 10th grade, while hosting a hackathon at school.

关于我的更多信息：我在空白的一年里要研究加密经济学。 我在10年级时学习了Web开发技能，同时在学校举办了黑客马拉松。

I’m considering developing a project based on this, but with many other insights that my friends and I have had since.

我正在考虑基于此开发一个项目，但此后我和我的朋友们有了许多其他见解。

• Ann Thomas, a volunteer from the triage groups, wrote about her experience here

  分流小组的志愿者安·托马斯(Ann Thomas) 在这里写下了她的经历

• Thanks to Dr. Harikrishnan, Dr. Nishanth, Ajit Chandran, Prasad Pillai, who helped organize the triage groups

  感谢Harikrishnan博士，Nishanth博士，Ajit Chandran，Prasad Pillai的帮助，组织了分类小组

翻译自: https://www.freecodecamp.org/news/how-i-used-crowdsourcing-to-help-kerala-floods-rescue-operations-12dc97c9a24b/