User:Emirielli

Revision as of 19:03, 12 November 2014

Ed Mirielli

I am Chair and Professor of the Computer Science and Information Technology Department at Westminster College in Fulton, MO. Fulton is located about 90 miles south-west of St. Louis and about 30 miles east of Columbia, MO. Westminster College is a 4-year, primarily residential liberal arts college with around 1100 students. Currently our CS and IT program has about 50 majors - and growing.

My research and scholarly interests include software engineering, HCI, AI and machine learning, applied statistics, and pedagogy. I am a big believer in interdisciplinary scholarship and have worked collaboratively in epidemiology and demography, computational sociology, computer science, information technology, and psychology. I am currently working with a chemistry department colleague on bringing back to life our chemistry instrument laboratory and establishing a data collection repository for chemical analytics.

When I'm not teaching, learning, and performing administrative tasks, I like to cook and eat BBQ and play golf. These activities can be so relaxing.

Part 1 – Walk through of IRC Conversation

• How do people interact? People are interacting in a soft, semi-formal fashion. There seems to be a specific purpose for this interaction and chat-meeting. The interaction seems to embrace inclusivity by encouraging questions and interaction among the participants.

• What is the pattern of communication? The pattern of communication is alternating between questions, answers, and proposing and reconciling issues or problems. There is a management of the communication by the moderator who interjects summary statements indexed by keywords to capture the salient qualities of the interactions and to establish action steps for further exploration or outcomes.
• Are there any terms that seem to have special meaning? The use of keywords in the form of syntax specific notations (e.g. #info, #action, #topic, etc.) for the chat allow, as stated above, categorization of content and particular thread elements to be organized for later use and summarization.
• Can you make any other observations? There's not a large number of participants - 6 not counting the BOT for this chat session, I guess that will vary from project to project, although I can see how managing this could get hard to follow with LOTS of participants. However, with the moderation and management of content using the IRC commands, the resulting summary report provides a nice way to know what the outcomes of the meeting are and who is responsible. Some participants are asking more questions than others; the questions are being answered or strategies proposed to consider for solving an issue. Problem solving is being attempted and potentially achieved in near real time for some things. I think that this system of communication facilitates quick access to knowledge and problem solving specific to a project's context.

Part 3 Followed GNOME Accessibility Team with little traffic.

== Part B: ==

B1. FOSS Field Trip:

*Use the Search feature in the center of the screen to view applications in an area of interest to you (e.g., gaming, sports, music, computing, etc.).

>>Searched for data mining

*How many projects are there in this category?

>>Really cannot determine definitively since there's seems to be no single authorities summary statistic available. I added up individual items from the refine searches selection for estimate my Best guess = 929pages * 25per page = 23225 projects in this search category... however, "Data Mining" with quotes = 11pages * 25 = 257 projects.

*How many different programming languages are used to write software in this category? >>Data Mining = 15, that that seems common for most projects. "Data Mining" = 12

*List the top four programming languages used to write programs in this category.

Data Mining JAVA (5575) C++ (3035) PHP (2421) C (2288) "Data Mining" JAVA (93) C++ (35) PHP (16) C (13)

*Identify the meaning of each of the statuses below:

Inactive - project seems as though is not currently being worked on or it has been a while last update > year...

Mature - project activity hard to determine especially when there's no content other than a URL to another website, many of the projects in this category have much of the same characteristics as some of the inactive projects.

Production/Stable - at least 1 production release is available for download

Beta - a beta release has been made available for download

Alpha - an alpha release may be available for download

Pre-Alpha - project is new, so little ready for an alpha release yet

Planning - still in planning stages and seeking assistance, little or nothing ready to download and use

*Compare two projects in this category that have two different statuses. Describe the differences between the statuses.

I am comparing 2 project identified from the "Data Mining" (with quotes) search - 1 = Production/Stable and 1 = Mature. My selection criteria for the project is based on the top project appearing after selecting the "Sort By" = Most Popular. I have excluded any projects from the list that are designated "Enterprise" as this seems to confound that search results.

Mature (N=6 excluded=1)

Project Title: RapidAnalytics - Business Analytics

Downloads (this week) = 61

Last Update = 8/9/2013 User Ratings = 15 - 5 star ratings (each rating sub-class is 0/5) Indented Audience = Advanced End Users, Developers Programming Language = JSP, Java Registered = 7/10/2014

Languages = English, German User Interfaces = Web-based

File Download list - only 1 single entry last modified = 3/22/2013

Support = URL redirect

Wiki = NONE

Code = NONE

News = NONE

Production/Stable (N=34 excluded=1)

Project Title: Weka

Downloads (this week) = 15378 Last Update = 2 days ago User Ratings = 49 5 start ratings (ease of use 4/5, Features 5/5, Design 4/5, Support 4/5) Indented Audience = Developers, End-user/Desktop Programming Language = JAVA Registered = 4/27/2000

Extensive File Download list - last modified = 10/31/2014

Support = redirect to other URL

Wiki = general description identifies purpose, provides screen shots

Code = RO no (more) commits

News = last 2 posts 8/15/2013 and 7/6/2011 - EACH seems a bit out of data with the rest of the site's data.

Conclusion: The Production/Stable project is more active with interest and content. There is seemingly more activity from both the user and developer community as compared to the Mature project. The mature project is designated as "mature" only in the sense that it has been around for an extended time, although it is not very active.

*Which projects are the most used? How do you know?

Initially, since I was unable to find an operational definition of the project status ratings, I thought that Mature project would be more used, but my initial comparison demonstrates that Production/Stable projects are most used by the development and user community. This is based on the download and update frequency. Clearly the status rating is a NOMINAL designation since the numerical index (1-7) do not imply anything with regard to any significant empirical or quantities differences between projects.

*Pick a project in your category. Answer the questions below: 1. What does it do? provides a machine learning tool for advanced analytics. 2. What programming language is the project written in? JAVA 3. Who is likely to use the project? How do you know this? Analysts, desktop users 4. When was the most recent change made to the project? 10/31/2014

5. How active is the project? How can you tell? It is very active with 15378 this past week and the last update being 2-days ago

6. How many committers does the project have? There is no Committer data available for this project.

7. Would you use the project? Why or why not? Would you use the project? Why or why not? Just based on knowledge of this project's purpose and reputation I would use it for USER activities and consider participation as a developer. However, since it seems that SourceForge is not the main site on which development is taking place, this is yet to be determined.

Part 2 - Ohloh

• What is the main programming language used in Mifos? JAVA

• How many lines of code does Mifos have? 2,673,467

• List some of the locations of the developers. >> These data Will not display in IE or Chrome...

• How many languages is Mifos written in? 19

• What language has the second highest number of lines of code? XML

• Of the programming languages used in Mifos, which language the has the highest comment ratio? Perl

• What is the average number of contributors in the last 12 months? < 2

• How long have the top three contributors been involved in the project? >> Getting gateway error...

• Compute the 12-month average of commits. What is the average number of commits over the past 12 months?. 30 commits/12 = 2.5

Project Evaluation Activity

• Mifos Evaluation Template

B3 - Blogging Activity

My Initial BLOG.

B4 - FOSS in Course Planning 1

We have a significant curricular investment in matriculating students towards a comprehensive software engineering experience. And it is from the perspective of "experiences" and not "courses" that focuses my attention. Much of the provided content and activities for FOSS engagement are highly relevant to contributing to this effort. I think that the POSSE workshop structure is an excellent starting point; this is especially true given its roots and focus stemming from the classroom experiences of others. My intention is to outline some activities and experiences similar to those from POSSE and then change them at various levels of breadth and depth within and across different courses. Below are some specific activities to potentially develop:

• Compare and contrast FOSS to Commercial SW projects using the guides provided for FOSS Field Trip

The outcome here would be to comprehend the similarities and differences in the various dimensions characterizing SW projects. While much of the detailed data available via SourceForge and ohloh would be a challenge to find for commercial vendors, students would be able to articulate important questions about projects independent of type (FOSS vs. Comm). This could be extremely useful in a job or internship interview setting.

• Focus on Documentation

As was pointed on in Andy Lester's Blog, documentation often "gets short shrift." As is common in most CS/IT/SWE programs, the "D-word" carries a burdensome and negative image. And as we all well know, documentation is at least as important as the code when it comes to project management and evaluation. For this activity I would ask students to examine various FOSS project documentation for its clarity of writing, topical focus, and relevancy to its intended purpose. Then based on the use of objectively defined rubrics and standards, the documentation would be rewritten and peer-evaluated. The final step would be to propose submission to the FOSS project. Clearly this is a writing intensive assignment lacks a certain sex appeal, but is one of the biggest differentiators for students in getting hired and eventually promoted; nobody likes documenting.

• Enhancing Coder self-efficacy

Needless to say, making coding contributions to a FOSS project is what many of us aspire to. It is the most popular aspect, the first thought by those interested, but at the same time deemed out of reach. Several of the POSSE articles for this section discuss the fact that even though "genius coders" are not necessary, it seems my code is likely not good enough to contribute. I believe this is a mind-set and something to be overcome though practice and comparison and contract. In this activity, after examining what FOSS is and its rich history and usefulness, I would identify within a FOSS project some code that performs some specific action or behavior. I would recast that code block into a well formed and detailed SRS (complete with style and functional & structural requirement) and make it a programming assignment. Upon completion, the students code would be compared and contrasted to what is actually used in the FOSS project. I would escalate the complexity of the problems and code until students coding self-efficacy increased -- as well as their objective ability. Now we are confident in our ability and ready to make a contribution.

C Part 1 - Bug Reports

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 - The unique identity of each "bug"
• Sev - Classification of a "bug's" severity: blocker, critical, major, normal, minor, trivial, enhancement
• Pri - A designation of the bug's priority to be addressed - immediate, urgent, high, normal, low
• OS - operating system on which "bug" was observed: AIX, BSDI, Cygwin, GNU Hurd, HP-UX, IRIX, Linux, FreeBSD, NetBSD, OpenBSD, opensolaris, OSF/1, Solaris, BeOS, Mac OS, Neutrino, OS/2, Windows, OpenVMS, other
• Product - any of the GNOME products or components - a very extensive list.
• Status - Current state of the "bug" is classified as: unconfirmed, new, assigned, reopened, needinfo, resolved, verified
• Resolution - "bug" has been resolved and classified as: fixed, wontfix, duplicate, notabug, notgnome, incomplete, invalid
• Summary - a short description of the "bug"

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

Interestingly, these definitions are not in the HELP glossary, where I would expect to look and find them nor was I able to find them in the "help". Using the "hint", the definitions are available as "tool-tips" while hovering the mouse over the detailed selection criteria within the advance search option. Alternatively these definitions are also located here: https://bugzilla.gnome.org/page.cgi?id=fields.html

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

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

6. What is the meaning of the colors used when describing a bug (red, gray, black)? Red is for "critical" severity bugs; Black is for seemingly all others but enhancement;

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). This is not a reasonable expectation give the whole theory related to "productively lost"; there is simply no way to know how to contribute to fixing a bug without additional understanding of the product and all its components and modules. With that said, I selected bug ID=363439 Description=Use CSS/XSLT names for text attribute mappings from enums ; this choice is based on recognizing most the terms referred to in the description.

7.1. Identify when the bug was submitted. 2006-10-19 15:36:42 UTC

7.2. Identify if there has been recent discussion about the bug? No discussion since 2013-11-13 19:07 UTC

7.3. Is the bug current? This bug is classified as "normal" and is still "open" with no resolution.

7.4. Is the bug assigned? To whom? Bug seems to be currently assigned to user a9016009..., originally assigned to to bill.haneman

7.5. Describe what you would need to do to fix the bug. First I would inquire about the true status of this bug to determine if it is still open, or if it was fixed and the ticket never closed. Upon that outcome I would, if still open, then research more about what the "atk" product is and then further research the recommendations contained in the various message threads.

8. Repeat the previous step with a different kind of bug.

8.1. Identify when the bug was submitted. Bug ID = 722917, Description=List of open 'easy to fix' bugs needs rework; product=gimp-web; submitted=2014-01-24 14:35:59 UTC

8.2. Identify if there has been recent discussion about the bug? No discussion since 2014-01-31 11:58:51 UTC

8.3. Is the bug current? This bug is classified as "normal" and is still "open" with a status of NEEDINFO with no resolution.

8.4. Is the bug assigned? To whom? User=schumami has set the status to NEEDINFO from it's UNCONFIRMED status

8.5. Describe what you would need to do to fix the bug. Given that the list of "easy to fix bugs" in gimp is dependent on some ADMINS's reconciliation of the way that "easy" bugs are flagged, there's little I can contribute to on this one.

Part 2 - Collective Reports

2. How many bug reports were opened in the last week? 350 How many were closed? 465

3. What was the general trend last week? of the 15 products listed, 6/15 closed more bugs than were opened; Were more bugs opened than closed or vice versa? Overall more opened than closed, but that is not universal by product.

4. Who were the top three bug closers? Mocera,Fortin Tam, Crha Why is this important to know? These are the most active contributor and seemingly closest to the system.

5. Who were the top three bug reporters? Jo, Ray, Desluriers Are these the same as the top three bug closes? NO What is the overlap in these two lists? Fortin Tam is the only person in both lists

6. Who are the top three contributors of patches? Danielsson, Ray, Cecchi

7. Who are the top three reviewers of patches? Droge, Mullner, Mocera What is the overlap between these lists and the bug closers and bug reporters? some of the same people are doing much of the work. What is the overlap between patch contributors and patch reviewers? contributors are often reviewers too

8. Click on the “Generic Reports” link.

9. Plot the Severity of each Version of the Accessibility features of Empathy.

10. What other reports can you generate? WAY TOO MANY OPTIONS! We can generate all sorts of reports - highly customizable

Part 2- Source Control

Done -- Thanks Stoney!

Creating an account and forking the original Foss2Serve repository was easy and strait forward. The "pull request" was not so clear. While I was able to make the request, it was not apparent that I did not have WRITE/COMMIT access. I thought we would be performing all the actions directly. So I closed the pull request thinking that would complete the commit. Stoney Jackson noted to me the basic instructions for what I had done, and he committed the changes. Just wanted to note this for future reference.

Part 2 - Course Planning 2

Goal:

I will be taking what I have learned during POSSE and applying it this spring with 3 or 4 students as part of my sabbatical - I am wanting to develop a highly structured and supportive independent learning experience in "distributed software engineering" using FOSS projects. The item below are my initial outline in achieving this goal.

• Compare and contrast FOSS to Commercial SW projects using the guides provided for FOSS Field Trip

The outcome here would be to comprehend the similarities and differences in the various dimensions characterizing SW projects. While much of the detailed data available via SourceForge and ohloh would be a challenge to find for commercial vendors, students would be able to articulate important questions about projects independent of type (FOSS vs. Comm). This could be extremely useful in a job or internship interview setting.

Update:

This assignment would be the pre-requisite knowledge needed for conducting the other tasks. Obviously there would be some significant amount of reading on FOSS, its history and evolution similar what we have been doing.

Modifying the existing lessons to focus differently will require several hours of effort per module. I anticipate little if any traditional lecture but more of a discussion format since this activity will be part of a hybrid/blended course. As with many assignments in a hybrid/blended/flipped environment, students underestimate the time commitments necessary to complete at a high-level of accomplishment (/me don't I know it); this is especially true when the work is self-directed. This concern will also apply to the professor during execution and delivery - I must be available via electronic media at relevant and opportune time. These would be some of the possible concerns.

• Focus on Documentation

As was pointed on in Andy Lester's Blog, documentation often "gets short shrift." As is common in most CS/IT/SWE programs, the "D-word" carries a burdensome and negative image. And as we all well know, documentation is at least as important as the code when it comes to project management and evaluation. For this activity I would ask students to examine various FOSS project documentation for its clarity of writing, topical focus, and relevancy to its intended purpose. Then based on the use of objectively defined rubrics and standards, the documentation would be rewritten and peer-evaluated. The final step would be to propose submission to the FOSS project. Clearly this is a writing intensive assignment lacks a certain sex appeal, but is one of the biggest differentiators for students in getting hired and eventually promoted; nobody likes documenting.

Update:

Some students are more interested in the NON-Coding aspects of software development and this task would allow the project-manager type to explore more deeply these aspects of FOSS. Given the experience with Part C and the bug-tracking, this too would allow students to generate reports and examine the management of projects from a perspective that just cannot be replicated in the traditional learning classroom. Once students become familiar with the tools and the project, they would be better able to contribute in a more traditional fashion to a FOSS project. As such, I think the FOSS community would be very open and welcoming to this. Taking the existing lessons and tweaking them to do more - both broadly and deeply, would require several hours to complete. For this I do not seem too many obstacles or stumbling blocks.

• Enhancing Coder self-efficacy

Needless to say, making coding contributions to a FOSS project is what many of us aspire to. It is the most popular aspect, the first thought by those interested, but at the same time deemed out of reach. Several of the POSSE articles for this section discuss the fact that even though "genius coders" are not necessary, it seems my code is likely not good enough to contribute. I believe this is a mind-set and something to be overcome though practice and comparison and contract. In this activity, after examining what FOSS is and its rich history and usefulness, I would identify within a FOSS project some code that performs some specific action or behavior. I would recast that code block into a well formed and detailed SRS (complete with style and functional & structural requirement) and make it a programming assignment. Upon completion, the students code would be compared and contrasted to what is actually used in the FOSS project. I would escalate the complexity of the problems and code until students coding self-efficacy increased -- as well as their objective ability. Now we are confident in our ability and ready to make a contribution.

Update:

Obviously this is the one that the true "programmer" wants to be involved in. It is likely the most involved pedagogically for the faculty and preparation wise for the student. A very in-depth study of a programming language will be necessary - this is true especially for projects using a language unfamiliar to the student or faculty. Project knowledge too will have to be gained quickly but some of that can be managed using the evaluation template so students and faculty alike can size up a project from a number of dimensions. This task is likely to take many hours to structure so that it truly guides the student in both process and content. Dropping a student into a project with little guidance or support along the way will be a sure way to alienate students from FOSS and make this a poor learning and teaching experience.