infras

Month: 2021-05

2021-05-02

tofus 09:56:43
@terry.f.wang has joined the channel

2021-05-16

patcon 06:05:44
hi all! does g0v.tw run a shared link shortener?
patcon 06:06:08
and i recall au manages g0v.link domain, yes?
patcon 06:09:48
am thinking on how helpful it’s been to run a lightweight shortener in some other spaces, a bit like this: https://link.hypha.coop/foo

It’s editable via CSV in github (or a GSheet, depending on desired level of accessibility)
https://link.hypha.coop/shortlinks

GitHub

hyphacoop/configurations

Contribute to hyphacoop/configurations development by creating an account on GitHub.

patcon 06:09:50
It’s nice because ppl just need to remember the “slug” to find all the important places/docs: g0v.link/foo. Would anything like this be helpful? (I tend to run it on rebrandly to start, so it’s minimal self-hosted infra to maintain)
chihao 07:39:10
@patcon don’t know if there’s already one but could be great to have one as long as it’s open source and collaborative?
patcon 09:21:25
Thanks @chihao! I'm working on getting one going for link.g0v.network (where a polis-related initiative is being hosted), so I can demo that and see if it looks good enough to reproduce for g0v.link :) :tada:
🙌 1

2021-05-17

irvin 00:05:11
@irvin has left the channel

2021-05-19

caasi 22:41:12
真的要搬家再來申請 https://libera.chat/chanreg

Libera Chat

Channel registration

A next-generation IRC network for FOSS projects collaboration!

🤔 2

2021-05-20

Guo-Jim 01:17:58
@guo-jim has left the channel
Guo-Jim 07:49:57
@guo-jim has joined the channel
游士鋒 12:34:28
@sfyou614 has joined the channel

2021-05-22

caasi 15:54:52
g0v IRC 現況 https://g0v.hackmd.io/@YMAapC0RTZaurbgCZtn72w/SJn3lVIFd

HackMD

g0v IRC 現況 - HackMD

# g0v IRC 現況 現在 g0v 主要的 IRC 頻道是 #<http://g0v.tw|g0v.tw> ,位在 freenode 這個 IRC 網路上。 ## 待處理事項 ### 是否取回 freenode 上的 IR

🙌 1 👍 1 1
tofus 16:06:48
這邊有Keedos的流程圖喔!
https://whimsical.com/Hveq7hkUWbbU93w6zq9kPz
2

2021-05-24

caasi 15:16:07
剛剛取回了 g0v IRC 頻道的 founder 權限,然後發現 freenode 也有 channel group ,下班再來更新資訊
6 1 1 2
caasi 18:22:28
• 在 freenode 管理員 t-42 的協助下,拿到 IRC 頻道的 founder 權限
• 之後打算也把 founder 權限設給 gugod, kcwu 和 yhsiang (不要的話講一聲
• freenode 也有 channel grouping 機制,一樣要聯絡管理員來申請 https://freenode.net/groupreg

freenode.net

Group registration - freenode

<http://freenode.net|freenode.net> - Supporting Free and Open Source Software Communities since 1998

kcwu 18:24:52
(小聲說, 我在考慮放棄使用 g0v irc) 一方面是因為有時兩邊的訊息無法很好的轉換傳遞, 一方面是 irc 只有 general channel
superbil 20:32:20
若是用 grouping 的話,可以開系列 `g0v-infras` 這樣呀~ 就不會只有 general
caasi 22:50:42
若大家決定放棄 IRC ,我也 OK ,討論一下讓子彈飛一會兒~

2021-05-26

gugod 22:51:58
用 IRC 或不用我是沒什麼意見或堅持。

我甚至覺得不必所有個討論頻道都開在這個 Slack workspace 內。如有有專案討論要開在 IRC 或 Matrix 也不錯 (雖然會讓一些事情比較難辦一些) 。基本上維持公開,有紀錄 (logbot)可查、CoC 與目標和 g0v 的有相容就好。
3 4

2021-05-27

pm5 08:40:35
這個原則也可以適用於幫忙設 matterbridge 的前提(相關討論在 #bridge):
1. 公開
2. 有紀錄可查
3. CoC
4. 符合 g0v 精神(「相容」是這個意思(對過去與未來相容)?)
gugod 09:14:03
> CoC 與目標和 g0v 的有相容
我的原意是:“CoC 相容” 且 “目標相容”
不過「目標相容」好像十分廣泛。
isabelhou 09:43:59
g0v宣言
1
chewei 09:55:04
Slack 目前開始有 Admins 與治理機制

可能這類 bridged 的服務,也要考慮,我建議是先有 Admins 與機制,並說明 bridged 服務有什麼風險,特別是成員資料送出去這樣的狀況

舉例來說 zulipchat 在剛才之前,直接是把 slack 這邊的暱稱與註冊 email 全部公開連 guest 都可以查看,一來是 slack 也不允許的事情,反而在 bridged 的服務卻被允許,也無人知曉監管,然後 想找 Admins 卻不曉得是誰,現在正在釐清這個匯出且公開 成員暱稱-註冊email 的操作發生時間點(可能是三年前)與操作者 #bridge
Image from iOS
ronnywang 10:14:25
slack 的 export 檔本身好像不包含 email 資訊,不知道 zulipchat 那邊是怎麼抓到 email 的?
要請 slack admins 幫忙確認囉
應該是好幾年前我有用 slack 內建的 export 功能提供匯出檔給 @kevinliao,但我印象中預設的 export 檔是沒有 email 的,我剛剛也有試著匯出過一次裡面沒有(https://g0v-slack-archive.g0v.ronny.tw/ 裡面也沒有 email 資訊)
看來我也是自動變成 zulip 那邊的 org owner,如果需要看什麼機密文件(?)的話可能我的畫面上有的看
😵 4 💔 3 ⚠️ 4
chewei 10:19:46
像是與 Telegram bridged 會有這樣的狀況嗎?

還有誰 於何時 接上了哪個服務呢?😵
chewei 10:58:07
是否要來確認 Full Slack Export 是什麼..
https://g0v-tw.slack.com/archives/C01SHPD80UD/p1622083639017300?thread_ts=1622034205.006500&channel=C01SHPD80UD&message_ts=1622083639.017300

Roles and account information are imported over as part of the full Slack export.

chihao 16:11:28
export 任何資料之前,不用有某種公告和確認嗎?
ronnywang 16:15:44
當初執行 export 的應該是我,我先道歉當時未進行公告,但我印象中我當時有確認過 export 檔裡面並不包含 private channel 資料以及個人隱私資料,只是我這邊已經沒有保留當時的匯出檔了
chihao 16:20:42
原來如此
chihao 16:20:59
ronny ++ 感謝說明
chihao 16:21:26
這是個有趣的案例呢 😛
gugod 16:30:33
web ui 上看來 zulip 那邊大部分使用者的建立日期是2018/12/17
gugod 16:30:44
那可能是實際執行匯入的日期
ronnywang 16:31:14
g0v-slack-archive 的 import script 也是在 2018 年 10 月寫的,可能也是用同一份 export 檔匯入的,但是我剛檢查 g0v-slack-archive 裡面的資料並不包含 email 個資
🙌 1
ronnywang 16:31:20
https://github.com/ronnywang/g0v-slack-archive/blob/master/webdata/scripts/import-directory.php

webdata/scripts/import-directory.php

``` &lt;?php include(__DIR__ . '/../init.inc.php'); $dir = $_SERVER['argv'][1]; if (!$dir) { throw new Exception("Usage: php import-directory.php [slack export directory]"); } else if (!is_dir($dir)) { throw new Exception("{$dir} is not a directory"); } try { Message::createTable(); Channel::createTable(); User::createTable(); ChannelUser::createTable(); } catch (Exception $e) { } // import channels if (!file_exists($dir . '/channels.json')) { throw new Exception("channels.json not found in {$dir}"); } $channel_info = json_decode(file_get_contents($dir . '/channels.json')); $channel_id_to_name = array(); $channel_name_to_id = array(); $db = Message::getDb(); $max_ts = 0; Message::getDb()-&gt;query("CREATE TEMP TABLE message_temp (LIKE message)"); $terms = array(); $c = 0; foreach ($channel_info as $channel) { try { $channel_id_to_name[$channel-&gt;id] = $channel-&gt;name; $channel_name_to_id[$channel-&gt;name] = $channel-&gt;id; Channel::insert(array( 'id' =&gt; $channel-&gt;id, 'name' =&gt; $channel-&gt;name, 'data' =&gt; json_encode($channel), )); } catch (Pix_Table_DuplicateException $e) { if (Channel::find($channel-&gt;id)-&gt;name != $channel-&gt;name) { // TODO: 看哪邊新... //throw new Exception("id = {$channel-&gt;id} 的頻道名稱是 " . Channel::find($channel-&gt;id)-&gt;name . ", 與 {$channel-&gt;name} 不吻合"); } } foreach (glob($dir . '/' . $channel-&gt;name . '/*.json') as $message_json) { $messages = json_decode(file_get_contents($message_json)); foreach ($messages as $message) { $max_ts = max($max_ts, $message-&gt;ts); $terms[] = sprintf("(%lf,%s,%s)", floatval($message-&gt;ts), $db-&gt;quoteWithColumn('data', $channel_name_to_id[$channel-&gt;name]), $db-&gt;quoteWithColumn('data', json_encode($message)) ); $c ++; if (count($terms) &gt;= 1000) { $db-&gt;query("INSERT INTO message_temp (ts, channel_id, data) VALUES " . implode(',', $terms)); $terms = array(); error_log("insert {$c} records"); } } } } if (count($terms)) { $db-&gt;query("INSERT INTO message_temp (ts, channel_id, data) VALUES " . implode(',', $terms)); $terms = array(); } $sql = "UPDATE message SET data = message_temp.data FROM message_temp WHERE message.ts = message_temp.ts AND message.channel_id= message_temp.channel_id AND (message.data)::text != (message_temp.data)::text RETURNING message.ts"; $res = $db-&gt;query($sql); $u = 0; while ($row = $res-&gt;fetch_array()) { $u ++; } error_log("一共變更 {$u} 筆訊息"); $sql = "INSERT INTO message SELECT * FROM message_temp WHERE (ts, channel_id) IN (SELECT ts, channel_id FROM message_temp EXCEPT SELECT ts, channel_id FROM message) RETURNING message.ts"; $res = $db-&gt;query($sql); $insert = 0; while ($row = $res-&gt;fetch_array()) { $insert ++; } error_log("一共新增 {$insert} 訊息"); foreach ($channel_info as $channel) { $c = Channel::find($channel-&gt;id); if ($max_ts &gt; $c-&gt;last_fetched_at) { $c-&gt;update(array( 'last_fetched_at' =&gt; $max_ts, 'last_updated_at' =&gt; $max_ts, )); } } ```

chihao 16:47:50
Zulip 事件紀錄,可以用在檢討(?)和治理機制討論 https://g0v.hackmd.io/KCnJ7hgbRke19j_-UfYsrQ

g0v.hackmd.io

Zulip 事件 - HackMD

@kevinliao 這邊
kcjl 似乎也在增加內容 ++
我跟 Zulip 的通訊完全上傳到 Slack 了。
我把我個人的電子郵件,名字刪掉了。也把 Zulip 員工的名字也刪掉了
也把 API Key刪掉了
@kevinliao 不太好讀,建議每一封 email 一個 `##` h2 如何?
先放那裡帶一會兒在整理我先寫一些其他的必要的東西
@ronnywang API Key 現在還有人在用嗎?
可以把他直接刪除掉把
API Key 目前已經不能使用了
應該是上週前不能使用的
是因為什麼原因而被禁止的? 想要把它放在 報告裡
因為上週三開始 #g0v-slack 在討論 slack 治理機制,然後我看到 Slack API Tester 這個 app 我覺得應該沒有人在使用,我就把他刪除掉了,應該就會影響到當初的 API Key
了解,謝謝!
1 👍 1
kjcl 16:48:58
@kevinliao has joined the channel
kjcl 16:50:24
我犯了大錯了。。。那時候我把 API key 直接發給他們了。不好意思大家。我把我全部跟他們的 e-mail 記錄放到共筆
無法完全看懂技術細節,但感謝發現立刻補救和開誠布公共筆。尤其是@kevinliao 提供了email紀錄。也許可以約個時間線上討論一下。
非常願意參與檢討會議。我也可以想辦法解讀一下技術細節
任何問題先歡迎在共筆裡以下的問答部分詢問。我會儘快回答
英翻中完畢。拜託修正!
kjcl 16:50:58
他們應該是透過這個方式把 email 帶進 Zulip 的
🥲 1
ronnywang 17:02:17
API key 好像不是我提供的,應該是 @kevinliao 自行產生的,當初 slack 的設定是人人都可以自行申請 API key ,去年才改成要 admin 同意才能申請
image.png
1 👍 2
ronnywang 17:02:49
不過 slack 這點還真奇怪,users:read.email 的權限一般使用者也可以取得?這個我確認一下
🤔 1
clkao 17:58:08
security bounty! 發了! (誤)
4 5 🎯 2 1
kjcl 18:17:19
英翻中完畢。拜託修正!
👍 2
ronnywang 18:19:43
image.png
1
ronnywang 18:20:19
好像關不掉 api tokens 瀏覽 email 的權限
好。我補充一下工筆
isabelhou 18:21:53
要晚上聊一下還是明天?
我都可以。如果等明天的話也許可以找 Zulip 團體的工程師參與
pm5 18:43:26
我想也釐清一下這是 infra & slack admin 的事情而不是 jothon 的事情
1 👍 2
pm5 18:44:39
因為似乎會讓人覺得 slack 是 jothon 管理的,但至少以我的理解的話不是這個樣子
1 👍 4
isabelhou 19:06:07
因為基礎松目前是揪松主揪,才剛討論slack治理機制,所以揪松算在坑內。但slack另有管理員這是一定要澄清的。#g0v-slack
👍 4 🕳️ 5 1
pm5 19:23:03
題外話發 security bounty +1
pm5 19:30:01
我覺得這樣看起來是 @kevinliao 發現了一個 bug 啊,應該要表揚一下吧?
🙌 4 🎉 2 😅 3 🐛 1
kjcl 20:07:30
討論的結果好像是
1. 應該deactivate Zulip instance
2. 應該去找 Zulip 支援團隊的確認數據已經刪除掉。
3. 我們重新做一個沒有 import 的 Zulip service 然後開通 bridge
在我刪除之前,有沒有 Zulip 上面為了檢討報告而還需要的資料? 我個人覺得沒有了

So it appears, from the discussion, next steps to mitigate:
1. Deactivate the Zulip instance
2. Confirm with the Zulip team that the data from the instance was deleted.
3. Kevin will set up a new Zulip instance with open source plan, and we will set up a bridge with *no data import**
Is there any data on the instance I need to move off before deleting?
2 1
Chris Bobbe 20:08:10
@csbobbe has joined the channel
chihao 20:22:32
kjcl ++ 在 3 之前我覺得要先把架 bridge 的治理機制架起來,然後再架 bridge 本人 😛
1
kjcl 20:23:05
同意
kjcl 20:23:29
設治理機制的治理機制是什麼? 😛
你已經開啟一個機制了XD
我以為現在還是在事件後續處理?— 「發生時間的處理方式」技術上也是個機制沒錯,但我想要有「怎麼決定可以蓋一座橋」的機制 XD
許願是錯誤示範,先道歉 XD
我指的開啟是問「設治理機制的治理機制是什麼?」這句話。事件後續處理和機制討論不衝突吧。
完全不衝突,而且是機制的一部分,如上所述 😛
kjcl 20:44:15
Screenshot from 2021-05-27 20-43-51.png

2021-05-28

kjcl 15:15:55
嗨大家,開了一個 whenisgood 決定檢討會議時間! http://whenisgood.net/9h55m9x

Chris 願意從加州跟我們大家視訊,代表他自己(而不是他的公司)了解一下以後流程能夠怎麼改善。因此我設的時間都是台灣早上,美國西岸傍晚。如果大家無法參與的話,我在儘量找其他時間

Hi everyone, I've started a whenisgood to settle on a time for incident review.
@csbobbe has agreed to join us from California (just as himself a g0v participant, not representing his company) to understand how processes can be improved in the future. As such, I've set times to be evenings on the American West Coast, and mornings in Taiwan. If none of these times work, please let me know.

whenisgood.net

WhenIsGood: g0v Slack/Zulip 事件檢討會議

Plan the time to have your meeting or event by co-ordinating availability with all the particpants using this fuss-free online tool.

Chris Bobbe 2021-05-29 02:34:05
> just as himself a g0v participant, not representing his company
I think my role can appropriately be a mixture of the two. 🙂 I'm a Zulip engineer (I started on January 6, 2020), and naturally that influenced my incident response, which will be relevant to the discussion. For example, when privacy concerns were raised, I knew immediately that it was possible for admins to set email visibility to "nobody".

The important point I raised with @kevinliao is that I have never been directly involved in our data import support operations and I'm not well-positioned to speak authoritatively on Zulip's practices there. (I work almost exclusively on the mobile apps.) I know that https://github.com/zulip/zulip/issues/18622 is a high priority, and that the engineers who work in this area are discussing the incident. I'm hoping to collect other g0vers' feedback on the incident, as well as any other ideas about how we can improve Zulip. (g0vers can also contact support@zulip.com or post on Zulip's community server).

One important message I'd like to relay from the Zulip team is that we apologize for not discovering and fixing https://github.com/zulip/zulip/issues/18622 sooner.

Also, I personally feel bad that people's data didn't go the way they expected, and it occurs to me that my own email address might have been affected if things had gone just a little differently in December of 2018. At that time, @kevinliao knew I was a big fan of Zulip, even though I didn't work there, and he knew I had a connection to Taiwan. By chance, he didn't introduce me to g0v and ask me to join the Slack at that time, so my email address could never have been leaked. So, in keeping the privacy of my data, I consider myself lucky. I know that many of you weren't lucky, and I take that as a serious reminder to reflect on how to advance the cause of privacy in Zulip and in the world.

While I expect we may gather useful action items throughout the meeting, my hope is that they'll arise organically from a collaborative discussion where the purpose is to learn more about processes and systems, in situations where honest people were doing their best to use them. I would gently suggest that going straight to bullet-pointed action items might direct our curiosity away from that kind of exploration. And, given my position on the Zulip team that I mentioned above, please know that I won't have all the answers myself, and I'll be glad to relay questions to the team. 🙂

As a heads-up, I'll be absent this weekend for a long-planned vacation and won't be back until my Tuesday morning.
Chris Bobbe 2021-05-29 02:36:17
> 代表他自己(而不是他的公司)
我想我的角色大概是兩種都有。 🙂 我是2020年1月6日時加入Zulip的工程師,這當然影響了我對此事件的反應,而這點我稍後會提到。例如,當有人提出對隱私的疑慮時,我當下便知道管理人員是可以將 email能見度(Email visibility)設定成沒人能看見(nobody)。

我跟 @kevinliao 提到的重點是,我從未直接參與過我們支援資料輸入運作的部分,因此我也不適合以官方的角度來討論 Zulip 這部分的作法。(我基本上只負責行動應用程式的部分。)我知道 https://github.com/zulip/zulip/issues/18622 是個高優先權的案子,而相關領域的工程師也正在討論此事件。我希望能收集 g0v 使用者對此事件的回饋,還有任何其他能幫助我們改善 Zulip 的想法。(g0v 使用者也能寄信至 support@zulip.com 或在 Zulip's community server 上發文。)

我想轉達 Zulip 團隊的一則重要訊息,那就是我們很抱歉沒有更早發現並處理 https://github.com/zulip/zulip/issues/18622 這個案子。

此外,我個人很抱歉大家的資料並沒有依照個人預期的方式處理。我意識到,2018年12月時若處理事情的方式有些許不同,我自己的email也可能受到影響。 @kevinliao 知道,雖然當時我不在 Zulip 工作,但我已經是 Zulip 的大粉絲了。 @kclj也知道我跟台灣的關係(我的配偶是台灣人,也是他幫翻譯的 😆)。幸好他那時沒有告訴我 g0v 也沒有邀請我加入,所以我的 email 才沒有被公開。因此,我覺得我很幸運能保護我的個資。我知道很多人沒有那麼幸運,而我也將此視為重要的提醒,反思如何在 Zulip 和世界上增進隱私權的推廣。

雖然我預計在會議中能收集到有用的行動項目,但我希望這些項目是在合作討論中自然產生的。合作討論的目的為是要更了解這些程序和系統,並知道善意人士是盡其所能地在使用這些程序和系統。我真誠地建議,不要直接條列出行動項目,因為如此一來可能會使我們的討論失去那樣探索的過程。另外,根據上述我在 Zulip 團隊的角色,請諒解我自己可能無法回答所有問題,但我很樂意幫忙將問題轉達給我的團隊。 🙂

對了,美國這個周末有三天連假,因此我要台灣時間周二晚上後才會有空。
3 2

2021-05-29

Chris Bobbe 02:34:05
> just as himself a g0v participant, not representing his company
I think my role can appropriately be a mixture of the two. 🙂 I'm a Zulip engineer (I started on January 6, 2020), and naturally that influenced my incident response, which will be relevant to the discussion. For example, when privacy concerns were raised, I knew immediately that it was possible for admins to set email visibility to "nobody".

The important point I raised with @kevinliao is that I have never been directly involved in our data import support operations and I'm not well-positioned to speak authoritatively on Zulip's practices there. (I work almost exclusively on the mobile apps.) I know that https://github.com/zulip/zulip/issues/18622 is a high priority, and that the engineers who work in this area are discussing the incident. I'm hoping to collect other g0vers' feedback on the incident, as well as any other ideas about how we can improve Zulip. (g0vers can also contact support@zulip.com or post on Zulip's community server).

One important message I'd like to relay from the Zulip team is that we apologize for not discovering and fixing https://github.com/zulip/zulip/issues/18622 sooner.

Also, I personally feel bad that people's data didn't go the way they expected, and it occurs to me that my own email address might have been affected if things had gone just a little differently in December of 2018. At that time, @kevinliao knew I was a big fan of Zulip, even though I didn't work there, and he knew I had a connection to Taiwan. By chance, he didn't introduce me to g0v and ask me to join the Slack at that time, so my email address could never have been leaked. So, in keeping the privacy of my data, I consider myself lucky. I know that many of you weren't lucky, and I take that as a serious reminder to reflect on how to advance the cause of privacy in Zulip and in the world.

While I expect we may gather useful action items throughout the meeting, my hope is that they'll arise organically from a collaborative discussion where the purpose is to learn more about processes and systems, in situations where honest people were doing their best to use them. I would gently suggest that going straight to bullet-pointed action items might direct our curiosity away from that kind of exploration. And, given my position on the Zulip team that I mentioned above, please know that I won't have all the answers myself, and I'll be glad to relay questions to the team. 🙂

As a heads-up, I'll be absent this weekend for a long-planned vacation and won't be back until my Tuesday morning.

#18622 Slack import should respect Slack's counterpart of EMAIL_ADDRESS_VISIBILITY.

When <https://zulip.com/help/import-from-slack|importing data from Slack>, Zulip should respect the <https://slack.com/help/articles/228020667-Manage-email-display|Slack workspace's setting> of who can see email addresses, instead of defaulting to showing email addresses to any user (that default setting is applied to all projects, with or without a Slack import; see the <https://g0v.zulipchat.com/help/restrict-visibility-of-email-addresses#restrict-visibility-of-email-addresses_1|doc> on the setting). The setting should be applied before any users are imported. A large open-source org reports that the delay in getting the right setting applied was multiple years; the Zulip Cloud org was created from a Slack import, there was a long period of inactivity, and then when it regained activity, users saw email addresses they considered private and an owner applied the "nobody" setting.

❤️ 2
Chris Bobbe 02:36:17
> 代表他自己(而不是他的公司)
我想我的角色大概是兩種都有。 🙂 我是2020年1月6日時加入Zulip的工程師,這當然影響了我對此事件的反應,而這點我稍後會提到。例如,當有人提出對隱私的疑慮時,我當下便知道管理人員是可以將 email能見度(Email visibility)設定成沒人能看見(nobody)。

我跟 @kevinliao 提到的重點是,我從未直接參與過我們支援資料輸入運作的部分,因此我也不適合以官方的角度來討論 Zulip 這部分的作法。(我基本上只負責行動應用程式的部分。)我知道 https://github.com/zulip/zulip/issues/18622 是個高優先權的案子,而相關領域的工程師也正在討論此事件。我希望能收集 g0v 使用者對此事件的回饋,還有任何其他能幫助我們改善 Zulip 的想法。(g0v 使用者也能寄信至 support@zulip.com 或在 Zulip's community server 上發文。)

我想轉達 Zulip 團隊的一則重要訊息,那就是我們很抱歉沒有更早發現並處理 https://github.com/zulip/zulip/issues/18622 這個案子。

此外,我個人很抱歉大家的資料並沒有依照個人預期的方式處理。我意識到,2018年12月時若處理事情的方式有些許不同,我自己的email也可能受到影響。 @kevinliao 知道,雖然當時我不在 Zulip 工作,但我已經是 Zulip 的大粉絲了。 @kclj也知道我跟台灣的關係(我的配偶是台灣人,也是他幫翻譯的 😆)。幸好他那時沒有告訴我 g0v 也沒有邀請我加入,所以我的 email 才沒有被公開。因此,我覺得我很幸運能保護我的個資。我知道很多人沒有那麼幸運,而我也將此視為重要的提醒,反思如何在 Zulip 和世界上增進隱私權的推廣。

雖然我預計在會議中能收集到有用的行動項目,但我希望這些項目是在合作討論中自然產生的。合作討論的目的為是要更了解這些程序和系統,並知道善意人士是盡其所能地在使用這些程序和系統。我真誠地建議,不要直接條列出行動項目,因為如此一來可能會使我們的討論失去那樣探索的過程。另外,根據上述我在 Zulip 團隊的角色,請諒解我自己可能無法回答所有問題,但我很樂意幫忙將問題轉達給我的團隊。 🙂

對了,美國這個周末有三天連假,因此我要台灣時間周二晚上後才會有空。
❤️ 5
pinshan.yuan 19:01:58
@pinshan.yuan has joined the channel