UCOSP

Undergraduate Capstone Open Source Projects

About

Software development is no longer bound by time zones or national borders. Projects of all kinds—academic, commercial, and open source—may have their GUI designers in Boston, their database team in Bangalore, and their testers in Budapest and Buenos Aires. Working effectively in such teams is challenging: it requires strong communication skills, and makes proper use of coordination tools such as version control and ticketing systems more important than ever. But it is also an opportunity for students to build ties with peers across the country and around the world, and for instructors to breathe new life into old courses.

Since September 2008, undergraduates from several universities in Canada and the US have been taking part in joint capstone projects in order to learn first-hand what distributed development is like. Each team has students from two or three schools, and uses a mix of agile and open source processes under the supervision of a faculty or industry lead. This FAQ describes the program’s current incarnation; if you have other questions, please contact Greg Wilson.

What are the learning objectives of this program? For students to gain hands-on experience with real-world development practices in a realistic environment while simultaneously learning and applying some core concepts of computer science.

Is this part of an official university or government program? Not yet—we are still in the pilot phase (which is a professor’s way of saying, “We’re still learning how to do this.”).

Who is sponsoring this? Our sponsors page describes and thanks the companies and organizations that have helped to make this program possible.

What projects are available? Our project list for Winter 2010 is available on the Projects page.

Who can enrol? Undergraduates who are in their final four terms of study, have a strong ‘B’ or ‘A’ average, and are able to enrol in an appropriate course at their home institution. (Typically, this course is called a capstone, a senior project, or a directed studies course.) To ensure balance, we limit the number of students per school; please contact your local faculty for details.

What schools are taking part? The following schools are confirmed for the Winter 2010 term:

See the Fall 2009 page for a list of schools that took part in that term.

Can I still take part if my school is not in this list? Sure, if you can persuade a faculty member at your school—please have them contact Greg Wilson for more information.

Can I take part more than once? Sure, if you can persuade a faculty member at your school. If you do come back, you can either stay with the same project or move to a new one.

Who chooses what projects students work on? The students themselves, on a first-come, first-served basis. We try to make sure that each team has roughly six students drawn from at least three universities. We also try to have at least two students from any university on any one project so that everyone will have a local partner.

How are tasks within a project allocated? This varies from team to team. In general, though, there’s enough work for everyone to spend most of their time working on something they find interesting.

What skills do students need? The programming skills required vary widely from project to project: students are more likely to succeed in a Java-based project if they already speak Java, and more likely to do well on a cellphone project if they have some previous experience with handheld devices or wireless networks. Students should also be familiar with, or willing to learn, version control, bug tracking, and other coordination tools. Keep in mind, though, that being able to set their own goals, manage their own time, and communicate with others is at least as important as knowing any particular programming language or operating system.

What do students find challenging about these projects? Cooperation, communication, and commitment. For many students, this is the first time they have had to set their own goals and deadlines, and some struggle with that freedom during the first few weeks.

What are the benefits to the students? Experience working in a distributed team on a meaningful project; peer contacts (social/professional networking); something cool to demo in interviews for jobs and graduate school.

Do potential employers and graduate supervisors actually look at these projects? Yes.

When do projects start and finish? Projects start at the beginning of term (September or January), and run to its end (December or April). Because different schools calendars’ don’t line up, some students may start or finish earlier or later than others. We do not currently accommodate students whose schools use a quarter system, and have no plans to run this program during the summer.

How much effort is expected from students? The same as any other course, i.e., about 8-10 hours/week.

Can I do this course at the same time as a co-op job or other industry placement? Only if your school’s policy permits it, and even then, only if you can commit 8-10 hours/week.

How are projects managed? The organizers take care of week-by-week project management, though other faculty are very welcome to get involved as well.

How are projects graded? Grades are awarded jointly by the local faculty organizer in consultation with the project lead. Grading schemes are tailored to individual teams and projects, and take into account the requirements of the courses in which students are officially registered. (For example, a student who is registered in a senior course on Software Architecture may spend more time on design and documentation than on coding.) In many projects, students themselves propose grading schemes once they are familiar with the project. There is usually not a midterm or final exam, but some schools require students to do an end-of-term presentation and/or create a screencast to show what they have accomplished.

What development process do teams use? Standard software development processes are not well-suited to students’ realities: unlike professionals in industry, students usually have to work on several projects at once, and are almost always new to the technologies they’re using and the problem domain they’re working in. Based on past experience, the best fit is a mix of open source practices and Scrum:

  • Every project keeps its work in a version control repository, uses tickets to track work items, etc. Teams are strongly encouraged to do code reviews.
  • Each team has an hour-long online meeting each week to review progress, set goals, answer questions, and resolve outstanding issues.
  • Work is usually done in two-week iterations. At the end of each iteration, each team member sets their goals for the next one, so that students have a chance to develop planning and estimation skills.
  • Each team is required to produce a five-minute screencast demo of their work at the end of the term.

What kind of work do students do? All the things that real software projects need, including design, construction, testing, packaging, and documentation.

Do teams get to meet each other and their project leads? Yes—there is a three-day code sprint in Toronto near the start of term at which teams meet in person to discuss the strategies for the term, attend team-building social events, and write lots of code.

How do team members communicate? Via the usual online tools, such as blogs, chat, mailing lists, and Skype. Team members may agree on something else new and trendy, such as FriendFeed, Twitter, or Google Wave.

What level of work is expected? (Almost) all of these projects are producting software for real-world use, so standards are high. Remember, “95% correct” may be an ‘A’ academically, but if 5% of an application is buggy, users aren’t going to be happy.

Do the projects vary from term to term? Yes, although we try to keep projects rolling for several terms to reduce startup overheads.

Do students get help from students who have worked on the same project in previous terms? Yes, where possible. Unlike most university courses, we strongly encourage students to communicate with each other and their predecessors.

How do code reviews work? Students post finished work (including tests) to their team’s code review site. Another team member then reads it through and gives the author on what needs to be fixed before it can be committed. Once the author has made all the fixes suggested, and the reviewer gives the ok, the code is put into the version control repository for others to use.

How can I find out more? Please contact Greg Wilson or the organizer at your university for more details.

11 Responses to “About”

  1. [...] By gvwilson Welcome to the Undergraduate Canadian Open Source Projects blog.  As the About page says, it is the home for a set of projects being done by computer science students from across [...]

  2. [...] Wilson is teaching a capstone project course on open source.  He’s made good on an idea he told me about a few years ago to bring [...]

  3. [...] be working on parts of the elmcity project by way of Undergraduate Capstone Open Source Projects (UCOSP), organized by Greg Wilson. In our first online meeting, the students decided they’d like to [...]

  4. onitony said

    Some additional Q/A.

    Will the teams get to meet each other and their project lead?

    The term starts off with a CodeSprint event in Toronto where the teams get meet in person, discuss the strategies for the term, attend team-building social events, and write lots of code.

    How do team members communicate?

    There are a variety of tools available for online communications. Blogs, IRC, and mailing lists are some of the options already in use. Team members may agree on something else new and trendy: Skype, Twitter, Google Wave.

    What kind of work will be done on a project?

    A team lead would typically have an idea of where the project should be heading, but the work done within that scope is fairly open ended. Students get to pick their own tasks, and could focus on areas of their interest.

    What is the difficulty of writing code expected to be produced?

    Because it’s a team project, with code possibly going into a production environment, the expected level of quality is different from a typical academic course. “95% correct” means that 5% of new code are bugs that break the project for everybody else. There will be peer reviews and automated tests to prove that everybody’s code works.

    What is a cool thing to demo in future interviews?

    As projects are open source, you will have publicly viewable code, in the context of a production system, committed under your name. For employers that want to see code samples, this is the thing to show. As well, one of the suggested deliverables is a video demo of what you’ve done — way cooler than simply describing what the code does.

    Do employers actually look at this project’s work?

    Yes, just ask Greg for some success stories.

  5. Eva Wong said

    additional_q_and_a++;

    – What are the learning objectives behind UCOSP?
    For the students to get experience and have fun doing something that they are interested in, under an environment that is close to how the industry is like out there.

    – What are some main challenges of UCOSP?
    Co-operation, communications and commitment.

    – Will the projects varies from term to term?
    Maybe, maybe not. However, things will be confirmed prior to the term starts.

    – Does the students get help from students who have worked on the same project from previous terms?
    Yes, and if there is, they have met each other at the code sprint a few weeks after the term started.

    – Are the above the set of all projects that are hosted in the term 2009 fall?
    No, we have one more, the Ingres projects.

  6. simonlg said

    Is it for code monkeys and people who like to work alone on their things?

    No, this project is not for them. You need to communicate a lot with others.

    How are tasks assigned?

    It depends on the project. In MarkUs, while being in Toronto, our project manager showed us the features we needed to do and everyone picked one.

    Is it necessary to know the programming language before starting the course?

    No it is not. If you know how to program and know at least one language, learning another one is easy. Reading a book on any language is fast and easy.

    Can the tasks be done at the last minute?

    No it can’t, you have to make progress each week and it is a good opportunity to learn how to work 8-10 hours a week every week.

    Is the trip to Toronto well organized?

    Yes it is, everything is planned. Hotel rooms are reserved and 2 out of 3 evenings are planned.

    Is it possible to not like it?

    No it’s not.

  7. Ted Tate said

    How are tasks within a project allocated?

    This will probably differ on a team to team basis. In most cases students will be asked what parts of the project they would like to work on and then will be allocated that part.

    How do online code reviews work?

    You will need to post your finished work (including tests) as a diff ,output from your VCS, to your team’s code review site. Then when a team member gets a chance he/she will review it and give you feedback on what needs to be fixed before you can commit the code to the VCS. Once you have made all the fixes suggested by your reviewer and your reviewer gives the OK then you can commit your code to the project VCS.

    What can I expect to learn in this course?

    You will learn about all the things you need to do software engineering out in the big open world. This includes things like version control, unit testing, and code reviews.

    What kind of people will I be working with?

    Take a look at this here blog to find out about all the awesome people who have done UCOSP in the past.

    What was the best thing about doing UCOSP?

    This is obviously a very subjective question. For most, it was probably getting to meet and hang out with all of the other UCOSPers at the Code Sprint. Reading email is much nicer when you can put a face to it.

  8. [...] some cross-country undergrad capstone projects again starting in January—the newly-updated UCOSP FAQ has some details, and I’ll post a note on that blog when we finalize the project list. Please [...]

  9. Gabriel Roy-Lortie said

    Here are some additional questions & answers that address to CS students interested in the UCOSP.

    Q1. Can I still participate even though my University is not listed at the top of this page?

    I strongly encourage you to get in touch with your local CS faculty and introduce them the UCOSP.

    People here are always looking forward to expand their collaboration network, and will welcome any request with the greatest enthusiasm.

    Currently participating universities are located in Canada and United States (for evident geographical reasons, this all started out in Toronto) but you should not keep yourself of trying to participate may you be on an another continent.

    If your university is not yet involved with the open source community, tell them how important open source collaboration could be for their students (some very good reasons are found on this page)

    Q2. What kind of tools will I have the chance to work with?

    Collaboration is a tremendous aspect of any project at the UCOSP. So, in order to interact efficiently with you peers, you’ll be given to use some very useful collaboration tools. You will, as expected, write your fair share of e-mails and blog posts when not attending to IRC meetings (or Skype — It greatly depends on the project your on, and what the teams may decide to use). Other than that, there will be the unavoidable industy-couldn’t-live-without Version Control, Bug tracking system and Code Review Tools.

    Version Control

    Examples: Subversion (SVN), Git, Mercurial[1]

    An absolutely necessary tool for team development that let each developer work on a local copy of the code base and “commit” his changes once they are ready. Each version control product offer his share of functionalities from the simple checkout-update-merge-commit flow to the more evolved “feature branching”.

    Personal experience:

    During Fall 09 Code Sprint, I was really surprised to learn that some students there were meeting with version control for the first time. If it is true that UCOSP participants have to be in their 4th year, it means some universities have not included the use of version control as part of their 3 first years cursus[2].

    On this page it is written that: “Students should also be familiar with, or willing to learn, version control [...]“. I would say, being willing to learn it is not an option. Unless you intend to code alone in your basement for the rest of your life. And even if I coded alone in my basement, I would use version control may it just be for the history capabilities.

    Code Review Tools

    Examples: Rietveld, Review Board, PeerReviewPlugin (Trac plugin)[3]

    Why is it important

    Version control is sweet and once you have tasted it you can not go without but in an open source context, it is not enough. Because, most desirably, many people are using the latest version of your code base (including end-users) you can not afford to have it broken by a faulty commit. The first line of defense to avoid that to happen is, of course, to test your code (can this be said too much?). Though testing is good, you want to make sure that your code reflects all of code standards for the project. There comes the code review.

    What will it gives you

    One common complaint about CS programs is that, unlike structural architects who study great existing architectures or novel writers that read great literature[4], when you study CS, you never get to read great software. A lot of things is to be learn just at looking at well-written code.

    Well, reviewing your peers code may not be the best source for “state-of-the-art great code”(this is arguable) but, nonetheless, it’ll greatly enhance your skills. General coding skills and expressive skills, as you will have to explain what is it you think is good/bad in someone else produced code. Never mind the fact that it’s a great way to get a grasp on an alien code base.

    Personal experience:

    I am participating in the MarkUs project right now and we use Review Board. How I miss having this tool in my other assignments. I am addicted!

    Q3. Can I participate more than once?

    There is no limit to the number of participation, according you must be in 4th year, you probably will have difficulties participating more than twice. I know you would, but… :-)

    Q4. If I participate more than once, will I have to work on the same project?

    No, you can choose to work on a different project. Although you should consider the reduced startup overhead when coming back to the same project. Think about it, being already set up (it is true that some of the projects involve setting up an impressive technological stack) and being familiar with the code base at the beginning of the semester would be a quite an advantage for you and your team.

    Q5. Are the project teams academics only?

    No, some of the project leaders are from the industry. And even when it’s not the case, you’ll find that industry people wander around these projects replying to questions and providing guidelines to those struggling with roadblocks.

    Q6. What will I do aside software development?

    You will get the chance to do a couple more things than plain software development.

    There is a public writing component to that course[5] for which you could be asked to, say, comment an existing blog post, review an article or publish something genuine on particular matter. All of the above inclining you to sharpen your expressive skills.

    But other things I could think of are: meeting interesting people (peers, teachers and professionals) and seeing Toronto (irrelevant to UofT students though :-p)

    [1] Hey, Mercurial is one of the projects at UCOSP!
    [2] If that’s your case, maybe you should think of writing an e-mail to your program comity (or whatever it is called at your place) about the matter.
    [3] Part of this list comes from Mike Gundelroy’s post[http://ostatic.com/blog/open-source-code-review-tools]. He’s one, out of many, of the industry people that wanders around projects which I refer to in Q5.
    [4] I’m paraphrasing Greg here.
    [5] As an example, this comment is my fall ’09 contribution.

  10. [...] Wrote a comment (on Greg’s request) for the About page of the UCOSP blog [...]

  11. [...] are eligible to enrol in either CSC494 or CSC495, then please check out the FAQ and project list at http://ucosp.wordpress.com/about/ or contact Prof. Greg Wilson (gvwilson@cs.utoronto.ca). The number of spots available to U of T [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: