我們要寫到多強力？如果特別說「不要被特別廠商綁定」，很可能這個準則沒有辦法一下子落實成原則，因為現狀就是有被廠商綁定，所以我們只能講是「朝向儘量服務永續」，然後「儘量開啟多方合作的可能性」等等，這個才會變成比較能夠落實。
這樣寫沒有人看得懂（笑）。
我們有「不特定於廠商」的專有名詞嗎？像我們說open document是一個vendor-neutral的技術？
老師這邊講的是vendor neutral，但是這邊的服務永續經營，如何把它轉換成vendor neutral，還是請團隊再想一想。
我們最小可行方案，就是把「經營」兩個字想辦法改掉，或者是變成同義字，也許「達到服務的永續」，這樣就可以了。
多一點的可行方案，是「永續」後面，再加開啟更多合作的夥伴、可能性等等，字樣就麻煩團隊幫忙。
請說。
……這個在「open by default」（準則8）。
所以簡單來講，你覺得完整性這邊，可能還包含達到公共利益等等的這一些部分。
不過，我想這部分應該接近不證自明，因為我們在做的是政府服務，所以一定是為了公益，而不是特定廠商的利益。如果有的話，那是個案。
我同意啊！公益性是非常重要，但如果要特別講公益性的話，那個是前言層級的東西，不是到我們東西都已經規劃到一半都要做的「準則5」來寫的。
前言包含公共利益或者是社會問題之類的，那個就請團隊再參酌，大概沒有辦法放到「準則5」。
大家看對於「準則5」有沒有意見？沒有的話就往下走。
「準則6：評估採用工具與系統」，目標是要符合各階段的需求，做法是為了提高效率與持續精進，機關要在各個階段，選用適當的工具系統與基礎設施。
這裡很有意思的是，我看到的版本是「選用」與「宜包含」中間沒有逗點或之類的，我不是很確定這個文意，意思應該是適當的這一些東西，然後「宜包含」，是不是？這一些東西「宜包含」以下的這四個考量，是不是這個意思？可能要有一個逗點之類的。
「評估其風險與限制而避免受限於契約而阻礙精進，評估選用穩定性高的開源工具與系統，考量支援常用的系統環境」，目的同樣是永續支援。
看大家有沒有什麼想法？這是滿連貫的，這四個確實我們終於看到唯一負面的字，就是「避免」，所以修到非常弱，但畢竟是整個準則裡面極少數負面的字，看大家有沒有什麼想法？
我自己的想法是覺得這個後面的「避免」真的太抽象了，大概沒有人知道是vendor neutral的意思，這可能要在配套方案或者是check list裡面展開成更有約束力的文字，但在這邊是比較正能量。
看大家有沒有意見？
「準則7：健全資安及隱私」，這邊講的是保護資訊安全、個人隱私，但是又不犧牲服務便利性，等於承認中間本來就有一些緊張關係，才會用「兼顧」二字。
所以為了要兼顧這兩個比較緊張的東西，所以機關要定期進行風險評估跟資訊系統檢查是採取適當的防護措施，讓使用者可以安心，看大家有沒有什麼想法，這一點我覺得是比較標準的，比較看不出目前沒有做哪一些東西，但我不知道大家的想法是什麼。
所以具體建議是，準則7是兼顧資安隱私與便利性之類的，大家如果不反對的話……因為如果不這樣子寫的話，其實內文不用這樣寫。
如果大家ok的話，這裡就不是健全，因為我們說「健全資安」是沒有問題的，但是「健全隱私」就開始有一點怪，如果說這個動詞是特別這三者要兼顧，這個也可以避免機關常常把廠商跟隱私混淆的問題，等於是我們三個併舉，並不是說前兩個是一個方向，後面是一個方向，這個是三個方向要兼顧，如果這樣可以的話，我們就用三個並列的方法處理，就是「兼顧資安隱私及便利性」。
「準則8：以開放為優先」，目的是要降低提供服務總成本，做法是引進民間創新的能量，符合開放標準及重複使用。
具體的做法是要透過開放資料與開放源碼來激勵民間創新優化服務，接下來還要採用符合開放標準且通過測試，可重複使用的共通平台及元件，這樣就可以快速精進服務，因此節省服務開發時間與總成本。
這邊用「開放源碼」，前面用「開源」，是有什麼動機嗎？或者我們全部都用「開放源碼」。
我記得這邊有講開源，大家看到「開源」就知道是開放源碼的意思，我具體建議是不是就展開成「開放源碼」，就是選用「穩定性高之開放源碼工具系統」，不然爭取到多一點的預算也叫做「開源」（笑），也就是充分的資源（笑）。
看大家有沒有什麼想法？我看前幾場逐字稿裡面有激烈討論這一段，所以這個好像已經預先收斂過了，我覺得還算滿不錯的，也就是把資料、源碼、標準及共通性的四個，其實只有部分互相重疊的東西，都放在同一個準則裡面。
如果大家都ok的話，就繼續往下走。
「準則9：測試與部署服務」。
那現在服務已經要上線了，所以要提供與實際運作一致的環境測試，不是在空想的虛擬狀況裡面測試，而且這個測試儘量不要手動測試，要作CI，也就是持續整合、持續發布。
而這一個部分的重點是：縮短測試與部署的時程，進行end to end的測試，還有易用性測試。這個「等」的意思是還有更多的測試要做。
接下來要確保各種常見的東西都可以有存取服務，但是講到「瀏覽器」，好像是web-based的服務。但是anyway我不是特別在意這一點，只是說我們這個涵蓋的範圍包含不是web-based的也在裡面。
我不知道你要用什麼，通常我們會說user agent，但在這邊就已經過於抽象，因此通常留載具系統，可能就可以了；或者「及環境」等等，如果講瀏覽器的話，等於是綁定web-based，然後還有迭代的服務，這部分跟剛剛的迭代是一樣的原則，看大家有沒有什麼想法？這個講的大概是軟體工程。
因為這個特別是在講軟體的部分。
鄧老師跟另外三位朋友想說，「準則9」的標題比較沒有特色。確實，我們沒有辦法想像不測試，或者不在一個跟現實生活類似的環境去進行模擬，我們就上線，這是很難想像的。
因此建議把自動化、縮短時程、更新服務、持續測試直接加到主題當中，不然這個主題好像沒有講，而具體建議是「持續測試服務與快速部署更新」。
這裡講的是把「持續」、「快速」加入，也就是把「服務」替換成「更新」，大家有沒有什麼想法？
我想就是放在自動化前面，「持續」是要做的第二件事，要測試也要持續，最後要自動化。
我自己覺得「持續」放前面是沒有什麼問題，至於接下來「快速」跟「更新」，是要用「快速」或「更新」，又或者是「自動化」，看大家有什麼想法？
如果是手動的話，沒有辦法快速部署，對不對？如果要把「自動化」拿掉的話，要把「快速」拿掉。
ok。
所以你的想法是，我們可以自動化來部署，但是我們部署前的測試，不一定要全自動化，是不是這個意思？就是自動化的scope只到部署而已，看大家有沒有什麼意見？
如果全部測試都要自動化，是滿強烈的，而且我們前面已經講了「宜縮短」，所以這邊其實有盡可能縮短的意思。
如果大家不反對的話，我們可能是說「並以自動化的部署方式迭代地進行服務」，我想「部署」一定要自動化，人拿一個光碟去部署，可能說不過去，所以「自動化」就把它縮限範圍了。
因為前面已經有全面測試了，我們就把前面刪掉，就是自動化部署，因為我們要儘量縮短時程，因此裡面自動化的部分要儘量多，但不表示是全面的自動化。
「持續測試」大家有沒有什麼意見？如果我們把標題改成「持續測試與快速部署服務」，我覺得「更新」好像就不用了；好，我們就「持續測試與快速部署服務」。
我們繼續。
