User:Rhoyle

Latest revision as of 00:48, 20 April 2017

Roberto Hoyle

Roberto Hoyle is an Assistant Professor in Computer Science at Oberlin College, in Oberlin OH. Oberlin is a small, liberal arts college 40 minutes outside of Cleveland. It has around 2700 students, and around 80-100 of them are Computer Science majors.

Roberto researches Privacy and Security, focusing on how people communicate on online social networks. He received his doctorate from Indiana University, Bloomington in 2016.

Stage B, Part 1:

• There are 12,378 repositories that reference education, the top one is nodejs/education
• It provides a historical overview of commits over time. There were two last Monday.
• There are 291 humanitarian repos. The last commit for crisischeckin was Aug 7, 2017
• There are 144 disaster management repos.

Stage B, Part 1:

• It looks like there are around 3,460 repositories for education.
• All of the code is on kde.org
• There are 10 similar projects listed
• Assuming the question refers to the similar projects, the information is the primary language and the license type.
• Humanitarian has ~40 projects, disaster management has around 60
• It seems that the activity is not available because of issues with incorrect code location, or becausae they don't let openhub scrape their pages.
• Organizations provides a list of organizations and how much they commit.
• OpenMRS Core Apps had a last commit 28 days ago.
• Last commit on github was 2 days ago. I assume the discrepancy is because openhub doesn't do scraping that frequently.
• Openhub seems easier to search, and give you more general information. Github seems more up-to-date, but more utilitarian.

Stage B, Part 2:

Stage B, Part 3:

OpenMRS: Mozilla Public License 2.0 --- Same as Apache, no concerns.

Apache Fineract: Apache License 2.0 --- I would be comfortable with this, it allows me to do what I want as long as some notices are kept

Regulately Back End: No license information found

Stage B, Part 4:

As my class is intended to be a software engineering course, there needs to be a substantial amount of programming done by the students. Contributing in non-programming ways would not fit in the course goals. I would lead my students towards:

a) Fixing a bug from the bugtracker

b) Adding test cases to the testing suite

There's materials online on the bugtrackers, but I couldn't find something on testing programs.

Stage C, Part 3:

Bugtracker

Learning Outcome

Pre-requisite Knowlegde

Time Requirements

Input from HFOSS Community

Contribution to HFOSS

Assessment / Grading

Questions / Concerns

Stumbling Blocks

Adding Test Cases

Learning Outcome

Students should be able to identify test cases that should be covered in subroutines in an HFOSS project and add suitable test cases to fix this deficiency.

Pre-requisite Knowledge

Students should know the programming language for the project. Students should be familiar with whatever testing suite is used in the project, as well as with git.

Time Requirements

Instructor Prep: Instructor should come up with an example program to code up in class, and think up test cases that the program should pass. This project should be independent of a HFOSS schedule.

Input from HFOSS Community

None necessary, but guidance on which areas may need more testing would help channel efforts.

Contribution to HFOSS

A more robust testing scheme. Possibly, the identification (and maybe fixing) of some bugs.

Assessment / Grading

This assignment can be split into a couple of in-class activities, followed by work done independently by the students.

1) In class assignment: code an algorithm that the students know (e.g. binary search)

2) In class assignment: come up with various testing scenarios by formulating hypotheses on what should be tested and how. Instructor should guide this to ensure that the principles behind edge cases and testing are covered. Students will then implement tests that will cover these cases, ensuring that their algorithm passes them.

3) Homework assignment: Students need to review a section of an HFOSS project and pick a subroutine for testing. They should design a robust set of tests, and implement them. Ideally, the subroutine should pass the tests, but if it doesn't, students should file it as a bug report, or if possible, fix the bug. Students should then add their test cases to the general repository so that they are run automatically on each build.

Questions / Concerns

Stumbling Blocks

Need to make sure that the program is in a language that the students are familiar with, and that it has units that make sense for unit testing.

Stage A, Part 1: Notes from IRC Assignment

• How do people interact?

The communication style seems to be informal, though focused on a single subject at a time. Everyone seems to jump in when they have something to say, but the meeting chair takes notes with the update and action commands.

• Are there any terms that seem to have special meaning?

Actions, Updates, and Next Steps have meanings that are picked up by meetbot

• What advantages might IRC have over other real-time communication methods (like Google Chat or Facebook Messenger?) Are there potential disadvantages?

The bot is extremely useful for keeping track of minutes and action items.

• Bonus question: Why didn't Heidi and Darci's actions get picked up by the meetbot?

They weren't triggered by the chair?

Notes from Intro to FOSS Anatomy Assignment

• Summarize the roles that you think would be most applicable for your students.

My students would mostly be interested in the designer or developer roles.

• What are the commonalities across roles? What are the differences?

Communication seems to be a common thread throughout the roles. Each role also has a contact person that can be used to get a new user started. In terms of differences, there's all sorts of skills that would be useful. It's not just programmers or translators that are needed.

• Describe the general process for submitting a bug

Go to the github repository and submit an issue.

• Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.

Types: : defects, enhancement requests, and tasks. For each ticket, you have a high-level description, the name of the person who submitted it, severity, and information on how to replicate the issue. There's a comment section for each issue as well, showing the interactions between developers discussing the issues. Finally, there's a status.

• Record the date on your wiki page

Oct 10, 2016

• Describe how the release cycle and roadmap update are related.

The roadmap is the list of all the upcoming features. The release cycle is the list of features that will make it into the current release, and a timeline for the release.

Sahana Eden:

The developers section seems more formalized with regards to the steps that users take. The testers and designers sections are not as fleshed out.

• How is the information here different than the information found on the Sugar Labs tracker page?

There is a different version of Trac being used, one that has pre-built reports that you can select. When you click through to the individual bug report, it looks similar to SugarLab.

• Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.

Types: defect/bug, documentation, enhancement, task. The information available seems to be similar.

• Record the date on your wiki page

11 hours ago

Release Map:

They have 3 releases planned, and have a display bar showing how close they are to getting each release out the door.