User:Alan.rea

Revision as of 22:19, 2 September 2015

Alan Rea (aka docrea)

Alan Rea is a Professor of Computer Information Systems in the [Department of Business Information Systems] at the [Haworth College of Business], [Western Michigan University].

Dr. Rea regularly teaches courses in Application, Internet, and Mobile programming, as well as Information Security.

His research focuses on secure mobile application development. In particular, Dr. Rea explores the security and privacy implications intertwined in developing, deploying, and managing the Internet of Things.

Response to IRC Activity

What is the pattern of communication?

There are three distinct phases to the meeting: introduction and pleasantries, work on particular challenges, organizing for next assignments. The bulk of the meeting are discussing and attempting to solve multiple challenges (VM issues, camera tracking, graphics challenges on documentation and the like, etc.).

The challenges all center around the FOSS MouseTrap application in varying degrees and center around functionality issues not only with the application but also the VM/Linux system. Collaborative brainstorming leads to some discussi of dependency issues that might be solved via various approaches.

Of special note are items such as the challenges of FOSS systems between various flavors and distributions (e.g., Fedora versys Ubuntu). There are also issues of potential missing support contacts (flapper87) and dead code forks.

Are there any terms that seem to have special meaning?

There are many terms relating to software offerings and dependencies, modules, and code commits. Many times these tend to scare potential users away. Instead of just noting to "update software" in FOSS we need to discuss repositories, potential kernel conflicts, open versus proprietary drivers, etc.

Can you make any other observations?

This is an extremely rich and productive meeting that takes place in a span of an hour. One can tell these individuals work with one another on a regular basis and are familiar with each others strengths.

PartB: Project Evaluation Activity

OpenMRS Evaluation Rubric

File:Rea OpenMRS Evaluation.ods

Mission: 17

Secondary: 25

PartB: FOSS in Courses Planning 1

Potential HFOSS Contribution

In terms of HFOSS Projects, what mosts interests me is anything dealing with Android development. I am currently teaching a beginning and advanced course, as well as taking part in a pilot project to award certificates and digital badges to students who complete the two course Android development concentration. Moreover, our department has a minor in mobile development that I co-ordinate.

Looking over the existing projects, it looks as if Ushahidi has a need for mobile developers (http://foss2serve.org/index.php/Ushahidi_Android_Application) as well as those interested in data management (http://www.ushahidi.com/). Our department has a concentration in data analytics (http://www.wmich.edu/infosystems/academics) so I should be able to get other students (and perhaps professors) interested as well.

Potential Courses

The two most applicable courses to the above HFOSS discussion would be Business Mobile Programming (CIS2610) and Mobile Commerce (CIS4700). These basically translate to beginning (2610) and advanced (4700) Android development. CIS2610 is offered every semester and has a mix of beginning and intermediate programming students. CIS4700 is offered once a year in the Spring and is comprised of advanced programmers.

CIS2610

• Join a mailing list
• Look over the bug tracking
• Work with the community
• Join the Twitter Feed (https://twitter.com/ushahidi)
• Join the Facebook page (https://www.facebook.com/ushahidi)

Because these are beginning programming students we will not work with code except for those who might be more advanced.

CIS4700

• All of the above (students will have done so in CIS2610)
• Join GitHub (https://github.com/ushahidi)
• Improve the wiki (https://wiki.ushahidi.com/display/WIKI/Build+The+Android+App)
• Write an app using the source code and APIs that targets a specific need

Other Courses

I also teach a Web development course in which we primarily use Bluefish and GIMP to learn Web development and work on a semester-long team project building interactive sites for non-profits and small businesses. This may be another option.

Part C: Bug tracker Activity

Part1: Bug Report

Definitions

• ID: Identifying number that will be used to reference the bug.
• Sev: Severity of the bug.
• Pri: Priority assigned to the bug.
• OS: The operating system version and Linux flavour the bug is filed on. In some cases this could be on a particular kernel. It might also be Linux, Windows, OS X, etc.
• Product: The actual software that has the bug report filed on it (e.g., banshee)
• Status: The status is set as NEW when submitted. It can then be changed as the bug is assigned, reopened for another fix, more information requested on the bug, etc.
• Resolution: Has it been fixed, determined to not be a bug, etc.
• Summary: Explanation of the bug's nature.

3. Most of the bug tracking definitions were found simply by mousing over the category. Another place to learn more about what should be in good bug tracking systems is http://timheuer.com/blog/archive/2011/10/12/anatomy-of-a-good-bug-report.aspx

4. Bugs are initially displayed alphabetically by product.

5. The shaded bug reports are software feature requests that do not immediately need to be fixed in terms of software functionality.

6. We discussed this in the weekly IRC meeting: black: normal status, red: priority, gray: feature requests.

Bug Hunt

7. https://bugzilla.gnome.org/show_bug.cgi?id=661178

• 2011-10-07
• 2012-12-05
• No
• Yes. Control-Center Maintainers
• One needs to make sure that keyboard shortcuts are coded into the control panel so that a user has the choice as to whether he/she uses the mouse or the keyboard to make changes.

8. https://bugzilla.gnome.org/show_bug.cgi?id=644379

• 2011-03-10
• No. Although there was much discussion and investigation when it was submitted. The last comment was the original submitter figuring out the issue was a configuration in his X file on a multi-screen system. Most likely new kernels, video drivers, and the prevalence of multiple monitor displays has resolved the issue on its own.
• At the time, it was.
• gtk-bugs
• The bug reporter resolved the issue with some testing and discussion with the gtk team.

Part2 - Collective Reports

3. 145 bugs in the past seven days were opened. 98 bugs were closed in the past seven days.

4. More bugs were opened than closed in the past seven days. However, 47 open bugs in this large an offering is quite good.

5. The top three bug closers were Matthias Clasen, Michael Catanzaro, and Milan Crha. This is an important statistic as FOSS projects always need active participants and these three people might be good candidates for project leaders if there are in the top 15 consistently.

6. The top three bug reporters were Michael Catranzaro, AlexL, and Bastien Novera. Michael overlaps both lists and might be a great candidate for a leadership position.

7. The top three patch contributors are Carlos Soriano, Michael Catanzaro, and Bastien Nocera. Once again Michael placing so high may be a good indicator of someone who can take on more in the project.

8. The top three reviews of patches are Sebastian Dröge (slomo), Bastien Nocera, and Carlos Soriano. (Michael is #6.)

11. There were 19 Braille bugs in the normal category.

12. You can also select Line, Table, and CSV.