User:GBraught

Revision as of 15:47, 1 June 2016

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