diff --git a/sources/talk/20150921 14 tips for teaching open source development.md b/sources/talk/20150921 14 tips for teaching open source development.md
deleted file mode 100644
index fb250ac4c6..0000000000
--- a/sources/talk/20150921 14 tips for teaching open source development.md	
+++ /dev/null
@@ -1,74 +0,0 @@
-GHLandy Translating
-
-14 tips for teaching open source development
-================================================================================
-Academia is an excellent platform for training and preparing the open source developers of tomorrow. In research, we occasionally open source software we write. We do this for two reasons. One, to promote the use of the tools we produce. And two, to learn more about the impact and issues other people face when using them. With this background of writing research software, I was tasked with redesigning the undergraduate software engineering course for second-year students at the University of Bradford.
-
-It was a challenge, as I was faced with 80 students coming for different degrees, including IT, business computing, and software engineering, all in the same course. The hardest part was working with students with a wide range of programming experience levels. Traditionally, the course had involved allowing students to choose their own teams, tasking them with building a garage database system and then submitting a report in the end as part of the assessment.
-
-I decided to redesign the course to give students insight into the process of working on real-world software teams. I divided the students into teams of five or six, based on their degrees and programming skills. The aim was to have an equal distribution of skills across the teams to prevent any unfair advantage of one team over another.
-
-### The core lessons ###
-
-The course format was updated to have both lectures and lab sessions. However, the lab session functioned as mentoring sessions, where instructors visited each team to ask for updates and see how the teams were progressing with the clients and the products. There were traditional lectures on project management, software testing, requirements engineering, and similar topics, supplemented by lab sessions and mentor meetings. These meetings allowed us to check up on students' progress and monitor whether they were following the software engineering methodologies taught in the lecture portion. Topics we taught this year included:
-
-- Requirements engineering
-- How to interact with clients and other team members
-- Software methodologies, such as agile and extreme programming approaches
-- How to use different software engineering approaches and work through sprints
-- Team meetings and documentations
-- Project management and Gantt charts
-- UML diagrams and system descriptions
-- Code revisioning using Git
-- Software testing and bug tracking
-- Using open source libraries for their tools
-- Open source licenses and which one to use
-- Software delivery
-
-Along with these lectures, we had a few guest speakers from the corporate world talk about their practices in software product deliveries. We also managed to get the university’s intellectual property lawyer to come and talk about IP issues surrounding software in the UK, and how to handle any intellectual properties issues in software.
-
-### Collaboration tools ###
-
-To make all of the above possible, a number of tools were introduced. Students were trained on how to use them for their projects. These included:
-
-- Google Drive folders shared within the team and the tutor, to maintain documents and spreadsheets for project descriptions, requirements gathering, meeting minutes, and time tracking of the project. This was an extremely efficient way to monitor and also provide feedback straight into the folders for each team.
-- [Basecamp][1] for document sharing as well, and later in the course we considered this as a possible replacement for Google Drive.
-- Bug reporting tools such as [Mantis][2] again have a limited users for free reporting. Later Git itself was being used for bug reports n any tools by the testers in the teams
-- Remote videoconferencing tools were used as a number of clients were off-campus, and sometimes not even in the same city. The students were regularly using Skype to communicate with them, documenting their meetings and sometimes even recording them for later use.
-- A number of open source tool kits were also used for students' projects. The students were allowed to choose their own tool kits and languages based on the requirements of the projects. The only condition was that these have to be open source and could be installed in the university labs, which the technical staff was extremely supportive of.
-- In the end all teams had to deliver their projects to the client, including complete working version of the software, documentation, and open source licenses of their own choosing. Most of the teams chose the GPL version 3 license.
-
-### Tips and lessons learned ###
-
-In the end, it was a fun year and nearly all students did very well. Here are some of the lessons I learned which may help improve the course next year:
-
-1. Give the students a wide variety of choice in projects that are interesting, such as game development or mobile application development, and projects with goals. Working with mundane database systems is not going to keep most students interested. Working with interesting projects, most students became self-learners, and were also helping others in their teams and outside to solve some common issues. The course also had a message list, where students were posting any issues they were encountering, in hopes of receiving advice from others. However, there was a drawback to this approach. The external examiners have advised us to go back to a style of one type of project, and one type of language to help narrow the assessment criteria for the students.
-1. Give students regular feedback on their performance at every stage. This could be done during the mentoring meetings with the teams, or at other stages, to help them improve the work for next time.
-1. Students are more than willing to work with clients from outside university! They look forward to working with external company representatives or people outside the university, just because of the new experience. They were all able to display professional behavior when interacting with their mentors, which put the instructors at ease.
-1. A lot of teams left developing unit testing until the end of the project, which from an extreme programming methodology standpoint was a serious no-no. Maybe testing should be included at the assessments of the various stages to help remind students that they need to be developing unit tests in parallel with the software.
-1. In the class of 80, there were only four girls, each working in different teams. I observed that boys were very ready to take on roles as team leads, assigning the most interesting code pieces to themselves and the girls were mostly following instructions or doing documentation. For some reason, the girls choose not to show authority or preferred not to code even when they were encouraged by a female instructor. This is still a major issue that needs to be addressed.
-1. There are different styles of documentation such as using UML, state diagrams, and others. Allow students to learn them all and merge with other courses during the year to improve their learning experience.
-1. Some students were very good developers, but some doing business computing had very little coding experience. The teams were encouraged to work together to prevent the idea that developer would get better marks than other team members if they were only doing meeting minutes or documentations. Roles were also encouraged to be rotated during mentoring sessions to see that everyone was getting a chance to learn how to program.
-1. Allowing the team to meet with the mentor every week was helpful in monitoring team activities. It also showed who was doing the most work. Usually students who were not participating in their groups would not come to meetings, and could be identified by the work being presented by other members every week.
-1. We encouraged students to attach licenses to their work and identify intellectual property issues when working with external libraries and clients. This allowed students to think out of the box and learn about real-world software delivery problems.
-1. Give students room to choose their own technologies.
-1. Having teaching assistants is key. Managing 80 students was very difficult, especially on the weeks when they were being assessed. Next year I would definitely have teaching assistants helping me with the teams.
-1. A supportive tech support for the lab is very important. The university tech support was extremely supportive of the course. Next year, they are talking about having virtual machines assigned to teams, so the teams can install any software on their own virtual machine as needed.
-1. Teamwork helps. Most teams exhibited a supportive nature to other team members, and mentoring also helped.
-1. Additional support from other staff members is a plus. As a new academic, I needed to learn from experience and also seek advice at multiple points on how to handle certain students and teams if I was confused on how to engage them with the course. Support from senior staff members was very encouraging to me.
-
-In the end, it was a fun course—not only for the me as an instructor, but for the students as well. There were some issues with learning objectives and traditional grading schemes that still need to be ironed out to reduce the workload it produced on the instructors. For next year, I plan to keep this same format, but hope to come up with a better grading scheme and introduce more software tools that can help monitor project activities and code revisions.
-
---------------------------------------------------------------------------------
-
-via: http://opensource.com/education/15/9/teaching-open-source-development-undergraduates
-
-作者：[Mariam Kiran][a]
-译者：[译者ID](https://github.com/译者ID)
-校对：[校对者ID](https://github.com/校对者ID)
-
-本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
-
-[a]:http://opensource.com/users/mariamkiran
-[1]:https://basecamp.com/
-[2]:https://www.mantisbt.org/
diff --git a/translated/talk/20150921 14 tips for teaching open source development.md b/translated/talk/20150921 14 tips for teaching open source development.md
new file mode 100644
index 0000000000..aef6304789
--- /dev/null
+++ b/translated/talk/20150921 14 tips for teaching open source development.md	
@@ -0,0 +1,75 @@
+GHLandy Translated
+
+开源代码开发的十四点教学技巧
+================================================================================
+
+对于培养和塑造开源代码开发者，学术界就是一个很好的平台。研究中发现，我们偶尔会开源自己编写的软件。这样做有两个理由，一是为了提升自己编写的工具的使用率，二是为了了解人们使用这些工具时会遇到哪些问题。在这样一个编写研究软件的背景下，我的任务就是为 Bradford 大学重新设计二年级的软件工程课程。
+
+这是一个巨大的挑战，因为我所面对的 80 个学生是来自不同专业的，包括 IT、商务计算和软件工程，这些学生将要在一起上课。最有难度的是，需要和这些编程经验差距很大的学生一起编写代码。按照传统，该课程允许学生选择自己的小组，然后布置他们构建一个存储数据库系统构的任务，最后提交报告作为评估的一部分。
+
+而我决定重新设计课程，让学生了解现实中的软件团队是如何协作的过程。根据学生的专业和编程技能，我将他们分为五六个人一组。这是为了确保每个小组的整体水平相当，避免小组之间的不公平。
+
+### 核心课程 ###
+
+课程的形式升级为文化课和实践课两项结合在一起。然而实践部分只是充当辅助，主要是老师监督各个小组的实践进度以及他们如何处理客户和产品之间的关系。传统的教学方式由项目管理、软件测试、工程需求分析以及类似主题的讲座组成，再辅以实践和导师会议。这些会议可以很好的考核学生的水平以及检测出他们是否可以跟得上我们在讲座部分中的软件工程方法。本年的教学主题包括以下内容：
+
+- 工程需求分析
+- 如何与客户及其他团队成员互动
+- 程序设计方法，如敏捷和极限编程方法
+- 如何通过学习不同的软件工程方法进行短期的水平提高
+- 小组会议及文档编写
+- 项目管理及项目进展图表
+- UML 图表及系统描述
+- 使用 Git 来进行代码的版本控制
+- 软件测试及 BUG 跟踪
+- 使用开源库
+- 开源代码许可及其选择
+- 软件分发
+
+在这些讲座之后，我会有一些来自世界各地的嘉宾为我们说说他们在软件分发过程中的经验。我们也设法请来大学里知识产权律师谈关于软件在英国的知识产权问题，以及如何处理软件的知识产权问题。
+
+### 协作工具 ###
+
+为了让上述教学内容的顺利进行，我们将会介绍一些工具，并训练学生在他们的项目中使用这些工具。如下：
+
+- Google Drive：团队与导师之间进行共享的工具，暂时存储用于描述项目的文档和图表、需求收集、会议纪要以及项目跟踪等信息。采取这样一个方式来监控并提供直接反馈到每个团队，是非常有效的。
+- [Basecamp][1]：同样是用于分享文档，在随后的课程中，我们可能会考虑用它取代 Google Drive。
+- BUG 报告工具，如 [Mantis][2]：只能让有限的用户自由提交 BUG。稍后我们提到的 Git 可以让小组内的所有人员用做 BUG 提交。 
+- 远程视频会议工具：在人员不在校内，甚至去了其他城市的情况下使用。学生们可以定期通过 Skype 来交流并记录会议内容或则进行录音作为今后其他用处。
+- 同时，学生们的项目中还会用到大量的开源工具包。他们可以根据自己小组的项目需求来选择自己使用的工具包和编程语言。唯一的条件是，这些项目必须开源，最后成果可以安装到大学里的实验室，并且大多的研究人员都支持这个条件。
+- 最后，所有团队必须向客户交付他们的项目，包括完整的工作版本的软件、文档和他们自己选择的开放源码许可。大多数的团队选择了 GPLv3 许可证。
+
+### 技巧和经验教训 ###
+
+在最后，这一年过的很愉快，并且所有学生的项目都做的非常棒。这里有一些我学到的经验教训，可能有助于提高明年的课程质量：
+
+1. 提供各种各样的有趣的选择项目给学生选择。比如说，游戏开发或者移动应用开发以及完成各种目标的项目等。建立普通的数据库系统已经不能提起学生的兴趣了，而参与到有趣的项目中去，学生本身就是自学者，同时可以帮助解决小组成员和小组之间的常见问题。再通过一个消息列表，学生们发表他们在测试中遇到的任何问题，以寻求其他人的帮助建议。然而，这种方法有一个缺点。外部考官建议我们使用统一种类型的项目和统一的编程语言以帮助缩小对学生的评估标准。
+2. 定期给学生在每一个阶段的表现进行反馈。比方说，可以在和各个小组开指导会议的时候、或者每个阶段进行反馈，以帮助他在接下来的工作中自我改进。
+3. 学生更加愿意与校外的客户一起协作。他们期待着与外部公司代表或大学以外的人协作，不过是为了获得新体验而已。与导师进行交流时，他们都能够表现得很专业，这样使得老师非常放心。
+4. 很多团队版开发单元测试的部分放到项目结束之后，从极限编程方法的角度来说，这是一个严重的禁忌。也许测试应包括在不同阶段的评估中，来提醒他们需要与并行开展软件开发和单元测试。
+5. 在这个班的 80 个人里边，仅有 4 个女生，每个女都分在不同的小组里边。我观察到，男生们总是准备充分地承担起领队角色，并将最有趣的代码分配个他们自己来编写，女生则多大遵循安排或则是编写文档。出于某种原因，女生选择不显示权威，即使在女性辅导员鼓励下，她们也不愿编写代码。这仍然是一个需要解决的主要问题。
+6.允许不同风格文项目文档，比方说，UML 图表、状态图或其他形式的。让学生学习这些并与其他课程融汇贯通来提高他们的学习经验。
+7. 学生里边，有些是很好的开发人员，有些做商务计算的则没有多少编程经验。我们要鼓励团队共同努力，避免开发人员做得比那些只做会议记录或文档的其他成员更好的错误认知。我们常在辅导课程中鼓励角色转换，让每个人都有机会学习如何编程。
+8. 各个小组进行导师会议室非常重要的，可以有效监督各个小组进展情况，还可以了解是谁做了大部分工作。通常，没来参加会议的小组成员基本就是没有参与到他们的团队工作中去的，并且通过其他成员提交的工作报告也可以确定哪些人不活跃。
+9. 我们鼓励学生们把许可证附加到项目中去，使用外部库以及和客户协作的时候要表明确切知识产权问题。 这样可让解放学生的思考能力，了解真实的软件交付问题。
+10. 给学生们自己选择技术空间。
+11. 助教是关键。同时管理 80 个显示显然很有难度，特别是需要对他们进行评估的那几周。明年我一定会找个助教来帮我一起管理各个小组。
+12. 实验室的技术支持是非常重要的。大学里的技术支持对于本课程是非常赞同的。学习正在考虑明年将虚拟机分配给每个团队，这样没个团队可以根据需要自行在虚拟机中安装任何软件。
+13. 团队合作，相互帮助。大多数团队自然而然的支持其他团队成员，同时指导人在中间也帮助了不少。 
+14. 来自其他技术人员的帮助只能作为辅助方法。作为一个新的学术，我需要从经验中学习，同时当我如何知道学生是，我会通过多个角度来建议学生和小组去尝试处理问。来自高级技术人员的支持对我来说就是一种鼓励。
+
+最后，对于作为导师的我以及所有的学生来说，这都是个有趣的课程。在学习目标和传统的分级方案上还有有一些问题需，以解决减少教师的工作量。明年，我计划会保留这种教学模式，并希望能够提出更好的分级方案以及介绍更多的软件来帮助监督项目和控制代码版本。
+
+--------------------------------------------------------------------------------
+
+via: http://opensource.com/education/15/9/teaching-open-source-development-undergraduates
+
+作者：[Mariam Kiran][a]
+译者：[GHLandy](https://github.com/GHLandy)
+校对：[校对者ID](https://github.com/校对者ID)
+
+本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
+
+[a]:http://opensource.com/users/mariamkiran
+[1]:https://basecamp.com/
+[2]:https://www.mantisbt.org/