User:SWeiss

Latest revision as of 01:37, 7 February 2017

Stewart N. Weiss

Short Bio

Stewart N. Weiss is an Associate Professor in the Department of Computer Science in Hunter College of the City University of New York, New York City's public university system. Hunter College has more than 23,000 students and 1800 full- and part-time faculty members. As of spring 2016, the Computer Science Department consisted of eleven full-time faculty members, with two more joining the Department in fall 2016. Prof. Weiss joined the Department in 1987 and has been teaching there ever since.

Prof. Weiss received his Ph.D. in Computer Science in 1987 from the Courant Institute of Mathematical Sciences of New York University, under the mentor-ship of Dr. Elaine Weyuker. His research interest was in the area of software testing, concentrating on the testing of parallel and concurrent software, but also expanding to theoretical and experimental comparisons of various software testing methods and paradigms. Prof. Weiss's research later shifted to include the study of improved methods of computational quantum chemistry, specifically in approximation methods for computing molecular energy using ab initio methods.

More recently, Prof. Weiss has become interested in computer science education as a research topic in itself, with a particular interest in the teaching of software testing to computer science students.

Prof. Weiss was not always a computer scientist. He started out by earning a degree in architecture school from The Cooper Union for the Advancement of Science and Art, in 1973, and worked in that discipline, initially in architectural offices, and later with his own design and construction firm, through 1980, when he returned to school to obtain an undergraduate degree in mathematics. What architecture, mathematics, and computer science have in common is the creation of things, such as physical environments, models of abstractions or natural phenomena, or software. Consistent with this is that, in his spare time, Prof. Weiss loves cooking, indoor gardening, building and repairing furniture, and photography.

Online Presence

I do not use social media in general, but I have a blog for the POSSE work, a personal blog, and my academic website.

My blog on teaching computer science is here,
my personal blog is here, and
my teaching website in the college is here.

IRC Activity

1. How do people interact on IRC?
   People write "comments" that are seen by all who are logged into the channel. Comments are typically short, no more than a single line, but sometimes they are longer. Some of the comments are commands to MeetBot. The MeetBot application defines the chairperson as the one who started the meeting.
2. What is the pattern of communication? Is it linear or branched? Formal or informal? One-to-many, one-to-one or a mix?
   The pattern of communication is very much like the interaction that takes place in an informal group meeting. There are one-to-one and one-to-many conversations. One-to-one is sometimes implicit and sometimes made explicit by starting a comment with the person's name, e.g. "Stoney, ...". The conversation is mostly linear, but it also branches. This is largely dependent on the discipline of the meeting members. In the particular meeting about Mousetrap, the conversation is fairly disciplined, with almost no divergence from the purpose of the meeting. The meeting was discussing updates and so there were different threads relate dto different updates. The chair does not have to intervene at any point to control the discussion.
3. Are there any terms that seem to have special meaning?
   There are various commands given to MeetBot, which have special meaning. They are identified by the leading character, #.
4. Can you make any other observations?
   Unlike a face-to-face meeting in which people see each other, in an IRC meeting, there are no visual clues as to who has something to say at any moment. You cannot see who is about to "talk" next. The sequence of comments flows fairly well, but it can sometimes have different threads running through it. I suspect that this has much to do with the group dynamics and how well the people know each other.
5. Why didn't Heidi and Darci's actions get picked up by the meetbot?
   Nicknames are case-sensitive, and the MeetBot can only assign an action item to a person if their nickname is used in the action item. The items not picked up had the wrong case.
6. Observations of an IRC channel
   In general I did not find much conversation going on in the few project channels that I tried to monitor. I am guessing that a 24-hour window might be small because the amount of activity is a sparse function of time with bursts of activity that may be much further than 24 hours apart.

Sugar Labs Project Anatomy

1. What roles in this project do I think would be most applicable for my students?
   Students have different skill sets in my classes, so there are a few different roles I foresee being possible. One is that of a content writer. Most students can handle writing either documentation, code, or guides of various forms and degrees of technicality. More likely is that the students will fit into the develop role, possibly with a bit of stretching. Some students like to code, some to debug, some to test, some to package things up, and so on. There is a task for all of my students as developers.
2. Overview of the bug tracker.
   The process of tracking a bug begins by creating a Sugar Labs trac instance. The trac instance is registered in the database and generates a work ticket. Work tickets can be tracked, commented upon, and edited in various ways. They are reviewed periodically by a "BugSquad". Tickets can represent defects or enhancements. The information associated with a ticket includes:
   
   • a general description,
   • distribution OS,
   • bug status,
   • ticket type,
   • owner,
   • reporter,
   • priority,
   • severity,
   • milestone, and
   • version.
3. About the Repository.
   The Sugar project uses a git repository. This can be inferred from the location URL: git://git.sugarlabs.org/sugar-base/mainline.git.
4. Relationship between the release cycle and the roadmap.
   According to the Sugar Lab webpage, "the Development Team's Roadmap is updated at the beginning of each release cycle by the release team."

Sahana Eden Project Anatomy

1. How is the information provided for people wishing to contribute as a developer, tester, or designer similar, and how is it different?
   It is interesting that the most detailed information is provided on the page for potential developers. There we find a detailed set of instructions, including joining the IRC chat and mailing list, reading a technical training manual, developer guidelines, and the signing of a contributor license agreement. While testers and designers are also encouraged to read the developer guidelines, they are not asked to sign any agreements, nor are they encouraged to follow the chat or join the mailing list. Testers are given a link to an extensive technical description of the test and bug reporting process, but designers have the least useful information on their page. This suggests that the priority of the project is oriented to recruiting developers.
2. How is this structure different than the one you found on the Sugar Labs website?
   The Sahana Eden project's contributor roles are much more detailed and specific than the Sugar project's roles. In fact, the information provided by the Sugar project is much less formal and clear. There is not a distinguished tester type in the Sugar project; testers are a special case of developers.
3. How is the information about the Sahana Eden Bug Tracker different than the information found on the Sugar Labs tracker page?
   The Sahana Eden Bug Tracker page is much more well organized. It provides a system of report generation based on a wide range of criteria. For example, one can view currently active tickets or various types of closed tickets, such as recently fixed "FRP" bugs. The set of types of tickets in Sahana is a superset of those in Sugar - it also includes documentation and task tickets. The data included in a single ticket is essentially the same though.
4. Does the Sahana Eden project use a web-based common repository or a local repo?
   The Sahana Eden project maintains a web-based repository on GitHub, but they also urge developers to clone off of the trunk repo and work in their own local repos, unless they intend to contribute to the project, in which case they also need a GitHub account and need to work with the web-based (i.e., GitHub) repository. In fact they give a very clear explanation of the workflow in their guidelines for developers.
5. Information about the Sahana Eden release cycle and roadmap.
   The Roadmap is a fairly detailed and informative description of each release, of which there are presently three, 09., 1.0, and 2.0, together with information about features, links to tickets, and timelines. The roadmap itself does not lend itself to finding information about how the release cycle is organized, however, the timeline on the website does. One can use the timeline to see each change, and when it was made, accurate to the minute, in full detail.

Thoughts on FOSS in Courses at Hunter College

The burning questions, the ones that gnaw at me whenever I think about FOSS and teaching, is

1. how to integrate it into the courses that I currently teach, and
2. what course(s) I could teach in my department that would
   
   • pass the curriculum committee review,
   • be exciting enough to students that they would actually enroll in them,
   • be basic enough that students who were not seniors would be qualified for them,
   • be beneficial to the students who successfully complete them, and
   • be interesting enough to me that I would enjoy teaching them.

This is quite a large set of constraints to be mutually satisfied, and I am not sure if the resulting set is non-empty, but for now I must assume it is not, otherwise it would be very demoralizing.

The first question is also a challenge. The logical course for me to modify is the CS2 course, which we at Hunter College have labelled Software Analysis and Design 2. In this course, the students learn elementary data structures such as the various one-dimensional structures (lists, stacks, queues), simple binary trees and general trees, and some classical algorithms that are independent of these structures, such as various sorting and searching algorithms. Their knowledge of C++ is extended commensurately.

The kinds of FOSS activities that would fit fairly naturally in the course would be very low level. Students could do code reading of the source code of open source projects in the Linux environment, and could produce documentation. They could design tests and actually test. I think it will not work for them to get involved in an open source community because the overhead is too high and the learning curve too steep. The technology that they would need to learn is too extensive.

The webpage How to Contribute To Open Source is very useful. There are many other activities listed there that could be used as exercises in the class. In particular,

• Suggest new features and options
• Correct spelling and grammar mistakes in documentation
• Develop spelling and grammar style conventions for documentors
• Build a glossary of technical terms
• Convert documentation into more useful formats (i.e. DocBook)
• Create diagrams, screen-shots, and graphics for documentation
• Submit graphics (icons, backgrounds) to use in the program
• Create validation or regression test cases
• See how a program handles streams of random data
• Read relevant standards and make sure the program follows them

The harder question is the second one. I think the general idea would be to run a course in which the students learn about open source as an idea, learn about the social, economic, historical, and ethical issues that bear upon it, learn to use the technology required to participate in its development, and then work on a very tiny, possibly even local, open source project. Ed Murphy's CIS 399 course at U Penn is a good model for the kind of course I can foresee running at Hunter College, as the first of a two-course sequence in open source development. In contrast, the 4080.445.01-Humanitarian Open Source Software course that is given at RIT would not work as a first course in Hunter because of the resources required and the strong dependence on teams. Hunter is a commuter college with little social bonding and social interaction. I can see building a course similar to the one at U Penn and getting it approved in my department, and I think the devil will be in the details.

Bug Tracker Activities

This is an exploration of the Gnome Bugzilla Bug List, answerign various questions posed as part of the Bug Tracker Activity.

Bug Reports

Below are definitions of the column names used in the bug tracker of the Gnome Accessibility Package. I used various resources, such as books on software engineering, web searches, and Gnome's documentation to find the most likely meanings of the terms, because the Gnome website did not have any explicit definitions. Gnome's list of values for each field of its ticket reports do not even have a severity or priority, although the importance field uses the combination of severity and priority, so one can infer from importance the other two values.

ID

Each ticket is assigned a unique ID when it is first issued.

Severity

The severity of a bug is the extent to which it negatively affects the behavior of the software. In the Gnome Accessibility Project, the severity field can also indicate if the ticket is for an enhancement rather than a bug.

Priority

The priority is a scalar value that indicates how urgent it is to resolve the ticket.

OS

The OS is the operating system in which the software is running.

Product

The Product is the specific program or component of the package.

Status

The status is a value indicating the state of the ticket with respect to progress, such as whether it is new, or assigned to a person, or unconfirmed or resolved.

Resolution

The Resolution is what action was taken to close the ticket.

Summary

The Summary is a brief textual description of the bug or enhancement request.

Bugs in the ticket list are initially sorted by lexicographic ordering of the name of the component. I did not see shading in the bug reports themselves but the list uses some shading to distinguish types of tickets. In particular,

• Red indicates critical or higher importance
• Gray indicates enhancement
• Black indicates normal importance

Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number).
I chose Bug 758637 - Introduce more keyboard shortcuts

1. Identify when the bug was submitted.
   2015-11-25
2. Identify if there has been recent discussion about the bug?
   It is currently under discussion.
3. Is the bug current?
   It still needs work.
4. Is the bug assigned? To whom?
   It is assigned to gnome-music-maint.
5. Describe what you would need to do to fix the bug.
   The source code for gnome-music and the gnome accessibility package.

I repeated the above activity. This time, I chose
Bug 381153 - Direction text attribute is inaccurate

1. Identify when the bug was submitted.
   2006-12-01
2. Identify if there has been recent discussion about the bug?
   There has been some discussion but not since 2015-12.
3. Is the bug current?
   It still needs work.
4. Is the bug assigned? To whom?
   It is assigned to gtk-bugs.
5. Describe what you would need to do to fix the bug.
   I would need the source code as well, and to review how GTK+ control text direction.

Collective Reports

1. How many bug reports were opened in the last week? How many were closed?
   114 opened, 123 closed.
2. What was the general trend last week? Were more bugs opened than closed or vice versa?
   More closed than opened.
3. Who were the top three bug closers? Why is this important to know?
   • Michael Gratton 36
   • Tim-Philipp Müller 22
   • Bastien Nocera 14

   It is important because one can decide which people might be helpful when one is stuck.

4. 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 15
   • Guillaume Desmottes 6
   • Daniel Aleksandersen 6

   Bastien is the overlap of the two lists.

5. Who are the top three contributors of patches?
   • Georges Basile Stavracas Neto 21
   • Bastien Nocera 20
   • Michael Olbrich 17
6. Who are the top three reviewers of patches?
   • Bastien Nocera 43
   • Sebastian Dröge (slomo) 21
   • Tim-Philipp Müller 20
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?
   • Bastien Nocera
   • Tim-Philipp Müller
8. Plot a line graph of the severity of bugs by component for Orca:

1. What class were the majority of the bugs for braille?
   Normal

FOSS Activities in a CS2 (Data Structures and Algorithms) Course

Lectures

The CS2 class at Hunter College is so crammed with subject knowledge that it is not possible to include more than an hour of lectures on the subject of FOSS without removing some subject content. This cannot be done without approval of the departmental curriculum committee. Consequently, I propose to include a discussion of FOSS at the very beginning of the course, during which software engineering principles are usually covered, and then in the midpoint of the course, after the students have learned enough material that simple FOSS-related projects would be feasible.

The lectures would be based on material from specific websites such as:

• http://teachingopensource.org/index.php/How_to_start_contributing_to_or_using_Open_Source_Software
• https://www.gnu.org/philosophy/free-sw.html
• https://opensource.org/faq
• https://icontribute.wordpress.com/how-to-contribute-to-open-source-without-coding/
• http://blog.smartbear.com/programming/14-ways-to-contribute-to-open-source-without-being-a-programming-genius-or-a-rock-star/

In-class activity

There cannot be any in-class activities because of time constraints. This class is not structured with recitation sections or labs; it is a lecture-only format.

Homework

Homework that could be added to the current set of programming projects assigned in this class could be FOSS-related.

1. One simple assignment would be to have them read excerpts from "The Cathedral and the Bazaar" much as we had to do for our homework. The learning outcome would be to understand that there are competing models of software development and that there are benefits to the FOSS model. Another outcome is being able to explain to someone else what FOSS is, and what the drawbacks of the alternative are. This assignment requires no prerequisite knowledge nor being part of a community. It could be graded by having students answer a few questions in a ten to fifteen minute in-class quiz. A stumbling block is that FOSS is not listed in the curriculum for the class and a student might complain if his or her grade were based on material not listed in the guidelines. The argument would have to be that FOSS is a part of modern software engineering practice and is therefore implicitly included.
2. Other short assignments would be to have the students read code fragments that contain no documentation and have them document them. The code would be chosen so that it, and any links to which it referred, contained only algorithms and data structures that they were taught. The learning objective is to be able to read and explain code written by others and to be able to write clear and complete documentation of such code. This assignment requires no prerequisite knowledge nor being part of a community. It would be graded qualitatively based on the accuracy and completeness of the documentation.

Stream of related activities

In this class there would be no other activities.

Projects

Usually there are three or four programming projects in this class. The only hope of including a major FOSS project is to modify or augment one of these.

1. One possibility would be to design a project that could be used to turn the class into a small community. The idea would be that students would write their own code, but that other students would test it anonymously using black box techniques. Students would document the testing and create tickets when they discovered errors. The details would need to be worked out. The learning objectives would be to be able to work as a community, to be able to test and debug others' code, and to be able to write tickets. This assignment requires no knowledge nor being part of an outside community. Grading will be carried out the usual way, with a certain percentage of points allocated to the testing, debugging, and ticket-writing components.