User:JBarr

From Foss2Serve

(Difference between revisions)

Jump to: navigation, search

Latest revision as of 01:29, 7 February 2017

John Barr

Bio

John is an associate professor in the Department of Computer Science at Ithaca College. He's been teaching computer science for over 25 years and primarily works in the area of computer science education. He's taught in various locales in the U.S. and internationally (Egypt and Qatar). Recent work includes mobile development (iOS and Android), global software development education, and innovative computer science pedagogy.

POSSE 2016 Exercises

Stage 1 Part A

Answers to the questions from "Intro to IRC" part 1:

How do people interact?

Through short messages and interactively. Much like texting.

What is the pattern of communication? Is it linear or branched? Formal or informal? One-to-many, one-to-one or a mix?

Informally. There seems to be an agenda, but the discussion varies broadly. Discussion is many-to-many though occasionally several people will dominate the conversation.

Are there any terms that seem to have special meaning?

Terms preceded by a hash seem to be commands.

Can you make any other observations?

Participants seem to have some idea of the agenda or topics before the discussion begins. The discussion also seems to be a continuation of an ongoing discussion. There are assignments made.

Answers to part 3: Intro to Wiki

Summarize your observations (of your selected HFOSS project). Pay particular attention to the ways that the selected project differs from the sample dialog you exampled in Part 1

Answers to part 6, Anatomy of a FOSS Project:

Contributions: Summarize the roles that you think would be most applicable for your students on your faculty wiki page. If you think that more than a single role is applicable, indicate why. What are the commonalities across roles? What are the differences?

Sugar Labs Project

Students could serve in a variety of roles. For example, students could serve in the "Educator" or "content writer" functions designing activities, creating media, etc. They could also serve as developers (our CS majors) or designers (our Emerging Media majors). Designers and developers share some overlap in the sense that each influences the other (and both work together in the engineering process). It seems that educators and content writers would work together in the same way.

Tracker: Describe the general process for submitting a bug and indicate the types/categories of tickets listed on this page as well as the information available for each ticket

Hmmm, signed into github and clicked on the "issues" tab of many projects, but none had issues.

Repository: Can you determine from the information provided here whether the project uses a web-based common repository or a local repo?

The project seems to sue GitHub, at least for many of their libraries and projects.

Release Cycle: Include an entry on your wiki page that describes how the release cycle and roadmap update are related.

The release cycle details how a release is produced in theory. The release team decides on the features, module versions, etc. to include in the release plans out the use of resources, etc. At the beginning of the release cycle the development team updates the roadmap to set specific schedules, module versions used, new features and tickets addressed in the release. The roadmap seems to be a public plan for the release.

SahanaEden Project

Community Summarize the information about contribution types. For example, are there any commonalities? Is there something distinct for each type of contributor? How is this structure different than the one you found on the Sugar Labs website?

The contribution types seem to be quite distinct at least in terms of required skills. Developers seem to work in python, designers use client-side web technologies (e.g., CSS and html), and testers seem to mostly do use-case testing. This implies that the roles would fit different types of classes since the student skills would have to vary across these roles.

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

This project seems to be using a wiki or perhaps dedicated tracking software whereas the Sugar Lab tracker was part of github. In the SahanaEden tracker tickets seem to be listed in the order received; in the Sugar Labs tracker it was by project or module.

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

request management, gis tracking, tests, css-UI, etc. Information includes version, priority, type, owner, status, and creation date.

Repository Can you determine from the information provided here whether the project uses a web-based common repository or a local repo?

They apparently use gitHub, so a web-based common repository.

Release cycle Include an entry on your wiki page that describes the information you find here.

The roadmap lists key features integrated, the developer responsible for the feature, whether the feature was added in beta or stable form (for modules) or was backend, internationalization or support material. For future features a time estimate is also given.

Stage 1 Part B

Answers to the questions from "FOSS Field Trip" part 1

See Blog.

Answers to the questions from "Project Evaluation Activity" part 2

See Blog.

Answers to the questions from "Blogging Activity" part 3

uh, see Blog.

Answers to the questions from "FOSS in Course Planning I" part 4

Chosen project: Ushahidi wiki or Ushahidi home

FOSS topics for COMP 39000, Mobile Programming:

General FOSS topics
- Open Source philosophy
- IRC, wiki's, blogs
- GIT

Ushahidi topics:
- Overview. See this tutorial
- Create a CrowdMap
- Installing Ushahidi
- Listening to IRC's
- Write a test/add comments
- Confirm a but
- Create an Android client

Stage 1 Part C

Answers to the questions from "Bug Tracker Activity" 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.

ID: unique issue identifier Sev: Severity of the issue. Pri: Priority of the issue. OS: OS that the bug was found on. Product: The particular software that the bug affects. Status: The current status of the issue. Resolution: Description of how the issue was resolved. Summary: Description of the issue.

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)?

Went to the "Advanced Search" page and also looked at the user guide.

4. Identify the order in which the bugs are initially displayed?

Originally sorted in numerical order by ID.

5. What is the meaning of the shading of some bug reports?

Did not see any shading.

6. What is the meaning of the colors used when describing a bug (red, gray, black)?

Seems to be related to the importance. Any type of critical level issue is in red any enhancement is in gray, any normal is in black.

7. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). 748924, gnome-disk-uti, "Orca announces some buttons as button"

   a.  Identify when the bug was submitted.  2015-05-05 03:09 UTC by Alfonzo.
   b.  Identify if there has been recent discussion about the bug?  There are no comments.
   c.  Is the bug current?  Yes.
   d.  Is the bug assigned? To whom?  No, it's status is NEW not ASSI.
   e.  Describe what you would need to do to fix the bug.  Need to access the source and determine how the labels are assigned.  If they're assigned statically, need to change the label text.  If they're assigned dynamically, need to determine how this is done and perhaps change a text file.

8.  Repeat the previous step with a different kind of bug. 747665, gnome-control-, "the background layored pane does not speak with orca"
   a.  Identify when the bug was submitted.  2015-04-11 00:28 UTC by kendell clark.
   b.  Identify if there has been recent discussion about the bug?  There are no comments.
   c.  Is the bug current?  Yes.
   d.  Is the bug assigned? To whom?  No, it's status is NEW not ASSI.
   e.  Describe what you would need to do to fix the bug.  Need to access the source and determine how the background layout pane is loaded and how components communicate with the background.  Possible that the background is consuming events or that the components are not registered to receive the events.

Answers to the questions from "Bug Tracker Activity" 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?

292 bugs were reported, 395 were closed.

4. What was the general trend last week? Were more bugs opened than closed or vice versa?

Depends on the module. In general, more issues were closed than opened. In the modules where more issues were opened, the number was small, e.g., 1-5.

5. Who were the top three bug closers? Why is this important to know?

Michael Gratton, Matthias Clasen, Nicolas Dufresne (stormer). Important since these are the people most active in the code maintenance and decisions about features and general structure should be directed at 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?

Bastien Nocera, Alexandre Franke, Allan Day. Not the same (though Bastien Nocera is the number 4 bug fixer). People working on code can often find other bugs.

7. Who are the top three contributors of patches?

Bastien Nocera, Debarshi Ray, Rui Matos.

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 Dröge (slomo), Nicolas Dufresne (stormer), Bastien Nocera. These three are also top bug closers. People working on code should review patches.

9. Click on the “Generate Graphical Reports” link.

10. Plot a line graph of the severity of bugs by component for Orca:

   a.  Select "Severity" for the vertical axis
   b.  Select "Component" for the horizontal axis
   c.  Select "Bar Graph" for type of graph
   d.  Leave the "Multiple Images" as <none>
   e.  Scroll down and select Orca from the Product menu.
   f.  Click "Generate Report".

11. What class were the majority of the bugs for braille?

normal.

12. What other reports can you generate?

You can generate reports by bug details, by people, by change history and though an advanced search.

Answers to the questions from "FOSS in course planning II"

FOSS topics for COMP 39000, Mobile Programming

Activity 1: Overview of Ushahidil

Activity

Read this tutorial

Outcomes:

a. Understand what Ushahidi does.

b. Understand the open source model used by Ushahidi.

c. Understand the open source community behind Ushahidi.

Background Knowledge

a. Understand the basic tools used in open source development (IRC, GIT)

Time Required

a. Instructor prep: 1 hour

b. Student Completion: 2 hours

c. Activity will not be synchronized with the Ushahidi community.

Input from HFOSS community

a. None.

Contribution to the HFOSS project and its usefulness

a. N/A

Assessment/Grading

a. Individual project

b. No HFOSS community role.

c. Work will not be committed or otherwise accepted by the community.

d. Basis for grading: a quiz on Ushahidi and its community.

Questions about the activity/task

a. None at this time

stumbling blocks or barriers to carrying out the activity/task

a. None

Create a CrowdMap

Installing Ushahidi