User:Relkharboutly

Revision as of 18:59, 12 November 2014

Ruby ElKharboutly is an Assistant Professor of Software Engineering at Quinnipiac University. The Software Engineering Program is offered in the newly established School of Engineering. Dr. Ruby's research interests include software design and architecture, reliability and performance and software data analysis. Prior to joining Quinnipiac, Dr. Ruby was a full-time Professor at University of Connecticut. She has four years of industrial experience working as a software engineering and IT consultant. In her spare time, Dr. Ruby is mostly spending time with her kids, in the kitchen or at the gym.

Introduction to IRC

• How to people interact? By sending instant messages to all meeting participants.
• What is the pattern of communication? No specific pattern. It seems to be a long meeting where each participant sends a message whenever they have something to say.
• Are there any terms that seem to have special meanings? Yes, all the hash tags such as #info, #action, #topic,
• Can you make other observations? The time stamp, text after hash tags is bold.

Intro to Project Anatomy

Sugar Labs Project

Teams: Each team has a mission and specific set of responsibilities. Team pages are structured differently for each team.

Bugs: Each ticket has a number, summary, status, owner, type priority and release milestone. Bugs belong to components and are categorized according to priority, severity and bug status.

Repository: Web-based or local? web-based

Release cycle: The roadmap is updated at the beginning of each release cycle

Sahana Eden Project

Teams

Developers: Developers can review the BluePrints of the project including requirements and design. They can create User Story/Use Case as well. Complete instructions are included in the "Developer Guidelines" to introduce new developers to the project

Testers : Testers can assist as non-technical users by following the QA process documented on the wiki. They can report issues using Bug Reporting Guidelines. Developers can test their code as well by following Developer/Testing Guidelines. Finally, SysAdmins can set up a server by following the Continuous Integration process.

Designers: Designers can help make the application and the web site more usable. Guidelines for themes and usability are available on the website.

Bugs: Tickets are in the form or reports. Each ticket is structured in the same way as in the Sugar Lab Project

Repository: Web-based or local? local

Release cycle: The roadmap includes key features, modules and supported material

Project Evaluation Activity

Evaluation : File:Mifos-Eval-ElKharboutly.xlsx

FOSS In Courses Activity

I am interesting in the design and architecture of the FOSS projects in general. To be able to reverse engineer a project and model the design. To evaluate the design and suggest improvements. My students are using FreeMind this semester to map the design and architecture. I could have benefited form the project evaluation activity to help students understand the project.

Bug Reports

Part 1-Bug Reports:

1. Define what each of the column names below indicate. Include the range of possible values for 2-7 below. Feel free to explore beyond the page to find more information.
   1. ID : Bug Identifier
   2. Sev : how server the bug is. blocker to trivial/enhancement
   3. Pri : used by bug assignee to prioritize his/her bugs
   4. OS : Platform
   5. Product : Project or component to which the bug belongs
   6. Status : the current bug status UNCONFIRMED, NEW, ASSIGNED, REOPENED, NEEDINFO
   7. Resolution : Is left empty for this product
   8. Summary : description of the problem
2. Describe how you discovered the definitions and how did you find the information from above? I am vary familiar with bugzilla since I had attempts to data mine and analyze some of the bug repositories a couple of years ago. I went to the help page for extra information
3. Identify the order in which the bugs are initially displayed?

They are ordered by status

1. What is the meaning of the shading of some bug reports?

1. What is the meaning of the colors used when describing a bug (red, gray, black)?

red : Critical gray : Enhancement Black : Others

1. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number).

Bug 81041

1. 1. Identify when the bug was submitted.--2002-05-07
   2. Identify if there has been recent discussion about the bug? -- None
   3. Is the bug current? Reponed
   4. Is the bug assigned? To whom? Panel Maintainers
   5. Describe what you would need to do to fix the bug. Turn Autoshow on for hidden panels

Bug 437481

1. 1. Identify when the bug was submitted.--2007-05-10
   2. Identify if there has been recent discussion about the bug? -- 2011
   3. Is the bug current? Assigned
   4. Is the bug assigned? To whom? ATK maintainer(s)
   5. Describe what you would need to do to fix the bug. Append documentation to explicitly specify which classes need to be completely implemeted.

Part 2 - Collective Reports

1. How many bug reports were opened in the last week? How many were closed? 46461
2. What was the general trend last week? Were more bugs opened than closed or vice versa? more closed bugs than open
3. Who were the top three bug closers? Why is this important to know? Matthias Clasen, Michael Schumacher,Jim Nelson indicates how much they contribute to the project
4. Who were the top three bug reporters? Are these the same as the top three bug closes? What is the overlap in these two lists? Jo, Michael Catanzaro, Bastien Nocera. Some programmers report bugs while testing the product
5. Who are the top three contributors of patches? Ray Strode,Carlos Garnacho,Marcos Chavarria Teijeir
6. Who are the top three reviewers of patches? Jonas Danielsson,Tim-Philipp Müller, Bastien Nocera
7. What is the overlap between these lists and the bug closers and bug reporters? There is some overlap
8. What is the overlap between patch contributors and patch reviewers? No overlap
9. What other reports can you generate?

FOSS in Courses 2

I would like to integrate open source development in my Software Design and Architecture class. One way would be to discuss the architecture of one of the projects and use it as a case study. For there term project, students can reverse engineer a code base and extract the underling design and architecture of the application. I would expect them to be able to contribute to the project through bug fixing or enhancements.

Learning outcomes of an term project

1. 1. Evaluate an existing project and analyze its current documentation
   2. Read and understand professionally written code
   3. Appreciate the importance of code documentation and project documentation
   4. Identify, describe and test bugs.
   5. Develop architecture and design documentation for an existing project
   6. Recognize coding conventions and design patterns.
   7. Contribute to open source development

1. 1. Describe any pre-requisite knowledge needed to complete the activity. This does not need to be a complete list.
   2. Estimate the time required for instructor prep, for student completion and elapsed calendar time. Are you going to have to synchronize your activity with the community or can the activity/topic be covered independent of the HFOSS community schedule.
   3. Think about possible input required from the HFOSS community. How much input is required and what kind?
   4. If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness.
   5. Describe the assessment/grading approach - What will the basis for grading be? Will this be a team activity or individual? Is there a role for the HFOSS community in helping assess student work? For instance, must the work be committed or otherwise accepted by the community?
   6. List any questions or concerns that you have about the activity/task.
   7. List any stumbling blocks or barriers to carrying out the activity/task.