User:Wjin

Latest revision as of 12:57, 8 September 2018

Wei Jin Bio

Wei Jin is an Associate Professor at the Dept. of Information Technology at Georgia Gwinnett College.

Dr. Jin's primary focus is continuing improvement of student learning in CS1, the introductory programming course.

She previously worked on Automatic Tutoring Systems for introductory programming, for which she hopes to resume the work soon.

Since Spring 2017, she participated in the CS-POGIL project, which aims to improve student learning in CS1 through Process Oriented Group Inquiry Learning (POGIL).

Most recently, she was accepted into the 2018 POSSE and she hopes that she can help engage students using real-world FOSS projects.

Page: http://www.ggc.edu/about-ggc/directory/wei-jin

POSSE Journal - Entry 1

The Sugar Labs Project (http://sugarlabs.org/)

Contributions -- The page Getting Involved lists different ways people can contribute to Sugar Labs project. GGC, we have four tracks in Information Technology, including Digital Media and Software Development. Digital Media students could contribute as designers, while Software Development students could contribute as developer. They could collaborate on the same game/education tool.

Tracker -- From the Submit Bugs page, all you need to do is to identify the activity or a sugar component repository that you think is relevant, visit the issues tab of the repo, and hit the big green button to report your issue. For each ticket, you will need to include a summary title, type, priority and milestone. Each ticket will be assigned a ticket number and its status will start with new and can change to accepted, assigned, and etc. See here for a query result.

Repository -- According to https://github.com/sugarlabs/sugar/, the most recent commit is April 29.

Release cycle -- According to Information about Sugar's release cycle and roadmap, the roadmap is update at the beginning of each release cycle.

The Sahana Eden Project (https://sahanafoundation.org/eden/)

Community -- The structure is very similar to the one that I found on Sugars Labs website. For example, designers and developers are both ways that my students can contribute. The difference lie at the different nature of each project. Sugar involves educators, while Sahana Eden involves GIS specialists.

Tracker -- According to the Sahana Eden bug tracker, the bugs report is organized by categories, such as Active Tickets, Accepted & Active Tickets by Owner, My Tickts, All tickets, and etc. For each ticket, there are also differences as to what information is shown on the summary page. For example, priority and owner are information that are not shown at the summary page for Sugar but for Sahana Eden.

Repository -- According the https://github.com/sahana/eden, the date of last commit is May 2, 2018.

Release cycle -- The the page for the information about Sahana Eden's release cycle and roadmap is organized by milestones. Each milestone contains a data, the progress (a bar showing how much of the goal is done), and a list of issues to be addressed, with issues already resolved marked done.

POSSE Journal - Entry 2

One of the best known FOSS project hosting sites Github (https://github.com/)

Education -- A search for Education rendered 20,321 results. For each project, the Insight tab will provide information of the activities on the repository. For example, the Pulse page shows the activity summary of the current week, including the number of different activities and activities per person as a bar chart. The Commits page shows the commits along a time line and shows a line graph of comments vs. days of the week. For the free-programming-books project, most commits were done on Tuesdays.

Humanitarian -- A search for Humanitarian rendered 394 results. HTBox/crisischeckin is one of the projects. It is an application meant to capture, share and integrate the data around volunteers, organizations and resources actively deployed into a disaster. It was last updated on Nov 29, 2017.

Disaster Management Applications -- There are currently 36 such repositories for this category.

Another FOSS project site OpenHub (https://www.openhub.net/)

Education -- A search for Education rendered 2252 projects (226 pages of results, with each page 10 results and 2 results on the last page). KDE Education is one of the projects. It has 23 code locations. Each of them is located at a place like git://anongit.kde.org/*.gitNone of the location.

On the project place, four similar projects are shown. Towards the bottom of the project page, you will see summary of the project, including lines of code of the project overtime, line graph of commits per month vs the time line, contributors per month over vs the time line, programming languages used in the project, and etc.

Humanitarian -- A search for Humanitarian rendered 21 results.

Disaster Management Applications -- There are currently 6 such projects for this category.

Organizations Page -- This page provides four categories of information: (1) the most active organizations, (2) the new organization, (3) Orgs by 30 Day Commit Volume, which can be displayed with different filters, and (4) Stats by Sector (commercial, non-profit, education, and government).

Project OpenMRS Core -- The last commit for the project was on March 11, 2018.

Benefits/Drawbacks of using both GitHub and OpenHub to search for a project -- Github is a FOSS repository site, while OpenHub is not a repository site but contains information for FOSS projects that have code locations elsewhere. I would think that OpenHub uses software to discover FOSS projects on the web. It is also possible that it includes manual maintenance. These two sites complement each other. Together they give a more complete set of FOSS projects out there.

Project Evaluation Rubric for Choosing a HFOSS Project

Evaluation of the OpenMRS core repository (https://github.com/openmrs/openmrs-core)

Intro to Copyright and Licensing

The information contained in the table below is from https://tldrlegal.com/.

If there is no license granted, it is almost impossible to contribute since no license mean no right to copy. To read the code, the first step is to download/copy the code.

MPL 2.0 and Apache 2.0 seem to be quite similar and both be quite proper for HFOSS project.

FOSS in Courses 1

1. Identify activities or topics that you are interested in within your HFOSS project of interest.
   1. Intro to FOSS
   2. Intro to Copyright and Licensing
   3. Programming Styles
   4. Different Ways to Contribute to FOSS
   5. Evaluating a FOSS Project
   6. Documentation
   7. Use and evaluation
   8. Verify/Fix a bug
2. Activities for an Independent Study Course or HFOSS Programming Club
   1. There are existing materials for all the activities that I am interested. The introduction type of activities (such as those we did to prepare for the POSSE workshop) can be used as is.
   2. Activities that I also fount interesting:
      1. Deploy_and_Customize_Ushahidi
      2. Bug_Selection and Solving_A_Bug

POSSE Journal - Entry 3

Intro to Bug Trackers (Activity)

From the references contained in Intro_to_Bug_Trackers_(Activity), we learned about the features of ticket (issue, bug) tracking systems and the cycle of a ticket.

Part 1 - Bug Reports

Observations about a typical Bugzilla instance at GNOME (GNOME Accessibility Bugs):

1. The following are the columns shown for the ticket tracking system.
   1. ID: unique identifier for each ticket
   2. Product: product name. Currently 62 different names listed.
   3. Comp: Component. Currently 71 different components listed.
   4. Assignee: Who is assigned to fix the issue.
   5. Status: status of the issue. Possible values: UNCONFIRMED, NEW, ASSIGNED, REOPENED, NEEDINFO.
   6. Resolution:solution to the issue
   7. Summary: brief description of the issue
2. The bugs are initially displayed in the decreasing order of their IDs.
3. Different color represent different importance:
   1. black: High major
   2. gray: High enhancement
   3. red: Normal critical
   4. bold red: Normal blocker
4. Example Bug 1: Bug 683748
   1. When was the bug submitted? 2012-09-10 21:30 UTC
   2. What recent discussion has there been about the bug? Most recent discussion is on 2012-10-23 11:49:27 UTC, not long after the bug was reported.
   3. Is the bug current? Yes
   4. Is the bug assigned? To whom? Assgined to nome-shell-maint
   5. Describe what you would need to do to fix the bug: It seems that the code is not well organized. Big efforts required to organize the code better.
5. Example Bug 2: Bug 625016
   1. When was the bug submitted? 2010-07-22 09:28 UTC
   2. What recent discussion has there been about the bug? Most recent discussion is on 2014-02-25 07:51:43 UTC, reporting a similar problem in a new version of the software.
   3. Is the bug current? Yes
   4. Is the bug assigned? To whom? Assgined to evolution-addressbook-maintainers
   5. Describe what you would need to do to fix the bug: It seems to be a memory allocation and accessing problem.

Part 2 - Collective Reports

Click on the “Reports” link on the top of the page. Then click on the "Summary of Bug Activity for the last week".

1. Number of bug reports were opened: 70
2. Number of bug report closed: 125
3. What was the general trend last week? More bugs closed than opened than closed
4. Who were the top three bug closers? Why is this important to know? Adrien Plazas, John Ralls, Benjamin Berg. They are currently the most active contributors to the project, who might have a good knowledge of what's going on.
5. 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? Jannick, Sebastian Dröge (slomo), Linus Svensson. Not the same as nor overlap with the top three bug closers.
6. Who are the top three reviewers of patches? Nicolas Dufresne (ndufresne), Víctor Manuel Jáquez Leal, Thibault Saunier
7. What is the overlap between these lists and the bug closers and bug reporters? What is the overlap between patch contributors and patch reviewers? The bug closer list and patch review list have three people in common. Bug closer and patch contributor list have one person in common. The bug opener and patch contributor list have three people in common. The bug opener and patch reviewer have one person in common. The patch contributor and patch reviewer list have one person in common.

Click on the "Reports" link at the top of the page and then click on the “Generate Graphical Reports” link. Plot a line graph of the severity of bugs by component for Orca. Select "Severity" for the vertical axis. Select "Component" for the horizontal axis. Select "Bar Graph" for type of graph. Leave the "Multiple Images" as <none>. Scroll down and select Orca from the Product menu. Click "Generate Report".

1. What class were the majority of the bugs for braille? Minor
2. What other reports can you generate? line, table, cvs

Intro to GitHub (Activity)

I have completed all activities on Intro_to_GitHub_(Activity).

FOSS in Courses 2

Activities for an Independent Study Course or HFOSS Programming Club

• Deploy_and_Customize_Ushahidi (In-class activity -> Homework)
  • Learning outcomes: follow instructions to install an actual running server
  • Prerequisite: client-server architecture
  • Instructor prep time: 1-3 hours to perform the activity ahead of time, prepare in-class activities to help students to get an easy start with the activity, and prepare homework assignments for students to complete the activity on their own.
  • Time for students to complete the work: 2-4 hours
  • This can be done independent of the HFOSS community if the installation instructions are clear.
  • If the instructions are not clear or could be improved, feedback can be provided to the HFOSS community.
    • Under this situation, students need to learn how to bug tracker system works.
  • This will be a team activity. The grade depends on how much they will have completed the activity and the amount of time it takes the team. The time requirement is to encourage the teams to get help early when needed.
• Verify/Fix a bug (In-class activity -> homework)
  • Bug_Selection (In-class activity -> Homework -> Project)
  • Solving_A_Bug (In-class activity-> Homework-> Project)
  • These are preparation activities for eventually fixing real bugs in a chosen HFOSS project.
  • Learning outcomes: learn the guidelines in evaluating bugs and work in team to address an issue
  • prerequisite knowledge: bug tracking system, Github
  • Instructor prep time: 2-4 hours
  • Student time: 2-4 hours
  • This will be a team activity.
  • Concerns: When students go for a real bug in a real HFOSS project, the amount of time needed to fix the bug might be difficult to track without the instructor's full participation.

Stage_2_Activities/Stage_3_Planning_-_Capstone Open_Source_Communication_Activity_version2