Open Source Process Reports =========================== Due: Tuesday, January 28, in class (printed copy of report or slides) Introduction ------------ This is a group assignment. Do this assignment together with other 15-413 CMU students who are working on the same open source project. Investigate the process used by your open-source project. A good starting point is to ask the following questions about the project: * How is planning done? Are there milestones or releases planned for the future? Is planning any different when working with your mentor than other people (not in any class) working on the project? * What forms of communication are used in your project? Describe any email lists, wikis, etc. in frequent use. Is your communication with your mentor different than typical interactions in the project? * What coding guidelines are followed by your project? Provide a reference or link to them. * What process must be followed to check code into a repository? * How is quality assurance done? Are code inspections/reviews used? How and when? Are there checklists for code inspection? How is testing done--are there standards you are supposed to follow in writing tests? Are there tools or libraries used for testing and inspection? Does the QA process include any static analysis tools? * What is the lifecycle of a bug? What stages does it go through in the bug tracking system? Is the development process different for features? NOTE: Answer as many of these as you can on your own. If you simply ask your mentor all of these questions you *will* annoy them, and I do not want to hear them complaining to me about this assignment. Instead, it is your responsibility to be proactive, and look at project documentation and tools to find out how the project works. It is OK if you get more details on some parts of the process than others; just talk about what you can find. If you do ask your mentor questions about process, make sure the questions are (A) relevant to your own work on the project, and (B) information that it is hard for you to get yourself. After answering these questions, think about *why* the process might be the way it is. Are there ways in which the process matches the domain of the software, or the people involved, or the tools being used, particularly well? Deliverables: Presentation or Report ------------------------------------ One of the goals of this class is that you not only learn about your open source project, but you learn from other students' experiences in their projects. Therefore, each group will give one presentation in class: once at some point during the semester, and once during finals week. Because 12 presentations on process may take a long time and may overlap significantly, we have decided that only 1/3 of the teams will present on this topic. The other 2/3 of the teams will write a process report (in lieu of a presentation) and then present later on a different topic, either architecture or quality assurance. The teams to present will be chosen by a bidding process. Only the first 4 bids to present, made as replies to the "Process Presentations" Piazza post will be accepted. Just post and say your team would like to present on this topic. If there are not enough bids by the noon on Thursday, January 23, we will assign teams to present. The details of the presentation or report are as follows: * Project presentation. Note: if you want to do this option *YOU MUST BID FOR IT* (see above--or be assigned to it if there are not enough bids). In this option, you will prepare a presentation of about 10 minutes (12 minutes maximum) describing the process used in your project. We suggest that you provide an overview of all the key areas of process, then focus in on one area you think is particularly interesting. That way your audience can get a good general impression but also interesting details. You will present in class on Tuesday, January 28. Be prepared for about 5 minutes of questions from the instructors and other class members. * Project report. In this option, you will prepare a report whose length is approximately 1 page + 1 extra page per person in the group (e.g. group size 2 = 3 pages, group size 3 = 4 pages).