User:Jpaul

Jody Paul

Jody Paul is on the faculty of the Mathematical and Computer Sciences department at Metropolitan State University of Denver (MSU Denver), an urban institution with a modified, open-admission policy.

Dr. Paul's main areas of interest include Computer Science Education, Software Engineering, and Cognitive Science.

Observations made while exploring HFOSS projects

Sugar Labs

Contributions

• The roles most applicable for my students: Content Writer, Developer, Designer, Translator
• Commonalities and differences across roles: All involve "communicate" (other than Educator); Each represents a different skill set

Tracker

• The general process for submitting a bug involves using Trac for issue tracking. A bug is reported by creating and filing a new ticket. A registered login is necessary.
• The types/categories of tickets listed include: defect, enhancement, and task. There is much information available for each ticket, such as: Reporter (author), Type, Component, Version, Keywords, Priority, Milestone, Owner, Cc list, Resolution, Status, Summary, and Description

Repository

• As of Mar 7, 2017, the date of the last commit was Feb 5, 2017, but this appears to correspond to a commit from Oct 10, 2016.

Release cycle

• Each release cycle includes "development, beta, release candidate and final releases."[1] The roadmap provides greater detail with scheduled release dates and freeze points. The most recent item on the roadmap schedule is dated 1 October 2016.

Sahana Eden

Community

• The grouping of contributors is relatively similar to that found in Sugar Labs but appears to be more focused on development than communication. The types of contributions associated with three of the groups include:
  • Developers - Code level design and implementation contributions
  • Testers - Both manual and automated testing; allows for non-technical contributions
  • Designers - Primarily user interface design contributions

Tracker can be found here. Place your answers to the following on your wiki page.

• The Sahana Eden project, like Sugar Labs, uses Trac for issue tracking. The information contained in a report of active tickets [2] is essentially the same as in the Sugar Labs report with minor difference in which fields are shown (e.g., Sahana Eden shows "Component", "Version", and "Created" fields whereas Sugar Labs shows "Milestone") and Sahana includes a distinct "documentation" type. Sahana Eden also provides more pre-constructed reports to facilitate searching and viewing the Trac database (compare [3] with [4]).

Repository

• As of Mar 7, 2017, the date of the most recent commit was Mar 7, 2017.

Release cycle

• Sahana Eden appears to use the Milestone and Roadmap structure from Trac. The roadmap at the website [5] appears to lack updating, with Milestone 0.9 shown as "5 years late" and Milestone 1.0 as "Planned for: May 2012 (Draft)".

FOSS Field Trip

GitHub

Search for term "education" produced: "We’ve found 11,995 repository results"

First project: "vhf/free-programming-books". Graphs>Commits indicates repository commit activity, weekly and daily.

Search for term "humanitarian" produced: "We’ve found 284 repository results"

The HTBox/crisischeckin project (as of 20 March 2017) shows: "Updated on Nov 4, 2016"

Search for phrase "disaster management" produced: "We’ve found 138 repository results"

OpenHub

Search for term "education" indicated 347 pages. Page 347 has one project. Assuming all other pages have 10, there are 3461 projects.

All KDE Education code locations appear to be at "anongit.kde.org", none indicate "github.com".

10 projects are identified as being similar to KDE Education.

OpenHub provides project information such as summaries and news, as well as data about the code base, repository activity, and contributors.

Search for term "humanitarian" returned 34 projects.

Search for phrase "disaster management" returned 54 projects.

"Activity Not Available" is described begin associated with "projects that do not have recent analysis because of problems with their code locations or other problems blocking Open Hub from collecting and analyzing code". (http://blog.openhub.net/about-project-activity-icons/ accessed 20 March 2017)

The "Orgs Explore - Open Hub" page shows activity statistics arranged by organization and type of organization.

The OpenMRS Core project on OpenHub (as of 20 March 2017) shows a last commit date of "18-August-2016". It also shows "Activity Not Available" (described previously).

The OpenMRS Core project on GitHub (as of 20 March 2017) shows multiple commits on 20 March 2017.

The "Activity Not Available" indicator on OpenHub points to a disconnect between the information available to and shown on OpenHub and the project repository hosted on GitHub.

GitHub and OpenHub provide different information with some overlap. Understanding the limitations of those helps in interpreting search results at each site. SourceForge is yet another such site that may also warrant searching. Perhaps using general search engines (e.g., Google, Bing, Yahoo, DuckDuckGo, ...) may be more beneficial for locating projects than using specific repository hosts' search features.

Project Evaluation

Walk through of an evaluation of the OpenMRS project

The table below contains entries for each of the evaluation criteria in the Project Evaluation Learning Activity. The evaluation for each criterion is recorded in the "Evaluation Data" column. A score is assigned in the level column using zero to indicate that the criterion is not met at all, two to indicate that the criterion is fully met, and 1 for something in between. The project overall total indicates the sum of scores for each of the criteria. (See: Evaluation Table Key)

Evaluation Table

Evaluation Factor	Level (0-2)	Evaluation Data
Licensing	2	Mozilla Public License 2.0 (MPL-2.0)
Language	2	Java (95.5%), SQLPL (2.9%), GAP (0.7%)
Level of Activity	1	There appears to be relatively low activity over the past 12 months; however, this may be a difficulty with my interpreting the data (see next response)
Number of Contributors	1	253 contributors are listed. Looking at the graphs, less than a handful have significant activity in the past 5 years. Looking at the pulse for the last month, "16 authors have pushed 84 commits to master and 116 commits to all branches." I'm finding it a bit difficult to decipher and reconcile the various summary statistics.
Product Size	0	218.35 MB (huge amounts of text if 1 character = 1 byte)
Issue Tracker	1	No issues logged via GitHub Ready for Work: 0 + 10 + 87 + 351 + 251 + 83 + 471 = 1253 Closed: 1 + 323 + 1615 + 3058 + 1252 + 487 + 3112 = 9848 Low/Sporadic activity
New Contributor	2	The Developer Guide is a very useful starting point. Getting Started as a Developer is somewhat welcoming and accessible. The OpenMRS Developers Guide is rather daunting.
Community Norms	2	The OpenMRS Code of Conduct is based on the Ubuntu Code of Conduct, addresses norms of collaborative behavior, and specifies penalties associated with violations of the code. Arbitrary conversations read in OpenMRS Talk appear to adhere to the code, be relevant, and often provide links to documented information.
User Base	2	Looking at the atlas there appear to be numerous locations at which OpenMRS is or has been used. Clicking on numerous Clinical sites, however, shows the notation "Why is this site fading away?" The 2016 Annual Report states that "Based on documented reports, OpenMRS is currently in use in 1,845 locations around the world." Instructions are provided for downloading, setting up, and using the software.
Total Score	13	This provided a very useful starting point for assessing appropriateness of an HFOSS project for use in a course. Having had this experience, I can see where and how I would choose to modify the criteria and the interpretation of evaluation data to facilitate appropriate project choice. For example, using differently-scaled Levels and a weighted sum for Total Score may better reflect the variance and relative importance of the evaluation factors.

Intro to Copyright and Licensing

1.

openMRS-core: Mozilla Public License, version 2.0

incubator-fineract: Apache License, Version 2.0

regulately-back-end: Not obvious. The regulately-front-end project indicates "The MIT License (MIT)"

2.

The MIT License requires that licensees must provide attribution and include both the copyright and the license. Licensees may modify, redistribute, and derive commercial value from the work. There is no specific requirement with respect to the licensing of derivative works or distribution of associated source code. Authors may not be held liable.

The Apache License 2.0 requires that licensees must provide attribution and include the copyright, the license, and changes made. Licensees may modify, redistribute, and derive commercial value from the work. There is no specific requirement with respect to the licensing of derivative works or distribution of associated source code. The software may be warrantied, which determines if the licensee may be held liable. Derivative works may be subject to patent claims.

The Mozilla License 2.0 requires that licensees must provide attribution and include the copyright and the license. Licensees may modify, redistribute, and derive commercial value from the work. Licensees must include the original source and must disclose source for all derivative works. The software may be warrantied, which determines if the licensee may be held liable. Derivative works may be subject to patent claims.

3.

I would be comfortable with contributing my own work to an open source project under any of these licenses. That has less to do with the specific license than it does with the project itself.

That said, I think a more pertinent issue is comfort with respect to requiring students to contribute to a project under these licenses.

I would be comfortable only with licenses that permit students to use their work for other purposes without restriction. I believe I would have issues with a license that permits others to use a student's work (a) without attribution or (b) for commercial use without their explicit permission. Given that each of the licenses identified above permits commercial use, I would not be comfortable with requiring the contribution of students in projects with such licenses.

Another concern about external project work in general is raised when participation in some specific project(s) is required as part of a course; even more so if such participation is part of a required course. The concern is whether students should have a say in determining if their own work is (a) to be made "public" and (b) to be used by others. This concern indicates potentially significant complications in course administration.

FOSS in Courses 1 (Instructors)

A target course for Fall 2017 is Software Engineering Principles, a senior-level introduction to software engineering.

1. A possible activity is for students to review the requirements (user stories, scenarios, software requirements specifications, ...) as documented within an HFOSS project. Outcomes can include identification of the types of requirements as well as assessments of the quality of specific requirements and of the collection as a whole.

2. Another possible activity is for students to review the design of an HFOSS project. Outcomes can include the identification of the architectural paradigm, the results of applying design metrics, and the identification of potential refactorings.

I would appreciate help in locating an HFOSS project that follows a Test-Driven Development paradigm.

Intro to Bug Trackers (Activity)

Project: GNOME
Tool: Bugzilla

Part 1 - Bug Reports

Screen capture of Bugzilla report displayed from link: GNOME Accessibility Bugs

Definitions of Report Column Names

Column	Explanation	Range of Values
ID	Unique identifier of the issue/bug	positive integers
Sev	Not shown. Presumed to be Severity: The assessed impact of the issue/bug	blocker, critical, major, normal, minor, enhancement
Pri	Not shown. Presumed to be Priority: The engineer's prioritization	Priority: High, Normal, Low
Note that bug reports show an Importance field that appears to be the concatenation of Priority and Severity; for example, "High critical".
OS	Not shown. The operating system on which the behavior was observed (The Component field also seems to be used to identify some operating system specifics, such as "win32".)	About a score of possible values, including "All", "Mac OS", "Solaris", "AIX", "Linux"
Product	Identification of a unit within the GNOME project	E.g., yelp-xsl, yelp, xchat-gnome, vte, nautilus, metacity
Status	The current state of the issue/bug	NEW, ASSIGNED, REOPENED, UNCONFIRMED, NEEDINFO, RESOLVED, CONFIRMED, VERIFIED
Resolution	Disposition of the issue/bug	FIXED, INVALID, WONTFIX, DUPLICATE, WORKSFORME
Summary	Concise (one sentence) description of the issue/bug
References: https://bugzilla.gnome.org/page.cgi?id=fields.html https://bugzilla.gnome.org/page.cgi?id=bug-writing.html https://bugzilla.gnome.org/query.cgi?format=advanced

Somewhat inconsistent information about definitions depended on which resources were consulted. This is not unusual in a changing environment. It is a good reminder about designing reusable assignments that refer to fluid environments. I consulted multiple references specific to the gnome use of Buzilla as well as Bugzilla tool documentaiton itself.

The ordering appears to be "remembered" because although I click on the same link from the http://foss2serve.org/index.php/Intro_to_Bug_Trackers_(Activity) , the ordering is different depending on what I had done previously. Using a different browser with no (known) history, the initial primary ordering appeared to be by Status.

I did not locate an authoritative reference for the appearance of report items. "Blue" links change to "grey" in response to mouse hover. A hypothesis is that "Red" is intended to indicate "critical" although it may be used for other purposes as well. (I note that its use isn't well-distinguished in an accessibility context.) There is background shading of some rows whose meaning I did not identify. Since "black" text and "grey" text are difficult to distinguish in general, my hypothesis is that the meanings aren't considered very important. A hypothesis is that "grey" relates to a subset of the Importance values.

I reviewed several dozen bugs but did not find anything that I thought I could address at this time.

The following responses are with respect to bug "Bug 754806 - No cursor when using magnifier/zoom".

1. Reported: 2015-09-09
2. Multiple people added as CC. Some discussion January-February 2017.
3. The bug is current.
4. The bug is assigned to "gnome-shell-maint"
5. To begin addressing the bug, I would first need to learn what is meant by the "magnifier" component of "gnome-shell". I would attempt to reproduce the bug, which would involve creating an appropriate development and testing environment. The next steps would depend on the nature of the product, documentation, etc. This might not be a good bug to tackle first as it blocks another open bug.

The following responses are with respect to bug "Bug 759551 - Epiphany seems to steal focus from caribou".

1. Reported: 2015-12-16
2. Not much discussion; additional report added 2016-04-02
3. The bug is current in that it is not closed.
4. The bug is assigned to "Epiphany Maintainers"
5. To begin addressing the bug, I would first need to learn what is meant by the "epiphany" product. Similar to the previous item, I would seek to access an appropriate development and testing environment. The next steps would depend on the nature of the product, documentation, etc. What makes this bug a potentially good choice is that it does not block any open bugs and it does not depend on any open bugs.

Part 2 - Collective Reports

Number of bugs "Opened in last 7 days": 12 + 7 + 1 + 5 + 23 + 4 + 0 + 12 + 4 + 3 + 5 + 7 + 1 + 0 + 3 = 87

Number of bugs "Closed in last 7 days": 10 + 3 + 0 + 9 + 13 + 0 + 1 + 14 + 5 + 0 + 7 + 7 + 0 + 0 + 0 = 69

Trend is relatively stable with a similar number of bugs opened as closed.

Christoph Reiter, Alberts Muktupāvels, Philip Chimento are the top three bug closers. There is mixed value to this knowledge in that it may foster a sense of competitiveness. It can also be a metric to detect outliers that should be subject to greater scrutiny.

Wei Lei, Bastien Nocera, and Adrien Plazas are the top three bug reporters. There is no overlap with the top three bug closers. Several individuals appear on both "Top 15" lists.

Christoph Reiter, Debarshi Ray, and Ray Strode are the top three patch contributors.

Carlos Soriano, Christoph Reiter, and Cosimo Cecchi are the top three reviewers of patches. The appearance of the same names on multiple lists indicates that a small number of individuals are most heavily involved with and active in the project.

Instructions indicate the desire to "plot a line graph" but also to 'Select "Bar Graph" for type of graph". The chart produced was a bar graph. Substituting "Line Graph" did indeed produce a line graph.

A search for "braille" returned a listing of bugs that spanned multiple products, components, and status. Using just the "braille" component, and assuming that "class" means "Classification", then the majority appear to be "Applications" rather than "core" and "other".

I can create reports based on combindations of most field values. Although most common logic appears to be afforded well by the grpahical user interface, some logic may be more difficult to construct. Here is a simple table showing Severity x Priority.

FOSS in Courses 2 (Instructors)

1. HFOSS can support learning activities both inside and outside of class. Distinctions of "project", "homework", or "in-class activity" are not relevant as these activities may be initiated during or outside of class and engagement may occur during and outside of class.

2. Courses and Activities

• Course: Software Engineering Principles, an introduction to software engineering
• Course: Software Engineering Practices, a senior-experience course

Although the prime motivator was to use HFOSS in support of the senior-experience course, this seems to be more readily applied to the introduction to software engineering course. Each of the following activities supports acquisition and application of knowledge in software engineering. The emphasized knowledge area is identified in the heading of each. Identified activities limit required contributions from HFOSS projects to existing artifacts, thereby loosening the coupling and mitigating scheduling and critical-path issues. Rubrics developed for these activities will adhere to those already in use for similar activities. Such rubrics identify key concept areas and distinguish among levels of demonstration. The rubric associated with an assessed activity is intended to be shared with students along with the activity specification. Students may need to be given the ability to decide whether to contribute their work to the HFOSS project, with such contribution not being required nor included in grading for course assessment. Concern: Many FOSS projects use software engineering practices which may not afford students "best practice" experiences. It may prove difficult to identify HFOSS projects with appropriate processes and artifacts, and result in requiring significant time and effort expended to continually address the differences between the project practices (outside of their purview) and best practices.

Requirements Engineering: Students will review requirements specified within an HFOSS project. Outcomes include identification of the types of requirements and assessment of the quality of the requirements specifications. Knowledge of requirements engineering and metrics for requirements evaluation is necessary to complete this activity.

Architecture & Design: Students review the design of an HFOSS project. Outcomes include: the identification of the architectural paradigm; the outcome of design metric application; and, recommendations for design quality improvement. Knowledge of software architecture, design, and metrics is necessary to complete this activity.

End-User Documentation: Students review the end-user documentation of an HFOSS project. Outcomes include: assessment of accessibility; identification of the characteristics of the intended users and the intended audience of the documentation; assessment of appropriateness, completeness, correctness, and utility of the documentation; and, recommendations for modifying the documentation to improve the end-user experience. Knowledge of attributes of end-user documentation and associated assessment criteria is necessary to complete this activity.

Maintenance Documentation: Students review the maintenance documentation of an HFOSS project. Outcomes include: assessment of accessibility and quality of maintenance documentation; and, reocmmendations for improving maintainability. Knowledge of software development and maintenance is necessary to complete this activity.