User:SWeiss

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.

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 [1] 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 similar to the course given at RIT with syllabus [2].