User:Ssheth

Swapneel Sheth

Swapneel Sheth is a Lecturer in the Computer and Information Science department at the University of Pennsylvania.

His research and teaching interests are Software Engineering, Privacy, and the Web.

Stage 1 Part A

Intro to IRC

Part 1

1. How do people interact?
   • In an informal manner
2. What is the pattern of communication?
   • Usually question and answer - somebody has a question or a problem, other tries to help solve it
3. Are there any terms that seem to have special meaning?
   • The chat bot commands
4. Can you make any other observations?
   • It's nice to have the meeting transcribed by meetbot in a relatively easy manner, with annotations

Part 3

I've been following the #ushahidi channel periodically, but it seems to have very little activity.

I've looked at other interesting (to me) open-source channels - #rvm, #ruby-lang, #rubyonrails. These are a lot more active and seem to have two kinds of questions.

1. I'm stuck.. help me with X
   • In this case, people are trying to install/work with some software/framework/library and getting error messages. This seems like a faster, 90s version of StackOverflow for people to get answers.
2. What is a good way to do X?
   • In this case, people are unsure what's a "good" (optimal, efficient, faster, better) way of doing something - A or B. They want advice from the more-seasoned users in the channel. Comparing to StackOverflow, I see this as a big advantage as something "subjective" is not a good question to ask on StackOverflow.

Anatomy of a FOSS Project

The Sugar Labs Project

• Community
  1. Activity Team
     • Develops and Maintains the activities; recruits developers.
     • There are 2 coordinators and a lot of contributors.
  2. Development Team
     • Builds and Maintains the core Sugar Project.
     • There is no coordinator and four people (assuming they're contributors?) listed
  3. Documentation Team
     • Provides high quality documentation (learner's manual, programming references, and tutorials).
     • There is no coordinator here as well and two editors with their areas of speciality listed.
• Tracker
  1. Types/Categories of Tickets
     • Defect, Enhancement, Task
  2. Information available for each ticket
     • The usual bug tracking categories - reported by, priority, component, severity, cc, bug status, owned by, milestone, version, keywords, distro/os, description, change history, timestamps.
• Repository
  • Web-based common repo, but it's git so everything is distributed and everyone has a "local repo".
• Release Cycle
  • The roadmap is updated at the start of each release cycle. Each release cycle contains development, beta, RC, final releases.

The Sahana Eden Project

• Community
  1. Developers
     • This is for people interested in contributing to the development effort of Sahana or for those who want to use Sahana in their own projects.
     • Unlike Sugar Labs, names and roles are not mentioned.
     • Training and guidelines are provided here.
  2. Testers
     • They want three types of testers - non technical users, developers, sysadmins.
     • Again, names and roles are not mentioned.
     • Training and guidelines are provided here as well.
  3. Designers
     • This is for graphic designers who have experience in CSS and HTML.
     • Training and guidelines are provided here as well.
• Tracker
  1. The default page shows reports, instead of tickets.
  2. Types/Categories of Tickets
     • Defect/Bug, Enhancement, Task, Documentation
  3. Information available for each ticket
     • They use Trac as well - so most of the information is similar as Sugar Labs. Reported by, priority, component, keywords, due date, cc, owned by, milestone, version, launchpad bug, description, attachments, change history, timestamps.
• Repository
  • Web-based common repo.
• Release Cycle
  • The current milestone (0.9 Medway) is 90% complete and 3 years late. It still a number of open tickets.
  • The future milestones (1.0 Avon and 2.0) don't have a date set, but they describe the key features required.

Stage 1 Part B

Project Evaluation Activity

File:Mifos Eval.xlsx

FOSS in Courses Activity

Here are a couple of activities I would like to use my class. I didn't find any existing material.

1. Mining Software Repositories (MSR) has become a very popular research topic. For a seminar-style class where students read MSR papers, we could use FOSS projects as case studies. Some examples of questions we could try answering and compare two projects:
   • Do bugs get fixed faster?
   • Are there better tests?
   • Is the code 'better' - more readable, better designed, etc.?
   • Is there a correlation between the above?
   • When do code commits happen?
   • What are the processes for merging in patches/bug fixes? (E.g., do smaller bug fixes in terms of LOC get merged in faster than larger bug fixes)
   • Who collaborates with whom?
   • ...
2. Using data from FOSS projects and combining them with other data sets can lead to very interesting mashups, data visualization, etc. It would be interesting to do this in the context of a class.

Stage 1 Part C

Bug Tracker Activity

Part 1 - Bug Reports

• Column Names, Meaning, Range of Values
  1. ID
     • Unique ID for the bug
  2. Sev
     • Severity: the impact of a bug
     • Values: Blocker, Critical, Major, Normal, Minor, Trivial, Enhancement
  3. Pri
     • Priority: the importance and order in which a bug should be fixed
     • Values: Immediate, Urgent, High, Normal, Low
  4. OS
     • Operating System
     • Values: All, AIX, BSDI, Cygwin, etc.
  5. Product
     • The Product that is affected by the bug
     • Values: accerciser, accountsdialog, acme, etc.
  6. Status
     • The General Health of the bug
     • Values: Unconfirmed, New, Assigned, Needinfo, Reopened
  7. Resolution
     • What happened to this bug
     • Values: Fixed, Duplicate, Wontfix, Notabug, Notgnome, Incomplete, Invalid, Obsolete
  8. Summary
     • The summary of the bug
• How did you discover the definitions and find the information?
  • Using the reports link
• Order of bugs
  • Sorted by id
• Meaning of shading
  • Enhancements are greyed out
• Meaning of colors
  • Red - Critical or blocker bugs; Grey - enhancements; Black - others
• Bug Details - id 545284
  1. When was the bug submitted? 2008-07-29 09:02:45 UTC
  2. Recent discussion? No, last in 2009
  3. Current bug? Yes
  4. Bug Assigned? Yes, to empathy-maint
  5. Steps to fix the bug? Use the last suggestion from the developer - open a bug with GDK, have that fixed, and use the fix for this bug
• Bug Details - id 648260
  1. When was the bug submitted? 2011-04-20 00:01:41 UTC
  2. Recent discussion? Yes sort of, last in Jan 2014
  3. Current bug? Yes
  4. Bug Assigned? Yes, to ATK maintainer(s)
  5. Steps to fix the bug? There is discussion about whether this needs to be fixed or not. Wait for the resolution of that as the bug is "unconfirmed" right now.

Part 2 - Collective Reports

1. How many bug reports were opened in the last week? How many were closed?
   • 346 opened and 469 closed
2. What was the general trend last week? Were more bugs opened than closed or vice versa?
   • More bugs were closed
3. Who were the top three bug closers? Why is this important to know?
   • Bastien Nocera, Jean-Francois Fortin Tam, Milan Crha. This will give you an idea of the people active in the project right now.
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, Debarshi Roy, Marc Deslauriers. They are not the same and there is some overlap between the two lists.
5. Who are the top three contributors of patches?
   • Jonas Danielsson, Debarshi Roy, Cosimo Cecchi
6. Who are the top three reviewers of patches? What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers?
   • Sebastian Droge, Florian Mullner, Rui Matos. There is some overlap between patch reviewers and patch contributers. There is a higher overlap between bug closers and patch reviewers.
7. What other reports can you generate?
   • Lots of other reports

FOSS in Courses 2

Activity 1 - Mining Software Repositories

1. Identify the ways that these FOSS activities/topics can be structured.
   • Combination of lectures, in-class activity, and homework
2. Learning Outcomes
   • The main learning outcomes would be understanding how software engineering happens in real-world, geographically distributed projects.
3. Pre-requisite knowledge
   • Basics of software engineering, basics of how to mine a software repository.
4. 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.
   • Instructor Prep - 15 hours; Student completion - will be split over 2 weeks of class, in-class activities and one individual homework.
5. Think about possible input required from the HFOSS community. How much input is required and what kind?
   • Very little input required in this case - would be nice to have feedback on projects that would be "better" to use.
6. If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness.
   • N/A
7. 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?
   • Individual homework, could potentially be part of larger team project. The nice part with this is that very little input is required from the HFOSS community. It would help to do studies to see what kinds of questions they have and how we can answer them.
8. Questions, Concerns, Stumbling Blocks, Barriers
   • Identifying appropriate projects would be the biggest stumbling block. The assumption is that the projects provide APIs for the bug repos, etc. so things can be automated. The assumptions also is that code is hosted on github or something similar, where we can look at version history (again using tools to automate the process).

Activity 2 - Using data from FOSS projects

1. Identify the ways that these FOSS activities/topics can be structured.
   • For this activity, teams would use data from projects like Ushahidi and combine that with other data sources like data.gov to create interesting mashups, data visualizations, etc. This would primarily be a team project over 6-8 weeks.
2. Learning Outcomes
   • The main learning outcomes would be using real-world data in the context of a software engineering or web programming class.
3. Pre-requisite knowledge
   • Basics of software engineering or web programming, basics of databases.
4. 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.
   • Instructor Prep - 5 hours; Student completion - team project lasting 6-8 weeks.
5. Think about possible input required from the HFOSS community. How much input is required and what kind?
   • Very little input required in this case - would be nice to have feedback on projects that would be "better" to use.
6. If the result of the activity is contributed back to the HFOSS project, describe the contribution and its usefulness.
   • The contribution would be open source projects (possibly hosted on github, deployed on heroku) that do interesting things with the data.
7. 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?
   • This will be a team (of 2-3 students) activity. The grading will be on factors like: quality of software developed, quality/quantity of software artifacts produced, novelty of idea, etc. It would be nice to have the HFOSS community help assess/vote on the team projects (and maybe use this as part of the grading criteria). Because the code will be open source, the community can use/build upon these projects.
8. Questions, Concerns, Stumbling Blocks, Barriers
   • N/A