Gianluca Torta is a Researcher and Assistant Professor in the Computer Science Department at Università di Torino, where he obtained a PhD degree in 2005.
His main research interests are in Artificial Intelligence, with particular focus on knowledge representation and reasoning.
He currently teaches Software Engineering and Artificial Intelligence.
His interest in Open Source software dates back to the late nineties, when he started using the FreeBSD operating system, the GNU Emacs editor and the Perl language thanks to a friend of him that already knew and appreciated OSS. Since then he has been an OSS enthusiast, both for personal use and for his academic work.
- People interact by writing messages that are shown to all the other people in the channel. If the nicknames of one or more persons appear in a message, such persons will hear a sound and see the message somewhat highlighted.
- The log reports a meeting, which makes use of a meetbot. The pattern of communication is, in general, non-linear, since different dialogues can overlap with each other. For example, more than one person replied to the same question or comment, giving rise to branches in the communication.
- The communication is informal, and many to many.
- I saw many technical terms, some of which I could not understand. There were also some special messages for the meetbot.
- bonus question: the bot hasn't picked up Heidi and Darci's actions because their nickname was typed with the wrong case, and the meetbot is case-sensitive
- I tried to observe the #a11y on the irc.gnome.org but, after several hours, there was no activity; so I turned to the #gtk+ channel on the same server.
- Unlike the meeting observed in the log, the communication was made mostly of help requests and answers.
- There was also a bot, but it was called bugbot and reported about creation and status changes of gnome bugs.
- The talk was very technical, I could not understand in detail most of it, since I don't know gtk+
FOSS Project Anatomy
- my students are all involved in Computer Science curricula (either BSc or MSc). Therefore I think the best fit for them is the Developer role, although some of them could be interested (and have skills) also for the Designer and Content Writer roles
- all the above roles require the ability to communicate: either through code, words, or images. This makes particular sense in a project developed by a large community for an even larger community of users in education. The difference is in the other skills required: either ability to code, to write clear documents, to design beautiful images and usable interfaces
- in order to enter a new bug for a Sugar Labs project, you should have a github account, go to the Issues section of the project and push the New issue button
- the types of tickets shown by the query on the bugs.sugarlabs.org bug tracker are of three types: defect, enhancement, and task. By the way this bug tracker seems to be independent of the github issues that can be opened by any github user
- last commit on Sugar Labs source repository was made on May 16 2017, 12 days before I wrote these notes
- at the beginning of each release cycle the dev team creates a roadmap for that release (e.g., 0.112). Such a roadmap lists the goals, schedule and freeze dates for the release. The schedule should be observed by all the module maintainers of Glucose (base) and Fructose (base activity) modules
- contributing as Testers can either involve manual testing (that can be done also by non-technical contributors), unit-testing the code you write (if you are contributing also as Developer), or working on the Continuous Integration process. Compared to the Sugar Labs project, this project distinguishes the Developer and Tester roles
- the bug tracking page is a list of reports that correspond to useful queries to the bug tracking system. This was not available in the Sugar Labs project. The Active Tickets are categorized into defect/bug, enhancement, task and documentation. The list of Active Tickets reports, for each ticket, component, version, priority, type, owner, status and creation date. By default minor-priority tickets appear after major-priority tickets and in a different color. I was surprised that the last ticket was opened more than 2 years ago
- last commit on Sahana Eden source repository was made on May 25 2017, 2 days before I wrote these notes
- the Sahana Eden roadmap seems quite outdated and unstructured, compared to the Sugar Labs project. It lists three releases (0.9.0, 1.0, and 2.0) that are probably all quite old, since even the last one has still a pending active ticket (see above). For the last release (2.0) there are estimations of the hours needed for the goals
FOSS Field Trip
- GitHub found an impressive number of 13,432 repositories with the word "education"
- the first project in the list was nodejs/education. The Graphs/Commits shows graphically the number of commits during the past year (aggregated every 20 days) and the number of commits during the last week (day by day)
- for the repository nodejs/education there was 1 commit during the last week, and about 20 commits during the past year: apparently the project development was not very active during the past year
- GitHub found 301 repositories with the word "humanitarian"
- the last commit on project HTBox/crisischeckin was made on April 22, about 6 weeks before my access to the repository
- GitHub found 121 repositories with the phrase "disaster management"
- OpenHub found about 3470 repositories with the word "education"
- the code repositories for project KDE Education are all hosted on anongit.kde.org; none of them is hosted on GitHub
- there are 10 projects listed as "similar" to KDE Education
- the project page for KDE Education reports, among other things, information about the Code (lines of code, languages), Activity (commits, 30-day and 12-months summaries), and Community (number of contributors, recent contributors, ratings)
- OpenHub found about 40 repositories with the word "humanitarian", and about 60 repositories with the phrase "disaster management"
- many projects have the "Activity not available" icon because, as explained at http://blog.openhub.net/about-project-activity-icons/, there are problems with their code locations or other problems blocking Open Hub from collecting and analyzing code
- the Organizations page provides information about the organizations active in FOSS development (e.g., The Linux Foundation, Apache Software Foundation, ...). Among other things, the page lists the most active organizations and some statistics by sector (Commercial, Non-profit, Education, Government)
- the last commit on OpenMRS Core reported by OpenHub was on April 17, 2017 (about one and a half months before my access to the site). Instead, the last commit on OpenMRS Core reported by GitHub was on May 30, 2017 (only 4 days before my access to the site)
- the difference is due to the fact that OpenHub updated its data about the code of OpenMRS Core 2 months before my access. Not sure why it did not make any further updates, since the URLs of the code repository are ok
- OpenHub is a very interesting site that I didn't know; one of its main benefits is that it can track repositories from multiple sources (e.g., GitHub, private repositories, ...). The drawback is that it may not be up-to-date with the last information about a project development
Project Evaluation (OpenMRS)
|Evaluation Factor|| Level
|Licensing||2||The project has a Mozilla Public License, version 2.0 which is Open Source|
|Language||2||The project top three languages are Java (95.4%), SQLPL (3.0%), and GAP (0.7%)|
|Level of Activity||2||The project has been active most of the weeks during each quarter of the past year.|
|Number of Contributors||2||The project has 262 contributors.|
|Product Size||1||The project size is 219.84MB; not sure whether this is an optimal size for my students, but it is certainly an interesting and well established project.|
|Issue Tracker||2||There are 1334 tickets "Ready for Work". There are 10,066 closed tickets. The 5th Blocker issue in the "Ready for Work" list is "Search does not work for parts of words", and was opened in July 2012 and updated in March 2016. I queried JIRA for the number of issues closed during the past year, and it turned out that 1191 issues were closed.|
|New Contributor||2||The SDK for developers is here. The project has many social accounts including Twitter, Facebook, YouTube, Google+, and Flickr. There are IRC and Telegram chats. There is a broken link to events, and a forum for asking questions that is very active. Overall, the project presence on the Web is well established, thanks to the project Web site and wiki.|
|Community Norms||2||The Code of Conduct for the project emphasizes positive behavior such as being respectful and collaborative; this is a good lesson for students (and instructors as well). Disagreeements are unavoidable, and the project has means to handle them, including through the OpenMRS Leadership Team. If inappropriate behavior still happens, there are penalties that can go up to being removed form the community. I have reviewed discussions Built-In Reports for Reference Application and Migrating emrapi module from GlobalProperties to metadata mappings. In the first thread I could observe a GSoC student applying and starting its work for GSoC 2017; the community was very welcoming and helpful with him. The other thread was an example of being considerate: it started in August 2016 with a developer notifying a change (not yet committed) and asking others to notify potential issues with other parts of the system and curent deployments.|
|User Base||2||The main page of the project Web site shows quotes from OpenMRS users in the OpenMRS users on the OpenMRS community panel, including Partners in Health and AMPATH. The blog also reports on OpenMRS uses, e.g. to Fight Malaria and to support hospitals in Haiti. The main page of the project site also has a link for downloading the software. The wiki has a link to the User Guide.|
|Total Score||17||Seems to be a project with an excellent health, suitable for welcoming new contributors including students.|
Intro to Copyright and Licensing
- the license of OpenMRS is Mozilla Public License, v. 2.0. The licence of Fineract is Apache License Version 2.0. I could not find any licence for regulately
- the Apache License Version 2.0 allows (can) Commercial Use, Modify, Distribute, Sublicense, Private Use, Use Patent Claims, and Place Warranty. It disallows (Cannot) Hold Liable and Use Trademark. It requires (Must) Include Copyright, Include License, State Changes, and Notice
- the Mozilla Public License, v. 2.0 allows (can) Commercial Use, Modify, Distribute, Sublicense, Use Patent Claims, and Place Warranty. It disallows (Cannot) Hold Liable and Use Trademark. It requires (Must) Include Copyright, Include License, Disclose Source, and Include Original
- I would be comfortable contributing to both OpenMRS and Fineract because of their licenses. To me (a non-expert) they look similar; in particular I am not uncomfortable with allowing Commercial Use. On the other hand, I would not feel comfortable contributing to regulately without having access to its license (if any)
FOSS in Courses I
HFOSS Project of Interest
- I am interested in the HFOSS project OpenMRS
- first of all, I like the goal to improve health care delivery in resource-constrained environments
- moreover, the evaluation activity showed that it is an excellent project to contribute to
- finally, it uses Java, a language that is well known in my University by both professors and students
- the "join the community" menu lists several ways to contribute:
- eventually, I would be interested to involve my students in Development (I teach to CS students)
- however, I think that learning a complex project such as OpenMRS is better done by starting with contributions to Test, or even Documentation
- Testing includes writing Unit Tests, which in my opinion is a good way to learn a project
- one area that I would like my students to explore is Decision Support (my research is mostly in Artificial Intelligence); I have found a Design item about that, not sure if it is being worked on
- I understand that OpenMRS is mostly made of modules (as, e.g., Moodle), that are managed in a relatively independent way w.r.t. the main system
- the Wiki reports a list of Projects, many of which are Unassigned projects: those could be interesting to explore
My HFOSS Course
- I would like to explore the use of HFOSS (and, in particular, OpenMRS) within a Software Engineering/Capstone Project class
- such a class should ideally involve some activity on requirements, design, implementation, and testing
- first I would ask students to get confident with the project by reading the documentation (and parts of the code)
- once they have understood at least some areas of the project, they could then write Unit Testing for some uncovered area of the project
- in the same area or a different one, they may pick up a bug from JIRA and try to fix it and commit it back to the project
- they could then pick some unsasigned project and try to elicit a requirements specification through some activity of requirements engineering
- as a design activity, they could either use UML to document some area of the existing system, or do some original design for the unassigned project they have analyzed
Intro to Bug Trackers
- meanings of columns
- ID is the numeric unique id of the bug
- Sev is the severity of the bug. Range: blocker, critical, major, normal, minor, trivial, enhancement.
- Pri is the priority of the bug. Range: Immediate, Urgent, High, Normal, Low.
- OS is the Operating System where the bug was observed. Range: All, AIX, ..., Windows, OpenVMS, other.
- Product is the product the bug refers to. Range: acerciser, accountsdialog, ..., zapping, zenity.
- Status indicates the current status of the bug. Range: according to the Advanced Search page, the range is UNCONFIRMED, NEW, ASSIGNED, REOPENED, NEEDINFO, RESOLVED, VERIFIED. According to the Bug Fields page, the range is UNCONFIRMED, CONFIRMED, IN_PROGRESS, RESOLVED, VERIFIED.
- Resolution indicates what happened to this bug. Range: according to the Advanced Search page, the range is FIXED, WONTFIX, DUPLICATE, NOTABUG, NOTGNOME, INCOMPLETE, INVALID, GNOME1.x, MOVED, OBSOLETE, NOTXIMIAN. According to the Bug Fields page, the range is FIXED, INVALID, WONTFIX, DUPLICATE, WORKSFORME.
- Summary is a short sentence on what the bug is about.
- I found the meanings of fields in the Bug Fields page, and the ranges in the Bug Fields and Advanced Search pages
- the bugs are initially sorted by ID
- the color seems to be related with the importance of the bug: I observed a "High critical" bug to be red, a "Normal enhancement" bug to be gray, and a "Normal normal" bug to be black
- bug 773719 Pressing tab without suggestions leaves path bar
- the bug was submitted on October 31, 2016
- the discussion has been silent since the same day of the report, namely October 31, 2016. It's been deferred for Nautilus 3.24. Will probably be fixed in 3.25 which is still work in progress
- the bug is current
- the bug is assigned to the Nautilus Maintainers
- probably, to fix the bug the main problem is to choose the key to replace the tab key for auto-completion in the path bar. Once that has been determined, it should be relatively easy to change the Nautilus code so that the chosen key is used instead of tab
- bug 643853 Combobox dropdown items are not selectable using keyboard
- the bug was submitted on March 4, 2011
- the discussion about the bug was recently resumed with a message on March 3, 2017
- the bug is current
- the bug is assigned to gtk-bugs
- as reported in the most recent comment on the bug, it is probably necessary to modify GtkMenu, since when the menu is open it grabs all the input, including the keys used to select from the Combobox. Then, the keypress handling should be added to the Combobox (something Daniel Boles says he already did, in the most recent comment on the bug)
- 258 bugs were opened in the last 7 days (from my access on June 25, 2017), and 236 bugs were closed
- overall, the numbers of opened and closed bugs are quite close for the last 7 days, although ther former is larger than the latter
- the top three bug closers were: Bastien Nocera, Tim Janik, and Milan Crha. It is important to recognize their effort to motivate developers to close bugs
- the top three bug reporters were: Bastien Nocera, Stephen, and Ting-Wei Lan. One of them is also a top closer, meaning that he is a developer
- the top three patch contributors were: Bastien Nocera, Abhinav Singh, and Florian Müllner
- the top three patch reviewers were: Georges Basile Stavracas Neto, Daniel Garcia, and Marcus Lundblad. The list of reviewers is almost disjoint from those of bug closers and reporters, and patch contributors. The only exception is Bastien Nocera, that appears in all the lists
- the majority of the bugs for the component braille have severity normal, according to the generated line graph
- it is also possible to generate bar charts and pie charts
FOSS in Courses II
- study of a part of a HFOSS project
- the first activity I'd like to analyse for inclusion in a possible SWEng class/Capstone project would require the student to understand a part of the project, e.g. a module, an architectural component, a complex feature
- this would involve reading documentation (if any), reading code, and producing schemas (Software Design Specifications) of code
- the work would be done in class (with the help of teachers) and as homework
- reporting and fixing bugs
- the second activity I'd like to analyse would require the student to test the part of the system analysed above, potentially writing automated test cases for finding bugs and filing them to the Issue Tracker of the project
- this would involve using the system (manual tests), writing code (automated tests, bug fixes), and communicating with the community through the Issue Tracker
- the work would be done in class (with the help of teachers) and as homework
- the third activity I'd like to analyse would require the student to explore an extension of the project that isn't yet well specified (e.g., unassigned projects in OpenMRS?), and do some requirements analysis
- this would involve reading whathever has already been written on the extension, thinking about it possibly interacting with the community, and producing some Software Requirements Specifications
- the work would be done in class (with the help of teachers) and as homework