User:KNarayan

From Foss2Serve
Jump to: navigation, search

Contents

Krish Narayanan

Krish Narayanan is a professor in the Department of Computer Science at Eastern Michigan University. She also serves as the undergraduate advisor in the department, a faculty fellow in the Honors College, and the faculty advisor for Women in CS club. She teaches both undergraduate and graduate courses, ranging from Intro to Programming to Advanced Database Systems. Her teaching and research interests are in the areas of databases and software engineering, with a focus on design. She has been actively involved in CS education over the past few years.

In her spare time, she teaches computer science to kids, especially middle and high school girls (Girls in Computing). She has been an avid Science Olympiad coach/supervisor for many years. She runs an event called iCompute for an elementary science olympiad. She has coached a few Girls in Computing teams to compete at the EMU High School Programming competition.

Check out Krish's blog

POSSE Stage 1 Activities - Pre-workshop

Link to deliverables

Intro to Wikis

1. How do people interact? Just like other IM interactions.

2. What is the pattern of communication? People in the chat room can communicate with all or with individual users. They can also issue IRC commands like /help.

3. Are there any terms that seem to have special meaning? Any text prefixed with # is a MeetBot command.

4. What advantages might IRC have over other real-time communication methods (like Google Chat or Facebook Messenger?) Are there potential disadvantages? Looks and feels techie! MeetBot and other services are a plus.

5. Can you make any other observations? The MeetBot summarizes the meeting pretty well. I understand that it is more work for the meeting chair but it is worth the trouble.

6. Bonus question: Why didn't Heidi and Darci's actions get picked up by the meetbot? A username is case-sensitive. The MeetBot looks for usernames in interactions for action assignments.

Sample HFOSS projects

SugarLabs

  • computer use in education (K-12)
  • many roles, such as, educator, developer, designer, translator
  • coding in Python, JavaScript
  • base module is called Glucose
  • base activity modules are called Fructose
  • Google Summer of Code
  • last push in March 2014!

SahanaEden

  • humanitarian platform for solutions to disaster management, development, environmental management
  • many roles, such as, devloper, tester, translator, designer, GIS specialist
  • coding in Python, JavaScript, SQLite
  • Communication through Google Groups, IRC, mail lists
  • last active ticket in 2015

OpenMRS

  • Open Hub project since 2007
  • a platform to store medical records for healthcare
  • initial adoption in Kenya
  • targeted towards non-programmers to help them customize a solution to their needs
  • mostly Java-based with some JavaScript
  • last commit was in August 2016

FOSS project hosting

SourceForge

A search for "Education" on the website and further refining the search to "Puzzle Games" resulted in 227 projects. There are 65 Java, 59 C++, 27 Python projects included and many more. Each project has a status associated with it, such as, stable, alpha, planning, etc. These indicate the stage of the development cycle they are in. For example, FindThatWord is in beta testing while FS.WordFinder is in production. The projects can be sorted using different criteria, such as, last updated, most popular, and rating. Brain workshop seems to be the most popular wheres Ohod Quiz Game seems to be the last updated.

I liked these projects:

  • Brain Workshop
  • IncrediBots
  • Sudokuki
  • Build your own jeopardy
  • Brain speed test

Brain Workshop is a Python project implementing a popular brain exercise. It is obvious from the reviews that anyone interested in mental exercises would like this app. There are 5 committers to the project. The last update was in August 2015. This is not a suitable project for contribution since it is well in production. There doesn't seem to be many maintenance/change requests.

OpenHub

OpenMRS is a moderately active project which was analyzed 26 days ago based on code collected 3 months ago. It is mostly written in Java. It is written in 15 languages, such as, JavaScript, XML, and Perl. It has 3.73 million LOC. The top three committers to the project have been active for the last 3-5 years. The average number of contributors in the last twelve months is around 10. The average number of commits in the past 12 months is around 30.

Mousetrap is another interesting project which provides a simple library for handling keyboard shortcuts in Javascript.

Walkthrough of OpenMRS

Mission-critical criteria : Viability

  1. Size/Scale/Complexity: A closer look at OpenMRS's architecture shows that a number of different tools and technologies are in play here. With over 3 million LOC and the use of multiple programming languages, I would rate this project a 3 on a scale of 1 to 3 for its size/scale/complexity. The high rating is warranted considering the small projects that students are usually working on in CS classrooms. The use of MVC pattern, Spring framework, Hibernate for object-relational mapping, and MySQL is a good blend of different technologies that students in our curriculum have been exposed to in a CS classes. It would be a good learning experience for them to bring them all together in one application.
  2. Activity: An average of 30 commits per month seems to be reasonably good for an active project.
  3. Community: OpenMRS seems to be an active project with over 950 downloads and releases as late as in August 2016. The community seems to be actively involved in OpenMRSTalk and IRC and constantly pushing updates. This kind of a community would encourage students to be actively involved, contribute, and learn. Here are some resources. Resources page IRC logs discussion platform Tickets page How-To Submit Code page
  4. Domain:
  5. Maturity:
  6. User support:
  7. Roadmap:

Mission-critical criteria : Approachability

  1. Project on-ramp: The project has a wealth of documentation on how one could get on-board and start contributing. The developer guide provides a wealth of information regarding how to get started, a database of past issues and how they were solved, current issues one could contribute to, and other useful resources. I would rate the approachability of this project very high.
  2. Contributor types:
  3. Openness to contributions:
  4. Student friendliness:

Mission-critical criteria : Suitability

  1. Appropriate artifacts: Browsing the section on introductory issues on the developers guide shows that issues are classified as bug fixes, task, improvement and new feature. There are a total of 71 issues listed. The tickets page list a step-by-step process for creating new issues (new features or bugs). It also lists a similar process to work on issues. These issues seem something students can work on. They have all the necessary information to get started and the issues seem to involve a manageable amount of time and effort to leave the students with a sense of contribution to a big project.
  2. Contributor support: In addition to the above resources, the resources page and how to submit code page provide all the necessary support for new comers to the project. Guidelines for code submission, coding standards and commit privileges are also provided. I would rate the contributor support for this project very high.
  3. Project description:
  4. Platform:
  5. Development features:

Overall evaluation of OpenMRS for a course

A careful evaluation of the project shows that it is a good fit for student's capstone experience in a CS curriculum. It provides exposure to a number of technologies, a large-scale project, team work, and a substantial support for students.

FOSS in a class

There are a number of ways to contribute to a FOSS project, including, writing and fixing code, analyzing code, modifying code to meet standards and conventions, prototyping and designing solutions, adding documentation, creating blog posts, updating wikis, doing historical and other related research, providing feedback and reviews, using and evaluating software releases, reporting bugs, responding to queries, learning to interact with a community, teaching others, investigating software licensing, understanding privacy/security issues and their applications, packaging and distribution of software, fundraising, brainstorming new features and enhancements, and helping with installation and other adoption issues. These are just a few of the many different options discussed in the following resources.

Below is a collection of resources to help with creating course content for a FOSS class. This content was copied from FOSS in Courses 1 (Instructors)

I am interested in using OpenMRS for my class project. I would likely start my students off with the following activities before contributing code:

  • Researching the project
  • Lurking in the IRC channels
  • Asking questions about ongoing project activities
  • Shadowing a contributor
  • Writing blogs/wikis
  • Downloading and installing the latest release
  • Providing experience reports on using the software
  • Submitting a bug report

I am considering a new FOSS class. ideally, I would like students to be able to contribute to a project at many different levels. The above list includes activities that do not require software development skills. I would like to spend at least a third of the semester on such activities and then have students contribute to the code base for the rest of the semester. The latter contribution would be a small-group effort and would mimic a CS capstone course with the exception of an ongoing, large, geographically distributed, well-defined, well-understood (by the students), and well-supported software development project.

Bug Tracker Activity

Bug reports

The GNOME Bugzilla has a collection of bugs reported by users and developers. An advanced search shows that the following are used to describe bus/issues.

  • ID - a 6-digit identifier
  • Sev - Severity, ranging from critical to trivial
  • Pri - Priority, ranging from immediate to low
  • OS - Operating system
  • Product - name of the entity associated with the bug, such as, gnome-panel
  • Status - status of the bug in the lifecycle, ranging from unconfirmed to verified
  • Resolution - the final decision on a bug report, such as, duplicate, obsolete, etc
  • Summary - short description of the bug

The bug report shows a list of bugs, ordered by status, with uncommitted ones at the top. These bugs then transition to new, assigned, needinfo, resolve, and unverified. Base on the severity of these bug reports, they are color coded. Red implies critical, black represents normal, and grey represents enhancement.

A bug that I can contribute to is here. This "new" bug was submitted in Aug 2016 and has not been assigned yet. It seems to report missing information in the GNOME user documentation - gnome-help. The bug reporter includes the pages in which the license agreement do not show up and also provides a patch to fix this bug. How difficult can this be!

Another bug that caught my attention is here. I am not sure if I could fix this, but it seems to be an interesting problem that cropped up after an update of a supposedly unrelated functionality. The problem seems to be with gnome-screenshot taking 100% of a cpu time. The bug reporter includes a bunch of components that were updated. This may be a difficult task to track and might have been a problem with regression testing or lack therof.

Collective reports Weekly bug summary for the week of Nov 7th, 2016 show the following:

  • No of opened reports = 308
  • No of closed reports = 268
  • The top three bug closers were Michael, Milan, and Alexandre. These are probably the active contributors to the project at this point in time.
  • The top three bug reporters were Piotr, Bob, and Phillip. These three contributors could be working on the QA aspect of the project. They don't seem to bug closers.
  • There doesn't seem to be much of an overlap between the above two lists.
  • The top three patch contributors were Phillip, George and Ignacio. There is at least one person on this list that is also a patch reviewer. But, for the most part these lists seem to be non-overlapping.
  • There seems to be one bug reporter who also submitted a patch.

The generate graphical reports page allows you to generate a wide variety of reports, on different parameters, such as, severity, number of components, resolution. You could generate a bar graph, line graph or pie chart on the data. The graphical report for Orca reveals that the component named "braile" had 0 major bugs, 19 normal bugs, 0 minor bugs, and 10 enhancements.

FOSS in a class - round 2

The class I am planning to use FOSS will be a new, upper-level undergraduate class. At EMU, we are allowed to cross-list classes between UG and graduate programs. So, the course would be attended by UG seniors and graduate students. I would expect students to to have experiences in advanced programming concepts, data structures and algorithms. I am questioning whether this course should have the software engineering course as a co-requisite. The two courses could supplement each other. If I decide to go with this idea, I would make all projects in this course individual ones. If not, I will have small group projects.

I would probably use one or both of the following as textbook(s) for the class:

Lectures would be based on the book contents. Readings and group discussions are possible options too.

Initially, would get students started with non-programming activities to get them to experience open source development. These activities could involve the following:

  • Researching a FOSS project
  • Lurking in the IRC channels
  • Asking questions about ongoing project activities
  • Shadowing a contributor
  • Writing blogs/wikis
  • Downloading and installing the latest release
  • Providing experience reports on using the software
  • Submitting a bug report

I would expect this initial exploratory phase to take about a third of the semester. I hope to have classroom discussions based on student experiences.

For the rest of the semester, I will have students contribute to code, through bug fixes, patches, new feature development, and such. This is going to involve significant time and effort on my part to research ahead of time and develop meaningful assignments for the students. It should include firm deadlines and deliverables till the end of the semester. It would be nice to have the community that the students are contributing code to, to provide feedback.

I plan to use the following resources for course planning:

POSSE Stage 2 Activities - Workshop

POSSE Stage 3 Activities - Post-workshop

Retrieved from "http://foss2serve.org/index.php?title=User:KNarayan&oldid=8758"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox