User:Hcarter

Hank Carter

Henry (Hank) Carter is an assistant professor in the Department of Computing Sciences at Villanova University. His research interests are in applied cryptography in mobile computing, specifically in providing provably secure privacy solutions to mobile phone users. He completed his PhD and MS in Computer Science at the Georgia Institute of Technology in 2015 and 2012, respectively, and his undergraduate degree in 2010 at Belmont University.

Web page: http://www.henrycarter.org

Stage 1 Activities

FOSS Field Trip

GitHub

1. There are 15,865 repositories returned from a search for "education", with 1,370 explicitly tagged with the "education" topic
2. The commits graph on the insights tab shows the number of project commits each day for the past week and each week over the past year.
3. There are 332 repositories returned from a search for "humanitarian", with 20 explicitly tagged with the "humanitarian" topic
4. The latest commit on HTBox/crisischeckin was April 22, 2017
5. 174 search results returned for "disaster management"

OpenHub

1. Approximately 2250 projects were returned for "education"
2. All of the repository urls are in the domain kde.org, not GitHub
3. There are 10 similar projects
4. Open hub provides license info, number of lines of code, commit activity, number of contributors, and more.
5. Humanitarian returned 30, disaster management returned 30 as well
6. The projects with no activity information seem to be ones that do not have OpenHub users contributing to the project. The source is hosted on other services, presumably where the contributors are registered.
7. The organizations tab shows commercial and non-profit organizations that are affiliated with different projects on OpenHub
8. Oct 10, 2017, although the aggregate stats are only provided for code pulled 6 months ago.
9. Oct 10, 2017
10. OpenHub is aggregating information from other repositories in snapshots, so the stats may not be immediate.
11. Using both sources would provide broader coverage of available projects (including ones not hosted on GitHub), but may also provide inconsistent project information.

Evaluation

Evaluation Factor	Level (0-2)	Evaluation Data
Licensing	2	MPL 2.0 license
Language	2	Java 95.4%, SQLPL 3.0%, GAP 0.7%
Level of Activity	1	Q1,2: relatively active. Q3,4: relatively inactive
Number of Contributors	2	271 contributors
Product Size	1	220.81 MB
Issue Tracker	1	1308 ready for work across all categories, 10374 closed, XFRM-170 opened 10/25/2013, some tickets opened in 2017 but few closed this year.
New Contributor	2	Install: yes; Communication: yes; Discussion: OpenMRS talk has new activity; Web presence: yes, there is a website and wiki
Community Norms	2	Code of conduct: focused on teamwork, concrete punishment measures, requires a team to manage the community. Talk: all conversations I examined were very technical, questions and answers were both very detailed, did not find any indication of rudeness or poor behavior.
User Base	1	Lots of forks and activity in the talk forum indicate a good user base; Lots of instructions for downloading and building the code, less for how to use it.
Total Score	14

Copyright and License

1. OpenMRS
   1. Can: Use Commercially, Modify, Distribute, Sublicense, Place Warranty, Use Patent Claims. Cannot: Use Trademark from contributors, Hold Designers Liable. Must: Include Copyright, Include License, Disclose Source, Include Original
   2. I would be comfortable contributing, as there are no restrictions that would make my contributions legally problematic. The "cans" seem pretty liberal here.
2. Apache Fineract
   1. Can: Commercial Use, Modify, Distribute, Sublicense, Private Use, Use Patent Claims, Place Warranty. Cannot: Hold Liable, Use Trademark. Must: Include Copyright, Include License, State Changes, Include Notice.
   2. This one seems similarly liberal, so I would not have a problem contributing here. The Must category is slightly different, as the notice file must be included and changes must be specified, but this does not seem prohibitively difficult.
3. Regulately
   1. I cannot locate a license for this particular project
   2. Because there is no license information, I would be hesitant to contribute to this project. Liability issues in particular could be problematic and would possibly not be protected as with the previous two licenses.

Bug Trackers

Bugs

1. The following columns are defined as:
   1. ID: a unique identifier for the bug
   2. Sev: the severity of the bug, from blocker (code unusable) to trivial
   3. Pri: the priority of the bug, specified from P1-P5
   4. OS: the operating system where the bug was found
   5. Product: the software product that contains the bug
   6. Status: the status of the bug fix, from the values (unconfirmed, confirmed, in_progress, resolved, verified)
   7. Resolution: the way the bug was resolved, from the values (FIXED, DUPLICATE, WONTFIX, WORKSFORME, INVALID)
   8. Summary: a brief description of the bug and resulting behavior
2. To answer the question above, I used the help documentation on gnome.org and the bugzilla homepage
3. The bugs are initially sorted by status, with unconfirmed at the top
4. The color specifies importance. Red is high critical, black is normal, grey is normal enhancement.
5. I could fix Bug 595297 - The column header borders are not visible enough in inverse high contrast theme:
   1. Submitted Sept 15, 2009
   2. No discussion since November 2009
   3. This seems like an out of date bug
   4. The bug is assigned to the Banshee Maintainers
   5. Seems like a pretty trivial fix to modify color values in the settings for this particular mode, although trying a few different values on different monitors might be needed
6. I could also fix Bug 598952 - Document the use of an object attribute to expose toolkit/source:
   1. Submitted Oct 19, 2009
   2. No discussion since June 2011
   3. Also seems like a dead bug
   4. This bug is assigned to the ATK maintainer(s)
   5. More tedious than technical, this would just require sitting down and adding an attribute to Accessibility Technologies Kit objects to document which toolkit produced the object. There seems to be some issue in determining this, since multiple toolkits could be used, but simply listing all involved toolkits seems like a straightforward fix.

Reports

1. 303 opened, 237 closed
2. More were opened than closed, but the breakdown across the top modules shows net increase for about half and net decrease for the other half.
3. Philip Withnall, Edward Hervey, Florian Müllner. This tells you who is most active on the project and who you might contact for guidance.
4. Jeremy Bicha, Frank, Dan Jacobson. There's no overlap, the reporters are probably spending the majority of their time testing, not fixing.
5. Marcus Lundblad, Isaque Galdino, Víctor Manuel Jáquez Leal. There is some overlap further down the lists between these sets, but not in the top 3 (Except Marcus, who is a top reviewer and patch contributor). This indicates a generally good separation of duties so that multiple eyes are on any fix.
6. Mostly normal severity for braille
7. Reports can be generated across any of the fields specified in part 1. You could generate reports per assignee, reports over particular products, or reports over operating system.

FOSS in Courses

Part I

1. Programming II/Data Structures
   1. This course teaches intermediate programming techniques and basic data structures in Java. Topics include stacks, recursion, queues, lists, binary search trees, and implementation details pertaining to memory layout.
   2. Activity 1: Introduction to Git. I would very much like to introduce the idea of version control and the tools used to accomplish this. The Intro to GitHub activity would fit this need perfectly: http://foss2serve.org/index.php/Intro_to_GitHub_(Activity)
   3. Activity 2: Teaching documentation. I would like to encourage better documentation practices among the students. The documenting code with meaningful comments activity would be great for this, but I think I would like to have student teams write their own code and trade amongst the teams rather than giving them source code to comment: http://foss2serve.org/index.php/Document_Code_with_Meaningful_Comments_(Activity)

Part II

1. Introduction to Git
   1. Students should be able to Describe how version control allows useful collaboration and organizes edits into a tree structure. Also, they should be able to create and commit code to repositories for their course projects.
   2. This would require prerequisite knowledge on using a command prompt to navigate a file structure, as well as having all the necessary tools installed and an account on a remote repository.
   3. This would likely be a one or two session lab held early in the semester.
   4. The community best practices would be useful, but no direct input is required
   5. This would not result in a project contribution
   6. This assignment would likely be graded for completion. However, using git in future assignments would be required, and failure to do so would result in minor deductions.
   7. My only concern is that incorporating yet another tool into the course could be too overwhelming (I am already trying to use the course to teach Eclipse so that the students will have experience beyond a teaching IDE)
   8. Getting the students to go through a tutorial and prepare their programming environments before class will be critical to maximizing lab time, but is something I expect to be difficult to motivate.
2. Teaching documentation
   1. Objectives would be to identify relevant information that requires documentation and to practice writing complete documentation to be used in course projects.
   2. This would require some maturity in programming, but nothing additional
   3. Would likely be incorporated as lecture modules periodically through the semester, perhaps when new projects are assigned.
   4. Using example documentation from real projects would be ideal for illustrating best (and not-so-good) practices.
   5. No contribution
   6. Grading would again come from the course projects themselves, where a small percentage (5-10%) would be reserved for documentation
   7. No questions yet!
   8. Driving home the significance of this assignment will be the hard part, as students frequently discount the importance of documentation in code.