Google Summer of Code

Google 代碼之夏活動已展開數天，那我就來介紹一下我所關心的開源軟體專案列出的規則吧！

在2012年4月23日前滿 18 歲或以上的學生 (必須是政府認可的高等教育學生) 都可以參加。 學生資格要求：http://google-melange.appspot.com/document/show/gsoc_program/google/gsoc2012/faqs#student_eligibility

Google 提供每位被接受的學生開發者 5500 USD 的獎金：5000 USD 給學生，500 USD 給指導的組織。

活動辦法詳情請見本年度 Google Summer of Code 首頁。

Fedora 專案

學生申請日已從3月26日 1900 UTC 開始 [1]。
有興趣的同學可以開始提交申請 (提案) 給 Fedora 專案與 google-melange。

請確認您在截止日4月6日 1900 UTC 之前完成下列程序。
請不要等到最後一刻才開始動作，遲交的提案不會被 gsoc 活動管理員或 Fedora 專案接受。

請完成給 Fedora 專案的提案 [2] 繳交動作，你可以在 wiki [3] 找到詳細指引；每個提案同時也須提交給 google-melange.com 。(請註冊活動，如果你還沒做的話) 你應該在 wiki [4] 上建立你的提案專頁，然後將連結寄送給 summer-coding 郵遞清單。一位學生可以提交一個以上的提案 [5]，但請銘記質比量更重要。

提案申請應該參考範本來撰寫 [6]。每個申請範本上的問題都要回答。如果你有任何重要且與提案相關的資訊，但申請範本中的問題沒提到，請隨意補充。但請一定要確保申請範本上的問題都有回答過了。

如果有不清楚的地方，請聯絡 Buddhika Kurera [bckurera AT fedoraproject.org] 或管理員或你的導師 (mentor)。此外，請在 summer-coding 郵遞清單以及 GSOC 2012 wiki 頁面 [7] 上保持聯絡，重要的通知會轉送到該清單/顯示在該 wiki 頁面上。

如果想知道 Fedora 目前對於 Google Summer of Code 的點子有哪些，請見 Summer Coding Ideal for 2012 ，你可以找到適合你的點子，並從頁面上提供的資訊與負責的導師聯絡。

Happy Summer Coding !!!

LibreOffice

LibreOffice 是個許多志工與受雇開發者一起合作的專案。不管你是貢獻給 LibreOffice 的公司其員工，或是以你自身的身份貢獻 LibreOffice，我們都會以相同方式來處理；因此，只有你的能力會限制什麼是你可以做的，以及什麼是無法做的而已。對本專案來說，很有機會能看見一般志工貢獻者做出專案技術方向的決定。

你在今夏所撰寫的程式代碼皆會直接進入 LibreOffice git 庫中。我們總是盡力讓同學們的苦工都能整合到下次較大的發行版本中。

參加 Google Summer of Code 的 LibreOffice 子項有什麼好處呢？

對你的生涯很有幫助！

你可能記得去年有許多相當成功的 Google Summer of Code 專案。兩位相當成功的學生如今受雇於開發自由與開源軟體，這可是與本活動的參與有直接相關。Eilidh McAdam 實作出 Visio 匯入篩選器 ，那是 LibreOffice 3.5 的旗艦功能。在 Eilidh 完成她的 phD 學位之前，已被 Lanedo 僱用。Miklos Vajna 在2010年針對 RTF 匯出篩選器功能改進，在2011年對 RTF 匯入功能改善。當他完成學業後，SUSE 就僱用他改善 LibreOffice。

當然，事情不見得都是樣；但他們不是最早，也不會是最後透過本活動得到工作機會的例子。

許多專案與導師供你選擇
我們的 GSoC 想法 wiki 頁面 包含超過 40 腫不同的提案，散布在 LibreOffice code-base 的各個角落。從 Microsoft Publisher 檔案格式的匯入篩選器，到 LibreOffice Base 對 sqlite 的支援，或是從改善合作撰寫功能，甚至到 Calc 效能的改進皆可，每個人都可以找到屬於自己的拿手處大展身手！

LibreOffice 專案有許多認真的導師，他們知道怎麼與那些不是住在同個屋簷下，不是鄰居，或甚至不同時區的人互動。社群友善，且相當歡迎你的加入。

如何申請
心動了嗎？那麼快來行動吧！
  • 秀出自己。 因為我們不認識你，所以我們要你告訴我們你的姓名、教育程度、電子郵件位址、在 LibreOffice IRC 頻道上的暱稱。
  • 證明你想要參與 LibreOffice。 為了檢驗這項條件，我們需要你完成 Easy_Hacks 頁面中的簡易程設事項 其中之一 (如果該 EasyHack 是由不同事項構成的，完成其中的一部分)，雖然這項考驗的截止日不嚴格限定，但是一定要在評選程序完成之前結束。這代表每位想被選中參與 LibreOffice 子項的同學，需要建置整個應用程式、修正臭蟲並提交修補檔至開發郵遞清單。請見 Development 頁面 瞭解更多資訊。
  • 解釋你想要達成什麼目標。 提供你想要對本專案行改善之處的詳細資訊，以及使用案例解說。你描述地越詳盡，它就對我們越有幫助。你想要改善的地方最好是以我們專案目前的點子為基礎，這樣我們親切的導師才能幫助你讓它更完善。
  • 你要怎麼計畫完成它？請提供我們下列資訊：
    • 預計的暑期時間表 (包括任何可能衝到的活動，像是你的課程、考試... )
    • 你想要如何實現的相關技術細節。你提供的合理細節越多，我們就越能輕鬆檢驗出你是否真的瞭解問題，以及問題的難度。
  • 為什麼我們該選擇你？ 給我們選擇你的所有理由。我們也對於你過去是否有過任何開源專案的改善行動 (hacking)、你的編程能力與社交技巧等有興趣。
LibreOffice 社群期待你有個歡愉且充滿生產力的夏天！

GNOME

https://live.gnome.org/SummerOfCode2012/Students
若要申請參與， 請先查看 Google SoC 's eligibility section  確保你符合參加資格。此外，請務必熟悉 Google's SoC 常見問題集 (英文) 。

決定個 SoC 專案


你可以在 ideas page 上查看我們的 SoC 想法，或是選取 有列出導師的 GNOME 專案 ，並與導師談談該 SoC 專案是否適合你。兩個頁面都可以，你可以在 IRC 上找到任何專案的主要開發者，介紹你自己，並詢問是否有適合你的 SoC 專案或者表達你自己的想法。

下列指引可以幫助你選取專案與準備你的點子：
  • 在 GNOME wiki 上閱讀專案的專屬頁面 
  • 在專案的 IRC 頻道 上閒聊
  • 建置專案的代碼，並執行它來查看最新的功能 (wiki 通常有怎麼做的指引，但如果真的遇到問題，請不要再猶豫，直接詢問專案的導師或 IRC 上的人們來幫助你)
  • 查看該專案在 GNOME Bugzilla 中還是開啟狀態的臭蟲回報
  • 查看該專案 Git repository 的最新更動
  • 閱讀該專案 郵遞清單 的最新討論
  • 閱讀專案導師與其他貢獻者的網誌 (當你查看 Git repository 時可以瞭解到誰是誰)
  • 閱讀 Planet GNOME
  • 檢閱 GNOME Love wiki 頁面與郵遞清單上可用的資訊
若要準備強而有力的提案，你需要盡可能學習有機會涉及實作時的事情，越多越好，並且在提案中寫下你目前所知道的部份有多少。

有些通用的 GNOME IRC 頻道 是你可以去晃晃的： #gnome-hackers、#gnome-love、#soc 等。如果你有任何與 GNOME 的 Google Summer of Code 申請方面的疑問，你可以在 #soc 頻道上詢問，或是聯絡 AlexandreFranke、ChristopheFergeau、DanielSiegel、 MarinaZhurakhinskaya。然而，請注意不要詢問類似「你認為我的提案會被接受嗎？(do you think my proposal will be accepted?)」這種問題。

做出小貢獻


一旦你決定你想提案的專案，你需要針對你將執行以實現提案的模組修正個小臭蟲。你可以詢問該模組的導師建議，瞭解怎樣才是適合你的臭蟲；或是在該專案的 Bugzilla 尋找某個你覺得可以的臭蟲，並拿它與導師確認是否沒有問題。你會需要下載並執行該專案的代碼，接著建立修正臭蟲的修補檔。雖然你的修補檔可能只有幾列代碼，但這無疑展示出你對於學習與參與的熱誠與意願。

當你在處理你的貢獻時，請不要拘束，自由詢問導師或該專案 IRC 頻道上的人們。你會需要上傳你的修補檔至專案 Bugzilla 中相對應的臭蟲回報。一旦你提交修補檔後，通常導師或其他人會校閱它，並給你一些怎麼改善的回饋。請務必遵循校閱者的回饋，並附上更新後的修補檔，直到你的貢獻可以被專案接納為止。這樣的校閱程序是平常更動進入專案前的標準過程，請不要因此被嚇著而裹足不前。你最好可以分配至少一週以上的時間來處理此程序，並且盡早開始。

填寫申請書


一旦學生申請期開始後 (3月26日)，你必須將你的申請提交至 Google's Summer of Code 網站。你的申請 只能 以英文撰寫。它需要包含你的提案的詳細描述。申請表須包含下列問題的回答：
  • 你的電子郵件位址與 IRC 暱稱？ 
  • 你是否有自己的網頁、網誌或微網誌？ 
  • 你的學業背景？
  • 你的提案的最終目標是什麼？ 
  • 你的提案需要修改或建立那些相關的部件/模組？
  • 你的提案對 GNOME 或其社群有什麼益處？ 
  • 你對於該如何完成你的專案有怎樣的計畫？ 
    • 如果有個含日期、重大里程碑/發行的時程表 (最好以兩週的間隔前進) 會很有幫助。
  • 你的期中考大約在什麼時候 [1]？
  • 你以前對於開源世界是否經驗？不管是使用者方面或是貢獻者角色皆可。
    • 請附上與你提案相關的 GNOME 模組臭蟲修正連結。 
    • 如果可以，請附上任何你寫過對 GNOME 或其他開源專案的代碼其連結。 
  • 你之前參與過的相關專案有哪些，以其你從中獲得的知識？ 
[1] 所有學生都會受邀參加 GUADEC，並在會議上演示他們的專案，大約在期中考之後。


請誠實並清楚回答這些問題。如果有什麼與你的申請相關的資訊，也請自由加入其中。請盡可能試著採用正確的英文填寫；評選委員會瞭解不是所有的申請人都以英語為母語，而且實際上很多 GNOME 社群成員都只是以英語為第二或第三語言！

你可能也想查閱 Google's SoC 給學生的建議 與 Buddhika Laknath 之前對於自己參與 SoC GNOME 子項後所給的建議 。

處理你的 SoC 申請永遠不嫌早！請注意 SoC 的位置非常有競爭性 (以往大約同個位置會有四位申請者) 建立強而有力的提案的關鍵，就是提出可管理、受同意的專案，並且貢獻與你提案相關的模組，然後撰寫清楚表達你的知識、技術、熱誠的申請表。

評選程序


每位 GNOME 基金會成員都可以查看學生的申請表，並在上面評註。當學生申請期結束後，小型的評選委員會 (約十人) 會分析評註，並選取他們心目中最合適的專案。這裡有些評選的準則：對於 GNOME 的實用性、學生對於專案的瞭解有多深、時間表是否看起來可實際執行、之前對於 GNOME 貢獻與其他工作時所表現出的技術等。

你該怎麼執行


一旦你的申請被接受，這裡有些你該怎麼與社群合作，以及我們期待你怎麼做的資訊：
  • 我們會指派一位導師給你，他/她會提供你執行專案時的指引，並判斷你是否完成
  • 你可以獲得 git repository 的存取權，或是自己建立自己的 git repository (目前有 gitorious 與 github 等服務可以協助你)，你可以在那裡放置自己的代碼
  • 你需要訂閱 gnome-soc-list 郵遞清單
  • 如果你有網誌，我們會將它匯流至有關 GNOME 與 Summer of Code 相關的 Planet 上：我們不只對你的專案有興趣，也想更認識你！你可以看看 Planet GNOME http://planet.gnome.org.
  • 你可以前往 irc.gnome.org 上的 #soc 頻道，與其他學生或導師聊聊 (當然，你也可以自由參與其他頻道！)
  • 我們希望你寄送一份有關你的進度的每週回報。如果還沒有撰寫一堆代碼，沒什麼關係，因為寫下你的想法更重要
  • 如果你可以盡可能過不同方式嘗試與社群合作會更好！那才是 Summer of Code 最重要的精神。如果你被邀請參與一些當地的 GNOME 活動，請不要驚訝！
雖然很不可能，但你或許會與指派的導師遇到一些問題。如果是這樣的話，請放心與 GNOME SoC 管理員聊聊。你親切的 GNOME SoC 管理員有 RubenVermeersch、DanielSiegel、ChristopheFergea 、SandyArmstrong 等人。

Blender
Blender 目前有個想法清單，如果想要參與的話，請參考它；通常每個想法所屬專案至少會有三位可能的導師。此外，請參考申請範本來提出申請。

相關連結：Bledner 今年度的 Google Summer of Code 首頁

留言

張貼留言

這個網誌中的熱門文章

直行橫列，以及 line (列/行), column (欄), row (列)

行，其字形本源是中央一條大路，左右旁開兩條小路的十字路口。 往前走向中央的大路，演變出行（ㄒㄧㄥˊ）走的意思；也是直行（ㄏㄤˊ）的由來。 列，其字形本源是歹加刀，歹是裂開的圖像，再加刀代表用刀劃開。 分開、劃開變成多個，演變出擺開、排開、一個一個的意思；也是橫列的由來。 在指稱行列時，自然是以眼前方向為直向，稱為行；左右擺開一個一個為橫向，稱為列。 台灣延續直書與行列的本源傳統，依然採用直行、橫列來描述排版的文字方向。 然而數位設備最早誕生自橫排為主的西方國家，數位化時也為了相容常見的歐美文字，漢字跟著橫向排列，於是橫書成為數位排版系統中最早支援的漢字排列方向，早於直書支援。 最早的軟體中文翻譯，是明確區分橫列的，例如「列印」(print)、「命令列」(command line)、「換列」(change line)、「新列」(new line) 等，皆是出自這個時期。 後來文書排版系統興起，也有越來越多軟體支援直書。而直書的所說的行，也因為排版軟體通行之故，大眾依口語直接被挪用至橫書情境使用，行的語義開始擴及並滲入橫書。這也約莫是圖形介面軟體、Windows 作業系統開始大幅流行之時。 文書排版系統中，有一指稱文字流方向的特定術語，Line，沒有區分方向，亦即可以是直書，也可以是橫書。 早期譯者還會視程式特性，在如終端機、文字編輯器軟體中，會將其翻譯為「列」，如「換列」(change line)、「列號」(line number)、「列印」(print) 等。在中文排版軟體興起後，開始出現「換行」(對應至英文的 new line 或 change line 或 line wrap)、「行號」的說法，並逐漸被大眾挪用到橫向語境中。 因此，目前臺灣的程式翻譯，在確定文字明確用於橫向情境，或譯者確定該程式沒有直書情境時，例如終端機、命令列程式、程式碼編輯器，會採用「列」來對應 Line。 至於同時能支援直書或橫書的軟體，例如文書編輯器，或是譯者無法確定程式的文字方向時，則採用廣被接受可同時指稱直書與橫書的「行」來對應 Line。 總結來說，「行」可以是 line，原先是直書，後來也被用於橫書；「列」也可以是 line，明確用於橫書情境。 至於試算表軟體，或其他可清晰區分直、橫單位的軟體，依然採用直行、橫列的標準譯法。 如 column 為欄（少數譯者譯為行），以及 row...
閱讀完整內容

Permission 取用權/權能; Permission denied 取用遭拒; Ask for permission 請求取用權/權能; Don't have the right permission to 無權/沒有權能

圖片
一般而言，Permission 在描述檔案或功能的「可取用權利」設定情境下，建議翻譯為「 權能 」。 若譯為「權限」可以接受，但譯者要注意它不是 Permission 的對應翻譯，而是轉變了意思概念的說法 （即職權、特定權力範圍的概念，英文為 Authority）。 至於其他如程式取用權的設定，例如攝相機、地理位置，或是隱私設定⋯ ⋯ 等授權程式存取與否的情境，則建議翻譯為「 取用權 」。 ====== 在軟體界的翻譯中，對於 Permission 的翻譯，常見一項重大失誤，讓我們來繼續看下去， 例：Permission denied. 沒有權限。（中文實際意義類同行車時沒有速限，可以 踩下油門貼地飛行囉） ；原文應譯為：沒有權能/取用遭拒 Permission 是 Permit 的名詞。 讓我們來看 Meriam-Webmaster 字典對 Permit 的英文解釋： Transitive verb 1 : to consent to expressly or formally permit access to records 2 : to give leave : authorize 3 : to make possible the design permits easy access   Intransitive verb : to give an opportunity : allow if time permits   簡單說，Permit 對應到中文就是「允許」「許可」「得以」的概念。Permission 就是得到允許、...
閱讀完整內容

正體中文、繁體中文？

在尚無所謂簡體字的年代，漢字本身就可分為正體字與異體字。 過去漢字還沒有官方規範前，一個字可能很多寫法，為了方便流通與做政績，官方就找有學識的人來指定標準寫法為「正體」，唐朝的某些年代則用「定體」一詞 [可參見漢學家白川靜《漢字百話》著作]。 而正體的正，是正規、標準的意思，並非指正統；其餘的非標準寫法就稱作異體，包含各種可以表述出同個字的其他寫法字，簡化字則是其中的子集。所謂「正體」一詞，就是為了統整多個表同義的漢字寫法，從中挑選一個作為官方承認而定的規範寫法，本來就會因為時代、地區、政府不同而有所改變。 中國大陸後來刻意對大多數漢字以形聲方式作人為的簡化創造，也稱之為簡化字，或者簡體字。而中國大陸所使用的漢字系統，因為主要推行簡化字之故，所使用的整體漢字系統方案都被稱之為「 簡體中文 」， 除了簡化字外也涵蓋未簡化的正體字 ，也就是那些仍未被簡化的古典正體字，這是因為並非所有的字都可以簡化，而前述這兩類字中國大陸都有訂立各自的規範寫法。 我們可以這樣想像， 如果前朝的正體字是樹木的主幹的話，中港臺三地就是各自生出了自己的分支發展、維護下去 。 那麼 臺灣用的漢字怎麼稱呼？ 在臺灣所使用的漢字，理當遵循臺灣標準，稱「 臺灣正體 」是最直覺的，這就跟國語文競賽，或是正式文件中要求你「請以正體字書寫」一樣直覺。對於 Traditional Chinese 一詞，由於臺灣地區不推行中國大陸的簡體字，因此對臺灣人而言就是指「以正體字書寫的中文」，即「正體字中文」，簡稱為「 正體中文」 。 臺灣正體字寫法也不盡與傳承的古典正體字相同，仍有些字或多或少寫法不同的。但只要因循臺灣官方規範的正規寫法，就是臺灣正體字。 而中國大陸官方所規範的整套簡化字、非簡化字方案寫法 ，也異於古典正體，因此中國政府 另外改採用「規範字」來稱呼 。 說著臺灣正體字也不完全符合康熙字體，或是寫法不符合原始造字原則云云，所以不能稱為正體中文的人，搞錯了時間、地點，反以過去古代正體為正規標準，這無疑是對正體二字的嚴重誤解，因為正體字如何寫取決於其時代背景與政治環境。 雖然也有相對於簡體中文，而將傳承下來的古典正體漢字表達為「繁體中文」的說法，但這是以簡體的觀點出發來看而稱呼。由於未簡化字的筆劃比起簡化字更「繁瑣」、「繁雜」、「繁複」，所以用「繁體」來取代過去「正體」之名。 之...
閱讀完整內容