User:Rbryant

Robert Bryant

Rob Bryant is a Professor of Computer Science and Director of the Information Technology and Society (ITEC) Program at Gonzaga University.

Professor Bryant has taught in the Mathematics and Computer Science Department at Gonzaga University for more than twenty years. In 2009, Professor Bryant became the Gonzaga Information Technology and Society (ITEC) Program Director and developed a new program in Information Technology designed to address a growing need for teaching computational thinking to undergraduate students in the liberal arts and other disciplines. His research interest are in Software Engineering and Computer Science Education.

In his 28 at years at Gonzaga Professor Bryant has received over two million dollars in grants from private and public funding agencies, and has published in both areas of research. From 2008 to 20012, as Co-PI of the Distributed Northwest Computer Science Department grant from the National Science Foundation (NSF 08-516, CISE – CPATH award # 0829651), Bryant was a liaison with high schools in Washington and Oregon to help coordinate the development of new STEM curriculum. He currently is the principle lead for a consortium of Spokane area high schools partnering with Code.org to provide professional development for mathematics, science, and career and technical education teachers who are teaching a new computing curriculum in schools begun in the fall of 2014. Professor Bryant has served as chair of the Mathematics and Computer Science Department. He is a past president of the Consortium for Computing Sciences in Colleges and currently serves at the national comptroller for CCSC. Presently he is also a Faculty Fellow for the Gonzaga Center for Teaching and Advising to promote technology integration to enhance pedagogy.

Part 1 IRC Conversation

How do people interact?

The interaction is informal and conversational with many responses immediate.

What is the pattern of communication?

The session is generally run by one person with other participants addressing the current topic or question. Users appear comfortable in introducing new topics and adding their input.

Are there any terms that seem to have special meaning?

There are IRC commands (info, action, topic, etc.) that have special meaning for the tool. The conversation includes terms specific to the topic.

Can you make any other observations?

It seems the conversation can get too focused between a couple of participants and it is good when someone else chimes in to get the meeting back on moving forward for everyone.

HFOSS observations

I am interested in both the Sahana project and the Ushahidi projects. Both efforts are focused on helping people in chaotic situations. Both projects are about 5 years old and have been successful in creating a large group of people to contribute to the effort.

The Sugar Labs Project

The three teams, Activity, Development, and Documentation, all have similar structures with positions of coordinators and contributors. The two teams of deployment and documentation lack a coordinator at the moment. All the team pages do a nice job of stating a clear mission. The contacts page for each of the teams indicate the various communication channels such as emaillists and irc channels the teams monitor. The activity team, due to the size of the contributor list, seems more active than the other two.

Tracker

The Sugar Labs bug tracker page lists the following information about each bug ticket:

Ticket number
A brief description about the ticket
Ticket status (accepted, assigned, closed, new, and reopened)
Owner (name/id)
Type (defect, enhancement, or task)
Priority (Immediate, Urgent, High, Normal, Low, and Unspecified)
Milestone (Unspecified and number)

Repository

The Sugar labs repository appears to be a local one.

Release cycle

The release cycle and roadmap are related in that the roadmap is updated upon a new release.

The Sahana Eden Project

Community

The pages for the Developers, Testers, and Designers communities are similar in providing ways to participate. The Sahana community pages differ from the Sugar Labs Team pages in that they do not list the names/contacts of the team members and specific community missions are not provided on the main community page but on other pages linked off the main community page.

Tracker

The Sahana Tracker main page provides a list of available reports/views from the tracker DB. This differs from the Sugar Labs tracker page which provided just one view of tickets.

The Active tickets page provides the following information about each ticket:

Ticket number
Summary (brief description of the ticket)
Component (subsystem involved) 
Version (trunk, test)
Priority (critical, major, minor)
Type (defect/bug, enhancement, task)
Owner (name/id)
Status (new, accepted, assigned, reopened)
Created  (date)

Repository

A web-based repository is used.

Release cycle

The roadmap provides an estimate of percent completion of milestones along with a list of tasks completed and needed to be completed.

FOSS Field Trip Activity

SourceForge

I selected the education category which had 61 projects listed.

15 programming languages were used in the various projects.
PHP, Java, C++, and Javascript were the top 4 programming languages used.
The status categories for projects appear to have the following meanings:

1. Inactive - project not currently being worked on
2. Mature - project has a lot of version releases and has been around for some time?
3. Production/Stable - project has a fairly stable version available.
4. Beta - project has a beta release available
5. Alpha - project has an Alpha release available
6. Pre-Alpha - very limited release available?
7. Planning - project is in developing stages - no download available.

Comparing a project in the planning stage vs a production/stable stage I see the planning stage project has 0 downloads and a vaque outline. The stable project has multiple versions released, lots of weekly downloads.

Projects most used are possibly ones with the most weekly downloads listed. However, that is not a true indication if they are being used by the endusers. The site does not have a viable metric to measure actual use.

I selected the "Psychology Experiment Building Language (PEBL) project to learn more about.

PEBL is a tool to design and create psy. and neuroscience experiments.
It is written in C++ and PHP.
Those most likely to use PEBL are psychology developers, educators, IT, and science/research people. These categories are listed un the "Intended Audience" heading.
It was last updated on 8/21/14
There have been 385 downloads this week.
4 project admins are listed on the wiki.
I choose this project to explore since I have had some psychology colleagues interested in help with developing experiment software recently. I will recommend this to them.

MIFOS

The MIFOS project is mostly written in Java.

It has 2.6 MLOC.
It appears there are developers from all over the world. The map only flashed for a few seconds in chrome and firefox.
It is written in 19 languages - not all are programming languages.
XML has the second highest LOC.
Perl has the highest comment ration.
Average number of contributors in the last 12 months is <1.
The top 3 contributors have been involved for 1,4 and 3 years.
The average number of commits/month over the last year is 5.75.

FOSS in courses activity

In my reading of the various examples of folks using FOSS in their classes, I found a few exercises/ideas that I will incorporate into my courses int he future. Doing a whole day covering FOSS and going through some of the projects would be helpful in my software engineering course. Showing nonCS majors from the liberal arts how they could contribute to projects without having a programming background would be beneficial for most students planning careers in international organizations and NGOs.

Bug Tracker Activity

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.

ID - id number of bug
Sev - describes the impact of a bug. (Blocker, Critical, Major, Normal, Minor, Trivial, Enhancement)	
Pri - important and order bug should be fixed.(Immediate, Urgent, High, Low)
OS - operating system the bug was found on.
Product- subsystem
Status - general health of a bug. (UNCONFIRMED, NEW, ASSIGNED, NEEDINFO, REOPENED, RESOLVED,VERIFIED and CLOSED)
Resolution - indicates what happened to this bug. (empty, FIXED, DUPLICATE, WONTFIX, NOTABUG, NOTGNOME, INCOMPLETE, INVALID, OBSOLETE) 
Summary - comment

The above definitions are further explained in the Reports link.

The bugs appear to be displayed by status and then priority.

I did not discover the meaning of the shading nor coloring of some bug reports.

The bug, 706966, was submitted - 2013-08-28 11:30. The reporter claims the display of the month information is too busy and needs a redesign. There has not been recent discussion about this bug. Is the bug current? - Yes Is the bug assigned? - No To fix the bug. - Duplicate the bug, review the code generating display of the feature, create an improved display of the feature.

Bug 692455 - Windows are not where they appear to be. Submitted 2013-01-24. There has been 3 comments on the bug mainly stating it was not reproducible. The bug is current but not assigned. The main challenge would be to reproduce the bug before any possible fix could be attempted.

Collective Reports

314 bug reports were opened in the last week. 423 were closed? More bugs were closed than opened in the past week. The top three bug closers were Bastien Nocera, Jean-François Fortin Tam,and Emmanuele Bassi. Why is this important to know? - Perhaps as individuals who would be helpful in contacting with help? The top three bug reporters were Michael Catanzaro, Jo, and Jean-François Fortin Tam. These are not the same as the top three bug closes. The is no overlap in these two lists. The top three contributors of patches were Ray Strode, Bastien Nocera, and Marcos Chavarria Teijeiro. The top three reviewers of patches were Sebastian Dröge, Florian Müllner, and Bastien Nocera. There is only 2 common in both of these lists

FOSS in courses 2

Some possible activities

Code reviews for students with some coding background (any programming course, SE course, Capstone course). Learning goals could include: Identify program code and documentation style for a specific HFOSS project. Provide possible areas for improvement in a projects code along with a resulting bug report reduction benefit.

For non-CS courses going through process examples such as prioritizing todo tasks and learning roles to fill in humanitarian relief efforts would be useful. No prerequisite would be needed. Learning goals could include: Identifying HFOSS projects and defined roles for select projects. Be able to actively participate in an HFOSS communication channel. Identify non-programming roles in an HFOSS project.

Reviewing bug reports to see process of software development would also be a useful exercise for both technical and non-technical courses. Learning goals could include: Demonstrate parts and processes of a bug report. Be able to submit a bug report or bug fix.

With the exception of the communication channel activity, the above activities could all be done independently of the community. The channel communication (e.g. IRC) activity would need to span a long enough period to cover channel use by the HFOSS community.

All activities I would create as group projects with grading being based upon the group's final report/product shared with the class. It would be helpful to have a rubric for each of the activities to establish guidelines on expectations.

For contributions to a HFOSS project I think it would require substantial class time just to get students able to see the parts of the process (understand project, download a project, follow project contribution channels and understand protocols for contributions, etc.)

Going through the process of learning about HFOSS projects, it seems gaining an understanding of a particular project would be necessary for the faculty member to adequately make the class experience not such a frustrating learning curve. Relying on project members to help achieve this would seem non-realistic in terms of a timeline for course deadlines.