User:GBraught

Grant Braught is a Professor of Computer Science in the Department of Mathematics and Computer Science at Dickinson College. The computer science program at Dickinson currently has 3.5 faculty members and 67 students as declared majors.

Grant's research interests include: Computer Science Education; Effects of tool design and pedagogy on student learning in introductory courses; Development of software tools for teaching bio-inspired artificial intelligence and robotics; Bio-Inspired Artificial Intelligence and its applications; Artificial life; Interactions between learning and evolution; The evolution of evolvability; Co-evolutionary systems; Swarm algorithms; Evolutionary and developmental robotics.

Outside of academia Grant enjoys golf, skiing, volleyball, craft beers, cooking and eating ethnic foods, Penn State Football and Norwich City FC.

Intro IRC Activity:

• How do people interact?

Interaction is via text messaging. In specific interactions between individuals they call each other out by name, which is necessary to infer who is talking to who.

• What is the pattern of communication? Is it linear or branched? Formal or informal? One-to-many, one-to-one or a mix?

Overall conversation is linear with darci mediating and calling on each in turn for updates. Within each update the communication is often many-to-one, with multiple users providing thoughts, input, suggestions and questions related to the updates.

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

There is a ton of jargon related to the project specifics and context that is being carried along from past meetings, emails and/or discussions amongst the team.

The #info, #action and #topic tags appear to be commands to the bot that is logging the meeting. Looking at the minutes later it is clear that these tags log information into the meeting minutes.

• Can you make any other observations?

The conversations can be very difficult to follow when they become many-to-one and many-to-many as each line is difficult to connect to the prior lines to which it is responding. Perhaps this is easier with the context of past meetings and when participating with familiar collaborators in real time.

• Bonus question: Why didn't Heidi and Darci's actions get picked up by the meetbot?

The #action lines use "Heidi" and "Darci" which the bot did not match to their usernames "heidi" and "darci" as was done for "amber". Thus, these action items remain unassigned.

Project Anatomy Activity: Guided Tour

Sugar Labs Project

• Contributions: Summarize the roles that you think would be most applicable for your students on your faculty wiki page. If you think that more than a single role is applicable, indicate why. What are the commonalities across roles? What are the differences?

The Developer role would be most applicable for our students. We are looking for them to interact with a developer community, gain experience with an existing code base, tool chain and work flows.

• Tracker: On your wiki page describe the general process for submitting a bug and indicate the types/categories of tickets listed on this page as well as the information available for each ticket.

A ticket should be prepared on the trac instance and then if braod attention to the issue is desired it should be announced with a link on the sugar-devel list serve.

Tickets appear to be classified as either "defect" or "enhancement". Information is also available such as a summary of the issue, the status of the ticket (new/accepted/assigned/reopened/closed), who created the ticket (reporter), who owns (i.e. is responsible for) the ticket, the priority of the ticket and the milestone by which the ticket is targeted to be addressed.

Significant additional information is available by clicking through to the ticket specific page. In particular, the full Description and the Change History would be valuable to a developer working on the issue.

• Repository: Can you determine from the information provided here whether the project uses a web-based common repository or a local repo?

The repo is hosted by Gitorious, which provides free hosting for git based open source projects.

• Release Cycle: Include an entry on your wiki page that describes how the release cycle and roadmap update are related.

The roadmap is updated by the development team at the start of each release cycle. The release cycle goes through development, beta, release candidate and final release versions.

Sahana Eden Project

• Community: are there any commonalities? Is there something distinct for each type of contributor? How is this structure different than the one you found on the Sugar Labs website?

The "get started straight away" section is a nice addition and makes it easy to quickly find something to work on. It is nicely divided into code/documentation/outreach/QA/UI tasks. For students and use in a class the "Easy Bugs to Fix" section is a great feature.

In general there seems to be extensive support for new developers including documents and video training. This should make it easier to get rolling with Sahana than many other projects.

• Tracker: How is the information here different than the information found on the Sugar Labs tracker page?

The information in the "Active Tickets" report is very similar to that in the Sugar Labs tracker. The most notable difference is that tickets are associated with particular components. This will allow developers to more quickly identify tickets to which their expertise may be best applied. Each ticket's creation date is also displayed in the report, making it easier to identify both new and old issues.

The immediate availability of a variety of commonly useful reports (e.g. Active Tickets, Easy Bugs, Feature Requests, etc) may be useful as well.

• Repository: Can you determine from the information provided here whether the project uses a web-based common repository or a local repo?

To install Eden git is used with a repository location on ghithub.com. Thus, this project uses a web-based common repository for the trunk. Developers fork the repository, make changes to their local repository, contributing changes back when complete.

• Release Cycle: Information about Sahana Eden's release cycle and roadmap can be found here. Include an entry on your wiki page that describes the information you find here.

The first thing that jumps out is that the milestone 0.9.0 "Medway" is "4 years late", though not particularly surprising or concerning, given the nature of the project. Plans for several future milestones are laid out in bulleted lists of the key features and tickets are tracked with respect to which milestone to which they apply.

FOSS In Courses Activity

• 3.1 - Identify activities or topics that you are interested in within your HFOSS project of interest. This can be a rough list and can serve as the basis for identifying possible class activities/topics.

My interest is primarily in designing a senior capstone course in which student groups select and work on an H/FOSS project. My current hope is that students will be able to select their own projects and that groups will be working on a variety of projects. Thus, in thinking about this question, I was thinking about the types of activities or topics that might be applicable across a wide range of H/FOSS projects rather than a specific one. Even more specifically, I was focused on the early part of the course in which the students are getting up and running with their projects and what activities could be assigned to ensure that they are making progress and preparing adequately for a large capstone experience with their project. The primary things that came to mind were:

• Blogging: Having the groups (or possibly individuals) maintain a blog that documents their work on the project. Some postings would be assigned with specific content to be addressed and others would be current thoughts/challenges/resolutions/etc.
• Install: Follow install process and evaluate documentation. Possibly including improvements to the install documentation.
• "Connecting": Connect with the project community through several channels (IRC/Wiki/Mailing List, etc) and comment on observations.
• Licensing: Study an open source license and possibly compare/contrast with another or engage in class discussion of tradeoffs.
• Examples: Run examples given in project and evaluate illustrative value and documentation. Possibly produce another example.
• Bugs: Review bug tickets. Try to reproduce old bugs. Identify good and bad bug reports, compare/contrast. Improve bad bug report.
• Code Documentation: Identify 2 sections of code, one well documented, one not. Describe purpose of each. Compare/contrast. Improve the poorly documented section.
• Tests: Run a code coverage tool to identify untested code. Write a test that covers it.
• Patch: Fix, or attempt to fix, a reported bug.
• Plan:: Develop a plan for the group's activity for the remainder of the capstone experience. Write a proposal and present it.

• 4.1 - Now that you have an idea of the possible types of activities or topics, identify one or two that you think would fit in your class. These do not need to be polished. This can be a rough list of ideas.

• Project Identification: Individually identifying FOSS projects of interest. Give some guidelines, but not a full evaluation process yet. This would be useful for having them identify potential group members based on areas of common interest. The goal would be to form into groups of 2-6 on a given project based on common interests.
• Project Evaluation: Documenting (on their blog) "FOSS Field Trips" for 2-3 projects of interest to the group to help them select from among those of interest to the group.
• All of those listed above: Blogging, Licensing, Install, Connecting, Examples, Bugs, Code Documentation, Tests, Patch, Plan.

• 4.2 - In your reading, did you find existing materials? If so, describe how would you modify them to fit your class?

• There were quite a number of useful existing materials that could be modified for use in my course. The modifications to them would be on an assignment by assignment basis and I have not delved into them deeply enough at this point to propose specific modifications. Still thinking big-picture. I imagine following a structure similar to:

• Independent_Capstone_Project_Design

• Two other full FOSS courses will also likely be useful in planning the overall structure of the course:

• Complete_10_week_HFOSS_Course
• RIT/The_Course

• Some additional materials from the foss2serve site that I imagine will be useful in building the assignments for my course include:

• Project Identification and Evaluation:

• Intro_Project_Identification_Activity
• FOSS_Field_Trip_Activity

• Licensing:

• Choosing_A_License

• Install and evaluate directions:

• Introduction_to_building_open_source_software
• Test_Installation_Instructions
• Linux_Beginner_Activity
• Bash_Activity
• Why_Use_Version_Control

• Connecting with Project Community:

• Getting_connected_with_the_community
• Intro_IRC_Activity
• Open_Source_Communication_Activity

• Examples:

• Nothing found here...

• Bugs:

• Research_Bug_Activity
• Bug_Gardening
• Writing_a_bug_report
• Bug_Tracker_Activity
• Bug_Tracker_Activity-MouseTrap

• Code Documentation:

• Document_code_with_meaningful_comments
• Finding_the_Code_Responsible_for_Behavior

• Tests:

• Test_Coverage_Activity

Bug Tracker Activity

Part 1 - Bug Reports

2. Define what each of the column names below indicate. Include the range of possible values for 2-7 below.

• ID - Unique numeric identifier for each ticket.
• Sev - Indicates the severity of the bug and/or whether it is an enhancement.
• Pri - The priority of the bug as set by the developers.
• OS - The operating system(s) on which the bug has been observed.
• Product - Which software product contains the bug. Useful in projects that have multiple products. Distinct from component within a product.
• Status - Indicates the current state of a bug (ticket), values include: Unconfirmed, New, Assigned, Reopened, NeedInfo, Resolved, Verified
• Resolution - Indicates what happened to the ticket (how it was resolved), values include: Fixed, Invalid, WontFix, Duplicate, WorksForMe
• Summary - A short (one sentence, tag-line) description of the bug.

3. Describe how you discovered the definitions and how did you find the information from above

• GNOME Bugzilla - Bugs Field Page
• GNOME Bugzilla - Search for bugs Page

4. Identify the order in which the bugs are initially displayed?

• The bugs are initially ordered by status (Unconfirmed, New, Assigned, Reopened, NeedInfo)

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

• This is a poorly documented feature of the tracker and I was unable to discern any significance in a reasonable amount of time.

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

• Red appears to correspond to an importance tag of "critical" or "blocker"
• Gray appears to correspond to an importance tag of "enhancement"
• Black appears to correspond to an importance tag of "normal" or "major"

7. 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: Bug 704330

1. Identify when the bug was submitted.

• Reported: 2013-07-16 15:07 UTC by Kamil Páral

2. Identify if there has been recent discussion about the bug?

• Most recent discussion appears to be from an IRC conversation and was posted when the bug was reported.

3. Is the bug current?

• The bug ticket was last modified in 2014 so may not be current.
• It applied to version 3.8.x of the product evince (a document viewer), the current stable branch is 3.20, so may not be current.
• Would need to confirm by installing and testing to see if the issue still exists in current version.

4. Is the bug assigned? To whom?

• Assigned To: Evince Maintainers
• Seems likely to be a placeholder for tickets that have not been assigned to individual developers.

5. Describe what you would need to do to fix the bug.

• Confirm existence in most recent version.
• Identify how similar features are implemented in the source code (e.g. how button mnemonics are assigned).
• Initiate further conversation about how this feature might be implemented - make a specific proposal for discussion.
• If consensus can be achieved, make the improvement and submit pull-request.

8. Repeat the previous step with a different kind of bug.

• Bug: Bug 723296

1. Identify when the bug was submitted.

• Reported: 2014-01-30 15:47 UTC by Joanmarie Diggs (IRC: joanie)

2. Identify if there has been recent discussion about the bug?

• Most recent discussion appears to be a marking of another ticket as a duplicate of this one. There appears to be further discussion on the duplicate bug page that might be of use.

3. Is the bug current?

• The bug ticket was last modified in 2014 so may not be current.
• The version of gnome-calculator to which this bug applies is not documented, so it may not be current.
• Would need to confirm by installing and testing to see if the issue still exists in current version.

4. Is the bug assigned? To whom?

• Assigned To: gcalctool maintainers
• Seems likely to be a placeholder for tickets that have not been assigned to individual developers.

5. Describe what you would need to do to fix the bug.

• Confirm existence in most recent version using the well articulated steps for reproducing the bug. This would require figuring out how to "Launch gnome-calculator in a non-english environment"

• Identify how internationalization is implemented in the source code (e.g. how it is done for other apps or within the calculator app for the parts that work).
• Initiate further conversation about how this feature might be implemented - make a specific proposal for discussion.
• If consensus can be achieved, make the improvement and submit pull-request.

Part 2 - Collective Reports

3. How many bug reports were opened in the last week? How many were closed?

• 280 reports opened and 324 reports closed. Including enhancement requests

4. What was the general trend last week? Were more bugs opened than closed or vice versa?

• See #3.

5. Who were the top three bug closers? Why is this important to know?

• Matthias Clasen, Michael Gratton, Tim-Philipp Müller.

6a. Who were the top three bug reporters?

• Bastien Nocera, Allan Day, Simon McVittie

6b. Are these the same as the top three bug closes?

• No, there is no overlap in these lists.

6c. What is the overlap in these two lists?

• See 6b.

7. Who are the top three contributors of patches?

• Bastien Nocera, Sebastian Dröge (slomo), Michael Olbrich

8a. Who are the top three reviewers of patches?

• Sebastian Dröge (slomo), Matthias Clasen, Nicolas Dufresne (stormer)

8b. What is the overlap between these lists and the bug closers and bug reporters?

• Matthias Clasen is a top bug closer and a top patch reviewer.
• Bastien Nocera was top a top bug reporter and a top patch contributor.

8c. What is the overlap between patch contributors and patch reviewers?

• Sebastian Dröge (slomo) is both a top patch contributor and top patch reviwer.

11. What class were the majority of the bugs for braille?

• All bugs for braille in orca are of class "Application", 29 of them.

12. What other reports can you generate?

• Tons of them. This seems to be a very powerful and easy to use reporting engine.
• One of particular interest for student projects is the "Bugs marked by developers as being good tasks for new developers" under "For Potential Contributors" on the main Reports page.

FOSS in Courses Planning 2

• Outline for first semester Senior Capstone Course using FOSS (COMP491Outline.pdf - link to file on dropbox). Currently there is a course outline with the first two class meetings fairly well specified, though the particulars of the assignments need to be worked out. Looking forward to being able to bounce ideas for these assignments and the larger course structure off of others at the meetings next week.