User:Sdekhane

Latest revision as of 10:05, 7 February 2017

Sonal Dekhane is an Assistant Professor of Information Technology at Georgia Gwinnett College (GGC). She is heavily involved in curriculum development and program assessment at GGC. Dekhane is committed to providing an authentic learning experience to her students. To meet that goal her software development class includes an interdisciplinary real world project where the students practice all stages of SDLC working with a real client on a regular basis and participating in activities such as client interviews, prototyping sessions, peer review sessions, usability testing with end users, etc. She is looking forward to revamp this course using knowledge gained through the HFOSS community and workshop. More information about Sonal Dekhane can be found here.

IRC Conversation Answers

• How do people interact?

The interaction among people on IRC seems very casual.

• What is the pattern of communication?

It reminds me of instant messaging. When addressing someone specific, their IRC name along with a colon is used. For example: "joanie: newbie question about GIT"

• Are there any terms that seem to have special meaning?

The commands start with a #. For example: #topic

• Can you make any other observations?

The text following the commands seems to be part of meeting notes.

Project Anatomy Activity

The Sugar Labs Project: Community

• The activity team is responsible for creating and maintaining educational activities that are collaborative and constructivist. They are also responsible for recruiting activity mentors and collaborating with the Education team to create their activities. Finally, this team is responsible for gathering feedback on the use of these activities in the field. Apart from creating the activities this team also has maintainers and testers to ensure the quality of the activities created.
• The development team is responsible for developing and maintaining the core Sugar environment. They work in conjunction with the design team and the testing team.
• The documentation team is responsible for creating and maintaining project documentation such as user manuals, programmer's references and tutorials.

One of the common things that struck me between these teams is that they collaborate with some of the other teams. All of the teams welcome participants and provide plenty of resources on their wiki pages to support their participants.

The Sugar Labs Project: Tracker

The categories listed on this page are Immediate Priority, Urgent Priority, New Blocker Bugs and New Easy to Fix Tickets. For each ticket in the Immediate and Urgent category, information about the ticket number, component, summary of the issue, status, owner, type and severity is available. For the New Blocker Bug category the status and owner information is missing. This information is also missing for the New Easy to Fix category, but this category has an additional column for Priority.

The Sugar Labs Project: Repository

It seems to be a web-based common repository.

The Sugar Labs Project: Release Cycle

The roadmap update at the beginning of each release cycle basically outlines what will be the delivered at the end of the release cycle and when will it be delivered.

The Sahana EDEN Project: Community

• The developers page seems shorter as compared to the Sugar Labs page. All of the information is still provided to the developers, but is linked from the main page, while keeping the main page short and clean. Developers can click on one of the many links to join the mailing list or install the development environment, refer to tutorials and pick a coding task. Experienced developers also have opportunities to work on bigger projects. The developers are required to sign a Contributor's License Agreement before contributing their code. I did not find this on the Sugar Labs Development team page.
• The testers page seems to outline the tools used and the rules to follow. It also provides bug reporting guidelines.
• The designer page specifies the tasks that designers can contribute to and the guidelines that they can follow.

On both the projects different teams might be using different tools, but basically the tools allow them to collaborate, communicate and manage software development. Personally, I felt as if the Sugar Labs had more information readily available on their wiki pages than the Sahana project.

The Sahana EDEN Project: Tracker

The Sugar Labs project had all relevant information about each ticket easily available on a single page. On the Sahana project, the bug tracker page lists different categories of bugs such as Active, Showstoppers on Trunk, etc. A list of tickets is displayed when we click on one of the categories. Information about status, owner, priority, created, type version, component and summary is available for each ticket on this page.

The Sahana EDEN Project: Release Cycle

The roadmap page for the Sahana project lists the various key features required for each release cycle. It clearly shows the current progress of the project, indicating whether the project is on time or not. It also shows the number of tickets closed and active for the current release cycle. The release cycle and roadmap page for the Sugar Labs did not have such detailed information for each release cycle available on the main page.

IRC Activity

On this channel, people reported changes they made and asked others to review and provide feedback. They also discussed various solutions to a problem so as to pick the right one. Some people asked for and reported status on presumably a module (deftest01) and then discovered why some modules were not starting based on their communication. Someone (probably new) introduced themselves and said what they were going to work on. The failure of some modules to start up was communicated to other people who joined the IRC channel later.

FOSS in Courses (Possible/applicable ideas)

• Introduction to FOSS (Reading activity, Cathedral and Bazaar)
• Tools (IRC channels, planets, blogs, etc.)
• Evaluate a couple of HFOSS projects
• Contribute to documentation and create examples showing usage of features
• Fix bugs

Bug Tracker Activity: Bug Reports

Column name definitions

1. ID: Indicates the bug number (unique bug identifier).
2. Sev: This field describes the impact of a bug. Severity values can be blocker, critical, major, normal, minor, trivial and enhancement.
3. Pri: Indicates priority of the bug. This field describes the importance and order in which a bug should be fixed Values can be urgent, high, normal, low
4. OS: Indicates the operating on which the bug was detected or feature requested. Values can be all, Linux, Open Solaris, Solaris, Mac, Windows or other.
5. Product: Indicates the products of the software in which an issue was detected or a feature/patch is being requested. The values have to be product names of the software. For GNOME desktop values can be aiselriot (games), buoh (online reader for comic strips), gevice (tool for administration of network device), pan (newsreader), zenity (displays dialog boxes from commandline), etc.
6. Status: Indicates general health of a bug. Values can be unconfirmed, new, assigned, needinfo, reopened, resolved and verified and closed.
7. Resolution: Indicates what happened to the bug. Values can be blank, fixed, duplicate, wontfix, notabug, notgnome, incomplete, invalid, obsolete
8. Summary: Gives a brief summary of the issue.

How was the definition found

When I went to the page showing list of bugs, I clicked on the first bug. As I scrolled down values for different columns for this specific bug were provided. The column names were hyperlinked and when I clicked on those hyperlinks I found their definitions and values.

Meaning of colors of bugs

The red bold bugs are blockers (very high severity), the critical bugs are in red and the enhancements (lowest on severity list) are in gray. Everything else is in black.

Bug 1 details

1. The bug was submitted on 5th June 2012.
2. There hasn't been any recent discussion on the bug. The last comment was posted on 23rd August 2012.
3. The status of this bug is unconfirmed. So it has not been validated. There is no resolution status specified as well. It seems like an old bug, but it is not closed. One of the solutions submitted was committed, but the ticket is not closed. So it is current.
4. The bug is assigned to gnome-shell-maint.
5. To fix the bug I would have to look at the code and modify it so that the appropriate label is assigned a name. The attachments and comments provided by other volunteers provide some idea of what the problem is and what needs to be done.

Bug 2 details

1. The bug was first reported on 23rd Feb 2010.
2. Yes. There has been recent discussion on this bug. The last comment was posted on 30th April 2013.
3. The bug seems current. One of the submitted patches was recently accepted but not committed yet. Although the status does not indicate that the bug is verified and closed.
4. The bug is assigned to Nautilus Maintainers.
5. To fix the bug, I would have to recreate the bug, find the appropriate code and modify it so that the tooltip is set to "search".

Bug Tracker Activity: Collective Reports

1. 405 reports were opened in the last 7 days and 509 reports were closed.
2. It looks like more reports were closed than were opened.
3. André Klapper, Florian Müllner and Timothy Arceri were the top 3 closers. It is good to know who the top closers are as they can be good resources of information.
4. Adam Dingle, Stef Walter and Matthias Clasen are the top 3 reporters. These are not the same as the top 3 closers. The second and the third reporter are in the list of top 15 closers. There is some overlap in the two lists.
5. Stef Walter, Jasper St. Pierre and Debarshi Ray are the top 3 contributors of patches.
6. Jasper St. Pierre, Sebastian Dröge and Owen Taylor are the top 3 patch reviewers. Some of the bug closers and bug reporters have also acted as patch contributors and patch reviewers. The second top patch contributor is also the first top patch reviewer.
7. Apart from different types of graphical reports you can also create tabular reports. For example you could plot the priorities of specific products. You can also create a report of frequently and recently duplicated bugs and frequently duplicated stack traces.