Planning the next semester

POSSE workshop, Friday Nov 18, Exercise for planning the upcoming semester.

1) First three things I want to accomplish in my course (491a in Spring 2017)

• Teach github version control and issue tracking (intro and use tools in lab)
• Reengineering (and maybe later) refactoring requirements and design documents from roadmap, documentation, and issue tracker (lead, Nanette interested in this)
• Contributing to code and/or documentation in repository (plenty of documentation on this in foss2serve wiki)

2) Three things I need to do at POSSE to continue working when I get home

• Find sparring partner
• Select a project
• Define a plan, milestones and action items

3) Next three things I need to do when I get home

• In detail description of required student preparation and the activities (as in pogil.org)
• Email class with detailed preparation plan
• Set up surveys (reuse existing standard to contribute to existing data collection, lead by Grant Braught)

FOSS@CSULB Course Preparation

FOSS in Courses 2

Background

This activity is an extension of the FOSS in Courses Planning 1 activity. The goal of this activity is to have
a 1-3 topics and/or learning ideas to bring for discussion to the workshop and receive feedback on.
We do not expect that these activities/ideas will be completely fleshed out, but to provide an initial starting
point to think about.

Here are ways that I can use FOSS activities:

• Lectures: FOSS examples, FOSS as a hands-on experience

• In-class activity: introductory POSSE assignments (see below)

• Homework: solving an introductory issue

• Stream of related activities: set up github, learn bug tracking, install a FOSS project

• Project: solving a set of related issues

*Questions for myself*: How to include the software lifecycle here - or better into CECS 343/543/542.
Take ideas from Heidie's course on that.
For design, what can I come up with? Documentation assignments in 343 to understand.
This was a major take-away for many students in my 343s, because they do little projects in other courses.
For testing?
For quality assurance?
Documentation is easier... there are lots of tasks there.

Revised activities

"Reengineering a Software Requirements Specification"

Description: Reengineering a SRS from a roadmap and issue database and coming up with a set of questions
on what the functionality should be and what is unclear, then ask community.
Learning outcomes: How to write a requirements specification, how to analyze an issue database and
what to critically ask for making sure that a SRS is sufficiently complete.
Pre-requisite knowledge: Content model of a SRS, requirements notation techniques, how to read issue databases
Time required: for instructor prep (1h), for student completion (3h) and elapsed calendar time (2 weeks incl. feedback)
Input required from the HFOSS community: (optional) feedback on specs and list of questions.
Contribution and usefulness: Requirements documentation in case there wasn't any.
Assessment/grading approach: Base on SRS & list of questions, team activity, (optional) co-rating of spec by community (?)
Questions or concerns I have: Does the community do things like that? How do I select a useful format of SRS?
Would 5 specs of the same system be useful??
Stumbling blocks or barriers: None so far.

"Understanding Design activity"

To-Be-Description: Understanding the existing design? Not much to be graded, unless I quiz them on it... 
Or let them first understand it and then reengineer a SDS? Are they not existent in documentation yet?

Learning outcomes: How to analyze and assess design, hot to develop or reengineer a design spec.
Pre-requisite knowledge: Content model of a SDS, design notation techniques, how to read documentation
Time required: for instructor prep (1h), for student completion (3h) and elapsed calendar time (2 weeks incl. feedback)

Input required from the HFOSS community: (Optional) feedback on specs and list of questions.
Contribution and usefulness: Design documentation in case there wasn't any.
Assessment/grading approach: Base on SDS & assessment, team activity (assessment could be individual), co-rating of spec by community (?)
Questions or concerns I have: Does the community do things like that? How do I select a useful format of SDS?
Would 5 specs of the same system be useful??

Stumbling blocks or barriers: None so far.

"Quality Assurance activity"

Description: Give students a checklist of what to look for: Code documentation, version control documentation,
structure and modularization, "clean-ness" of interfaces, etc.

Learning outcomes: How to analyze a an implementation and a code repository.
Pre-requisite knowledge: Code repositories, some coding skills (enough to read & understand code)
Time required: for instructor prep (1h), for student completion (3h) and elapsed calendar time (1 week)

Input required from the HFOSS community: None.
Contribution and usefulness: None.
Assessment/grading approach: Assessment, individual activity
Questions or concerns I have: None.

Stumbling blocks or barriers: None so far.

Bug tracking

Bug Tracker Activity

Background:

Bug tracking systems are a form of change management and organization used by FOSS projects.
Bug trackers do far more than simply keep track of bugs. They also are used to hold new feature requests,
patches, and some tasks. Bug trackers are also called request trackers, issue trackers, request trackers and
ticket systems. Please read the two readings below for a more complete treatment of bug trackers and their use
in FOSS projects.

• Karl Fogel's chapter on bug trackers
• Wikipedia's page on Bug Tracking Systems

Directions:

We will begin by looking at a typical Bugzilla instance for a project. We will be using GNOME's Bugzilla instance,
but specifically looking at the bugs for the Accessibility Team.

Part 1 - Bug Reports

1. Open a browser and go to the GNOME Accessibility Bugs
2. Define what each of the column names below indicate. Include the range of possible values for 2-7 below.
   Feel free to explore beyond the page to find more information.
   1. ID: unique identifier for each bug
   2. Sev: severity - how bad is it? From blocker ("application unusable") to trivial ("minor cosmetic issue")
   3. Pri: priority - how important is this to resolve? Assigned by developer.
   4. OS: Operating system with which the bug occurred
   5. Product: where the bug is observed.
   6. Status: How far along in the process is it?
      [UNCONFIRMED, NEW, ASSIGNED, REOPENED, NEEDINFO]
   7. Resolution: How was it solved? What may help for resolving it?
   8. Summary: of the issue in one sentence.
3. Describe how you discovered the definitions and how did you find the information from above
   (hint: the advanced search shows the options or the Reports link has a link)? Previous knowledge.
4. Identify the order in which the bugs are initially displayed? According to Status.
5. What is the meaning of the shading of some bug reports? Shaded ones are less critical or minor
6. What is the meaning of the colors used when describing a bug (red, gray, black)?
   Red is critical, black normal, grey enhancement
7. Select a bug that you think that you might be able to fix and look at it more closely - 385900 
   1. Identify when the bug was submitted. 2006-12-14
   2. Identify if there has been recent discussion about the bug? Not since 2011
   3. Is the bug current? Yes, seems to be according to status.
   4. Is the bug assigned? To whom? To a role (Panel Maintainer) but not an individual developer.
   5. Describe what you would need to do to fix the bug. Find the document or piece of code where this
      originates - nobody has been able to identify it so far.
8. Repeat the previous step with a different kind of bug. Did it for a couple more, nothing out of the ordinary.

Part 2 - Collective Reports

1. Click on the “Reports” link on the top of the page.
2. Click on the "Summary of Bug Activity for the last week".
3. How many bug reports were opened in the last week? How many were closed? 18 opened, 13 closed.
4. What was the general trend last week? Were more bugs opened than closed or vice versa? 5 more opened.
5. Who were the top three bug closers? Why is this important to know? Sebastian, Michael, and Milan.
   They are probably product champions and likely to be able to help finding ways to resolve more of them.
6. Who were the top three bug reporters? Are these the same as the top three bug closes?
   What is the overlap in these two lists? Vrishab, Mohammed, and Sebastian. Yes, the latter one.
7. Who are the top three contributors of patches? Philip, Carlos, and Bastien.
8. Who are the top three reviewers of patches?
   What is the overlap between these lists and the bug closers and bug reporters?
   What is the overlap between patch contributors and patch reviewers?
   Sebastian, Florian, Milan. Only one overlap.
9. Click on the “Generate Graphical Reports” link.
10. Plot a line graph of the severity of bugs by component for Orca:
    1. Select "Severity" for the vertical axis
    2. Select "Component" for the horizontal axis
    3. Select "Bar Graph" for type of graph
    4. Leave the "Multiple Images" as <none>
    5. Scroll down and select Orca from the Product menu.
    6. Click "Generate Report".
11. What class were the majority of the bugs for braille? Normal.
12. What other reports can you generate? Tabular reports and change over time.

FOSS In Courses Activity

When many people think about including FOSS in a class, they are typically thinking of one of two things:

1. Finding an artifact from the FOSS project such as a code segment that provides the base for study within the classroom (e.g., code review), or
2. Making a code contribution to the project by fixing a bug or making an enhancement.

However, there are myriad different activities based on FOSS as well as ways of contributing to FOSS projects that go beyond coding. The purpose of this activity is to explore some of the other ways to introduce students to and/or involve students in FOSS projects.

Observing some of the different activities and ways to contribute starts with understanding what these are. Helpful resources for new developers trying to learn about it are:

1. Andy Lester's 14 Ways to Contribute to Open Source without Being a Programming Genius or a Rock Star
2. Craig Buchek's great list of ways to contribute other than code
3. The list of activities on the 50 Ways to be a FOSSer page

For educational purposes, there are further resources to draw from:

1. There is a set of learning activities
2. TeachingOpenSource has a Teaching Materials Catalog
3. Steve Jacobs at RIT has a Open Source Course

For OpenMRS in my course, activities or topics that I am interested in are:

• The introductory assignments as we are doing right now for POSSE.
• Solving introductory issues across the system to get students used to the way of working in this particular project and to get them set up with the development environment.
• Bigger topic or module: I am not sure which one to choose here.

Existing materials for those activities are:

• Introductory assignments: Intro to FOSS, project anatomy (and evaluation), learn IRC and other types of channels or forums, version control (git), bug tracking (also on github)
• Solving introductory issues requires the list thereof and the new developers guide
• The to-be-chosen bigger topic requires the technical overview of the project and then more documentation on that active project or module.

Walk through of an evaluation of the OpenMRS project

There are many criteria which should be looked at when determining if a project is appropriate to use in your class. These criteria are broken into two groups - mission critical and secondary.
I am using these criteria to determine whether the OpenMRS project would be a good fit for the software engineering senior design course in Spring 2017 at CSULB.

Mission Critical Criteria-Viability

1. Size/Scale/Complexity - An ideal project should be neither overly simple nor overly complex.
   1. On the OpenMRS web page (http://openmrs.org/), there's the OpenMRS Wiki (under Other OpenMRS sites). From the menu on the left expand the Developer Guide and the Getting Started as a Developer options and then look at the Technical Overview. From examination of the technology stack, the architecture looks modular and further search shows it is documented elsewhere on the site. This provides a first look at the complexity of the application and the number and various different technologies involved.
   2. Based upon the results from OpenHub (gathered in the FOSS Field Trip activity) and the information from the OpenMRS Technical Overview page, think about the size of the code base and how many different technologies and layers are involved in the application. What would you score this project for size/scale/complexity on a scale of one to three where one is "low" and three is "high"? Probably a medium because it could be more complex but it is certainly sufficiently complex to learn the ropes and to have to focus.
2. Activity - To support student participation a project should be reasonably active. Number of commits can be used as an indicator of activity.
   1. Based upon the number of commits (gathered in the FOSS Field Trip activity) would you consider this project active? This project can be considered as active because it had on average more than a commit per day over the past 12 months, so that is a good basis for assuming that the activity will also continue for a while longer.
3. Community - A suitable project has an active user community. While it is difficult to quantitatively evaluate the activity of a user community, some indicators include a regular history of project downloads and documentation updates over time, current activity on user mailing lists, and testimonials on the project web site.
   1. Examine download activity
      1. Go to sourceforge.net and enter OpenMRS into the search box.
      2. Choose OpenMRS from the search results.
      3. Click on the number of downloads that is listed on the project page. 976 downloads this week is pretty good!
      4. Change the date range to give a graph of downloads over the last year. 72,490 downloads in the last year. This certainly makes for a large enough user community.
   2. OpenMRS has begun migrating legacy mailing list activity to OpenMRS Talk. Examine discussion activity: The user and developer forum is very active and well moderated.
   3. Examine the IRC logs: The IRC logs show good communication, high activity, and good netiquette.
   4. Based upon the download history, discussion activity, and IRC activity, do you feel this project has a good community? This project certainly has a good community, multiple leaders, highly spread developer community, everything that seems to be necessary for a community to thrive.

Mission Critical Criteria-Approachability

Here you are evaluating a project's on-ramp to contribution, scoring as follows:

1-Insufficient-Few or no pointers on how to become involved.

2-Sufficient-Suggestions about how to get involved other than contributing money with accompanying high-level instructions.

3-Ideal-Obvious link to get started, list of suggestions for things to do and detailed instructions.

1. Examine project on-ramp.
   1. Link to getting started - The website has a Get Involved page with links to ways you can contribute and share your ideas.
   2. Each of the links (Develop, Test, Document, Translate) contain more detailed information about what and how you can contribute.
   3. The Getting Started as a Developer page contains a detailed list of how to get started including a list of introductory issues.
   4. Detailed instructions - The Developer Guide contains instructions and information in many areas including process, architecture, tools, and developer documentation.
   5. Based upon the resources you looked at, how would you rate the approachability of the OpenMRS project? This project certainly has everything in place for thriving development, and I would rate it as very approachable. Developing, testing, documenting, translating are all options for contributing. Sharing is also encouraged via connecting, suggesting, spreading the word, or just getting an OpenMRS ID.

Mission Critical Criteria-Suitability

1. Appropriate Artifacts - Since evaluation is dependent on class objectives, in this example we'll assume the objective is to learn the process of working in an authentic development environment by contributing bug fixes to OpenMRS.
   1. Opportunities to contribute bug fixes - Examine the issues found at the bottom of the getting started as a developer page. The introductory issues are categorized into curated and non-curated, which means that there are some that have a thorough description of how to solve them, while others don't. There are 39 curated and 70 uncurated introductory issues listed.
   2. Documentation on how to contribute bug fixes - On the Tickets pagethere is information on how to create and work on an issue, including links to coding standards and the code submission process. 
   3. Based upon the number of bugs suitable for students to tackle and information on the process of how to submit bug fixes, do you think this would be an appropriate project for your students? Based on the number of introductory issues, even though I think my students would especially like to start on curated ones, I think this would be a suitable project.

2. Contributor Support - Does the project have a high volume of guidance to help students as they learn?

1. Communication Tools - Communication tools are directly available from any of the Wiki Spaces (Documentation, Projects, Resources). The Resources page contains links to OpenMRS Talk and IRC Chat, as well as links to group meetings (under Events), and training opportunities.
2. Web Presence - Examine the IRC logs. There has been plenty of activity during the last week.
3. Operating Processes - Links to information about coding standards, the code submission process, and commit privileges can be found on the How-To Submit Code page. The process for making feature requests is available on the Tickets page. These processes are well documented.
4. Response to Questions - Review a few of the posts on the OpenMRS discussion platform. Posts to this forum seem to receive timely and supportive responses.
5. I would you rate the support that newcomers to OpenMRS receive as really good.

In summary, it looks like the OpenMRS project is a very suitable project for the course according to the mission-critical criteria. The project is viable, approachable, and suitable. The community is very active, very supportive, and very well documented. The cause of the project is to support healthcare worldwide. It is a medical records system.

For the secondary viability criteria, for understandability of the domain, the required domain-knowledge is not too complicated. Maturity, user support, and roadmap are all given as well.

Secondary for approachability, the types of contributions, the openness to contributions, and the friendliness to students also seem to be given.

Secondary for suitability, the project description is very accessible, the project is platform-independent, and the development features provide enough options for all students to find general as well as very specific issues.

So for the secondary criteria, the rating is also good for OpenMRS.

Exploring Open Source

I am on a mission to explore open source and I am learning how to teach it so I can incorporate it in my software engineering senior design project in Spring 2017. This is an account of some of my activities while exploring and learning.

FOSS Field Trip 

Part 1 - Exploring SourceForge

One of the best known of these FOSS project hosting sites is Source Forge (http://sorceforge.net/). I explored projects in SourceForge to gain an understanding of the key characteristics of a FOSS project.

I used the Search feature in the center of the screen to view applications in the area of

"Mountains" because I am a mountain addict.

There were 19 projects in this category?

Five different programming languages are used to write software in this category.

The top two programming languages used to write programs in this category are C++ and Lua, and there were only 3 other programs in other languages.

The meaning the different statuses of an open source project is the following:

Inactive - "no longer actively maintained"

Mature - "well established"

Production/Stable - "ready to promote for wide use"

Beta - "ready for rigorous wide user testing"

Alpha - "test phase by general users, unstable, preliminary release"

Pre-Alpha - "not ready for public, under development"

Planning - "under planning"

Comparing two projects in this category that have two different statuses did not give me a whole lot of choice because most of the projects were rather inactive, but some more than others :)

Project that was the most used was called "Fracplanet" according to the number of downloads (22 last week).

Fracplanet is an interactive application to generate and view random fractal planets and terrain with oceans, mountains, icecaps and rivers, then export them to POV-Ray format or Blender.

The programming language the project is written in is C++ with Qt and OpenGL.

The people who are likely to use the project are 3D modelers, which I take from the categories provided in the description and in the reviews.

The most recent change made to the project was in April 2016.

The project is not very active according to the code repository updates. Furthermore, it has only one committer.

I wouldn't use the project unless it is for a one-time need and fits me well enough, because it is not active enough with one contributor, even though somewhat recently updated.

Part 2 - OpenHub

In this activity, I used OpenHub to gather information about a Humanitarian Free and Open Source project named OpenMRS (https://www.openhub.net/).

For the OpenMRS Core project, I identified when the data in OpenHub was last analyzed and the last commit date. It was analyzed 25 days for the 3 months ago committed code; 2 months ago was the last code pull but no commit.

The main programming language used in OpenMRS Core is Java.

The lines of code of OpenMRS Core are 3,739,232 lines of code.

OpenMRS is written in 15 languages and the second highest number of lines of code is in JavaScript.

Of the programming languages used in OpenMRS, the language that has the highest comment ratio is Java.

The average number of contributors in the last 12 months was about 15.

The Top Contributors have been involved in the project for 3-5 years.

The average number of commits over the past 12 months was about 40 per month, so a little more than one per day.