User:Dee.weikle

Latest revision as of 01:52, 7 February 2017

Dee Weikle

Dee A. B. Weikle is now an Associate Professor in the Computer Science Department of James Madison University. Until fall of 2016 she was an Associate Professor of Computer Science in the Mathematical Sciences Department at Eastern Mennonite University (EMU). Dr. Weikle graduated from Rice University with a BS in Electrical Engineering and worked for 8 years as an engineer, first at Tracor Aerospace and then at Motorola Semiconductor, both in Austin Texas. After that she lived a year in Gothenburg Sweden then moved to Charlottesville, VA where she finished a PhD in Computer Science under Dr. William Wulf at the University of Virginia.

Dr. Weikle teaches a variety of classes including Computer Architecture and Operating Systems, Algorithms, Data Structures, Java, Computers and Society, and the occasional Topics or math class. Dr. Weikle is also the Deputy Editor of the SIGCAS Newsletter and her research interests include computer architecture, modeling computer architectures and the mathematics behind that modeling, computer science education and the societal impact of computers and technology.

Dr. Weikle has little free time, as is the case for many professors, but spends a majority of it with her family, including three children; hiking, cooking, crocheting and reading. Her favorite form of exercise is Bikram yoga.

Skills

Teaching: CS0, CS1, Introductory Programming: Python, Intermediate Programming: Java, Data Structures, Algorithms, Computers and Society, Computer Architecture and Operating Systems, other special topics Interest in developing pedagogical tools, hands-on activities in above coursework

POSSE 2015-09

Stage 1 Activities - Part A

Introduction to IRC (4)

How do people interact?

People interact in short, partial sentences about specific topics. Communication is intended for the entire group and primarily focused by a leader (the chair) who also takes brief notes using the commands to the meetbot for notes. It appears these commands will end up creating a summary for later review. This allows conversations to include comments that might not be important initially, but end up with an important insight or result.

What is the pattern of communication?

The pattern of communication is to stay on topic, and as mentioned above communicate in short phrases, making use of acronyms or abbreviations that are known to others in the group. No concern about typos or "being interrupted". Everyone just keeps following threads and brings them back together if needed.

Are there any terms that seem to have special meaning?

Yes, there are commands to the meetbot that seem to have special meaning. It is also possible to be specific about who you are directing a question or comment to by starting with their name. This feels a bit like a command or protocol.The sessions started out with what appears to be the meetbot listing some potentially useful commands: #action #agreed #help #info #idea #link #topic

Can you make any other observations?

I noted that the meeting seemed fairly short (around 30 minutes). People seemed to pop in and out although it was real time. Participants also seemed to be able to participate and run something else in the background to try different ideas as they were thrown out - enabling results to be given to the group during the meeting.

Anatomy of a FOSS project (6)

Summaries of team info from the Sugarlabs Team Page July 30, 2015

Activity Team - The activity team supports the maintenance of current activities (their concept of applications) and the creation of new activities. As such they maintain the "ecosystem" for activities, which is similar to the operating system in the PC world. Their responsibilities also include recruiting activity developers, working with the development team to support developers, and the deployment team to get feedback. Unique aspects of this team seem to be that they explicitly work with at least 3 other teams and the formality of their page including the explicit list of their responsibilities.

Development Team - The development team builds and maintains the "ecosystem" that is the foundation for activities (much like an operating system). They actually implement changes to the system and work with the design team to envision new versions. A unique aspect seems to be the election of a "team lead".

Documentation Team - The documentation team creates and updates all the manuals for the different activities and underlying API of the environment. Unique aspects of their wiki seems to be the discussion on the top page as well as an explicit list of contributors, also had an in-person meeting.

All teams have a basic explanation of their role, links and an open invitation to immediately get started working, some kind of schedule, some kind of communication mechanism (two mention IRC).

Sugarlabs Bug Tracker

Types/categories of tickets: Tickets are primarily either defects or enhancements, saw one "new" task

Information available for each ticket: Ticket #, Summary, Status (can be assigned, reopened, accepted, or new), Owner (userid), Type (defect, enhancement, new), Priority (High, Normal, Low, Unassigned), and Milestone (often unspecified, but sometimes version/release #)

Sugarlabs Repository

I am a bit unsure, but I think Sugarlabs uses a web-based repository because the Activities list includes pushes to what looks like a link...

SugarLabs Release Cycle

The release cycle and roadmap are related in that the roadmap is basically a plan for what will be included (goals) for upcoming releases where the release cycle is the actual numbering and process for new releases to users.

Summaries of group info from the Sahana Eden Page July 30, 2015

Developers - The developer's group actually develops new code and asks you to look at current code as well as participate in initial training. Training is available virtually, either in slide presentation/recording or live sessions. They expect you to sign a contributor's agreement from the beginning.

Testers - Primary focus seems to be on generating test cases which they encourage even non-technical users to do. They also encourage developer's to see if their new code has broken something. Very simple top page. Less training (if any) and less information on wiki.

Designers - Designers are making the appearance of websites and code repositories more appealing and easier to use. Some technical capabilities useful in that ideal designers incorporate their designs through the use of css and html, but it appears just suggestions are useful too.

The structure for Sahana seems more flat, general, and simpler than that for Sugarlabs. There are fewer teams or groups at least. Developers in both groups seem to be the more technical and more formal.

Sahana Eden Bug Tracker

The information here is different that the information on the Sugarlabs Tracker in that they are categorized and linked to in different ways... by owner, milestone, version etc. It is also clear that it is an international project simply from the bugs. There is an effort here to make sure bugs are unique, an interface for those trying to solve bugs - i.e. bugs listed by logged in userid, and different reports are available for categories of bugs.

The types/categories of tickets are similar to the Sugarlabs types/categories in that they are primarily defect (bug) or enhancement, but I also saw a task and a documentation type here.

The information available for each ticket is also similar to Sugarlabs: Ticket number, summary, component, version, priority, type, owner, and status.

Sahana Eden Repository

I think that the Sahana Eden repository is also web-based common repository. It seems like they both use github, but Sugarlabs is moving to a local site. I have to admit I am not completely sure what the difference is between a web-based common repository and a local repository. I have done a bit of research googling and using wikipedia, but still don't feel like I have a complete picture.

Sahana Eden's Release Cycle and Roadmap

For Sahana Eden the release cycle and the roadmap seem to be the same thing. The information here has names for different releases "groups" along with features that each should contain, how far behind schedule it is, and a list of languages that are being supported for the release grouping. Again struck here by the international flavor of Sahana Eden.

Stage 1 Activities - Part B

FOSS in Courses

Identify activities or topics that you are interested in within your HFOSS project of interest

I had identified the Mousetrap project as one that interested me. This is in part because I am a computer architect, and I am interested in the possible addition of some hardware platform for projects. We are starting a new engineering program at EMU and it would be helpful if I could identify projects that would work for both computer science and computer engineering. The computer vision aspect of Mousetrap has the potential to be synergistic with some of my colleagues' interest in robotics. Plus it just sounded cool. After more time learning about evaluating HFOSS projects, I wonder if it has enough activity, but perhaps this is primarily a summer issue and since others have used it successfully, I am going to stick with it.

Topics I am interested in within the Mousetrap project would likely be fixing some bugs and/or user interface issues. In some ways, Mousetrap is not a good fit for me because I teach the Java programming class and other faculty are primarily responsible for the Python class we have had. Also, I am not the Software Engineering faculty member so using it to learn software process only or primarily is not a great fit for my classes either. I do think it could work very well for independent projects. Many of the advanced students I have skip the introductory programming class that is in Python as we try to keep that to just inexperienced students. As a result some of them want a way to receive credit for learning Python. I have been connecting them with other professors in the sciences or physics who need some Python code written for something they need in their labs or for running demos in their courses. I then set up some online activities for them to do the first couple of weeks to learn Python syntax, after which they simply work with the professor to write and maintain a piece of software for their professor. Mousetrap could be a project that I offer to work with students on as a Python independent study. Also, seeing how open source works, I might encourage some faculty to begin open source projects for the code they want written. (This I might wait on until I am more experienced.) The thing I noticed recently on the Mousetrap pages that interested me most though was the detailed information on a link to the Gnome pages for how to run a hackfest. I have been interested in doing this for students in my program and this seemed like it could be a perfect way to get started on this type of venture.

Now that you have an idea of the possible types of activities or topics, identify one or two that you think would fit in your class.

Like I said above, I think a series of Mousetrap bug fixes or UI improvements would be a perfect way to implement my own Python independent study class. Other ideas are for my CS110 Introduction to Computer Science class where we study the software life cycle, a simple way to make this more hands-on would be to give them a project with really strong documentation like OpenMRS and have them identify all of the components of the software life cycle in the project itself. Also in this class we talk about copyright and other kinds of legal protection of intellectual property. Introducing the idea of open source software and noticing the different licensing agreements would also make this discussion more real. OpenMRS might also be a better fit for my Intermediate Programming: Java class because most of the source code is in Java. I could have an option to the final project in that class be to fix a bug or set of bugs in OpenMRS. I think the biggest difficulty there is that they haven't had much experience with revision management systems yet, although I am adding some to this course. I also think that I could identify an open-source project like OpenMRS that uses Java as its source language and as I bring up testing, documentation, code style, and revision management concepts in class at least use it as a real-world example throughout. In this way perhaps the final project wouldn't be so intimidating.

In your reading, did you find existing materials? If so, describe how would you modify them to fit your class?

I did find some materials that would be helpful. In particular I found some materials on revision management systems and a clever video on copyright in the words of Disney characters. Several of the links were broken and I didn't get too far into the materials, but it seems like there is a great deal there. I will certainly return to these as I am working to implement a course on open source software.

If you did not find existing materials, summarize the activity in a sentence or two

See above.

Stage 1 Activities - Part C

BugTrackers

Bug Reports

1. ID – unique identification number for the bug or issue report

2. Sev – Severity perhaps?

From: http://www.elementool.com/contact/articles/Bug_Tracking_severity_priority.html

Severity: A severity classification of a software error is based on the degree of the error impact on the operation of the system.

The severity classification is as follows: Critical – The bug causes a failure of the complete software system, subsystem or a program within the system.

High - The bug does not cause a failure, but causes the system to produce incorrect, incomplete, inconsistent results or impairs the system usability.

Medium – The bug does not cause a failure, does not impair usability, and does not interfere in the fluent work of the system and programs.

Low – The bug is an aesthetic, is an enhancement or is a result of non-conformance to a standard.

3. Pri Priority maybe … Priority: A priority classification of a software error is based on the importance and urgency of resolving the error. The priority classification is as follows:

Immediate – The bug should be resolved immediately.

High - This bug should be resolved as soon as possible in the normal course of development activity, before the software is released.

Medium – This bug should be repaired after serious bugs have been fixed.

Low – It can be resolved in a future major system revision or not be resolved at all.

4. OS – Operating System? – any operating system such as Windows 8 etc.

5. Product – possible products… as in each code repository may be included in multiple end products to defining which end product the bug manifests itself in…Possible values includes any product the code base is used in – in this example there were over 10 products

6. Status – what status is the bug or issue in…. example values NEW, UNCONFIRMED, REOPENED, RESOLVED, ASSIGNED, etc.

7. Resolution – Description of how the bug or issue was resolved. Some possible values are fixed, wontfix, duplicate, notabug/invalid

8. Summary – basic description of what the bug is, entered by user or other developer, can basically be anything…

Basically found out what they were by Googling and looking around site at what they contained… guessing.

Bugs seem to be initially displayed in their submission order which loosely corresponds to their id number…

Shading is only for readability of the overall lines it seems like at first…

Can’t find the meaning of the colors…

1. Select a bug that you think that you might be able to fix and look at it more closely (click on the bug number). 1. Identify when the bug was submitted. 2012-01-02 16:31 UTC by Benjamin Kris 2. Identify if there has been recent discussion about the bug? No, all discussion in 2012 3. Is the bug current? Doesn’t seem to be… 4. Is the bug assigned? To whom? Bug is assigned to tracker-search-tool so doesn’t seem to be assigned to an actual person yet 5. Describe what you would need to do to fix the bug. First figure out if it is really a bug or needs to be fixed because it is pretty old. Second find the area of the code that uses the feature or displays the feature in order to see what needs to be done. 2. Another bug…Deleted notes should go into trash 2006-12-03 21:11 UTC by Steve Frécinaux Submitted Recent discussion…. Modified in 2012, so not really…., bug assigned to Tomboy Maintainers, looks like changed to feature…

Collective Reports

2. How many bug reports were opened in the last week? 17 How many were closed? 30

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

4. Who were the top three bug closers? Matthias Clasen, Joanmarie Diggs, Michael Natterer. Why is this important to know? Because they can help determine if bugs are really bugs (can be your buddie in reporting problems)

5. Who were the top three bug reporters? Christian Stadelmann, Lapo Calamandrei, m.rick.mac Are these the same as the top three bug closes? Not it doesn’t seem to be.What is the overlap in these two lists? No overlap in top 3 - overlap in whole list though several.

6. Who are the top three contributors of patches? Debarshi Ray, Jonas Adahl, Sebastian Droge

HFOSS Project Ideas

CS110 – Software Lifecycle demo in MRS

Lecture – I try not to do traditional lectures very much, but a short introductory lecture usually helps to get students a good frame to begin an in-class activity. It seems that students don’t read effectively often, so just counting on them to read is not ideal. The mini-lecture could be about the software lifecycle, then talk about open source projects in general and have them bring up OpenMRS. I could navigate the site in a few key places, then let them do an in class activity on their own.

In-Class Activity – For CS110 I think it would be wise to have the phases described on a worksheet and then help them navigate to those parts of the project and make comments on each, similar to what we have been doing in POSSE. My concern is that the OpenMRS site is fairly complicated. It may not be easy to navigate and I am not quite sure what I want them to observe.

Possible Learning Outcomes:

- Understand the software lifecycle including design ideas/fix request, documentation (maintenance and user), testing, bug identification, etc.

- See and be able to discover different parts of the software lifecycle in a real world project

- Become familiar with the accessibility of open source software

- Understand the need for revision management software and be able to describe that need

- Be able to give examples of programs used for revision management software

Prerequisite Knowledge: None

Instructor Preparation: Initially 4 hours? 1 for visually appealing mini-lecture or video, 2 to peruse site and find examples of software life cycle along with possible observation questions, 1 to prepare in-class activity worksheet.

Input from Community Needed: No

No Contribution Back at this point This would either be an individual or paired activity. Graded on completion. No feedback needed. Concerns or barriers – is this worth the time it would take up in class. I normally don’t spend much of this class talking about the software lifecycle. Is this too much time for the topic? I do like the idea of CS110 students seeing how accessible a project is and that they can contribute in non-technical ways as well.

Teaching GitHub in Intermediate Java

I have already tried to do this some primarily from in-class activities with a peer tutor and a modification of a tutorial from GitHub. There has been some success, but to take it to the next level I really need to sit down and practice with GitHub myself so that I can figure out what tools fit the class. Some of the GitHub videos might be useful. I really don’t like learning this way, but my students seem to like it. I prefer reading where I can see where I am going and go faster or slower depending on what I need. Indexing into a video to remind myself of a command etc. is not ideal.

Throughout the semester enable students to use GitHub with themselves.

Mini-lecture on theory of revision control systems – emphasis on vocabulary and what it means.

In-class activity to walk students through the modification of a simple program including a small addition of a method for a previously defined class. In this activity make sure they get GitHub downloaded and are able to use it successfully at least once.

Throughout the rest of the semester have students pull lab specifications down, and perform pull requests to get them up. Come up with method of automatically testing code from GitHub.

Possible Learning Outcomes - Become familiar with the theory behind revision control systems and be able to use one. - Understand and be able to use the vocabulary of revision control accurately, examples: fork, push, pull, commit, merge. - Have real experience using a revision control system to update and maintain a personal code base for labs

Pre-requisite knowledge: None

Instructor prep time: ? This is a big concern for me because I still am not confident with how to make things work and the big picture here. I could really benefit from discussing how to run a class through GitHub. I find that the tutorials etc. are nice, but don’t really give me the “middle” picture ideas of how to organize a class and use GitHub.

Input from Community: If I don’t have students build a project in the community, then none is needed. If I were to offer the option of a final project in something like OpenMRS, it would need to coincide with their cycle…I could allow them to simply work on bug fixes that I selected, but for that I believe I would need significantly more experience with a particular open source project.

Grading Approach: Probably an A would be if bug fix was completely accepted by the community, as long as it was difficult enough. Issue will be determining other grade levels.

Stumbling Blocks: Just simply finding/making the time to really learn GitHub or other tools. Making time to work in the community myself.

Project to contribute code/other to actual open source project

I haven’t figured out the best way for me to do this yet. I may choose to run it as an ACM club project at first to get my feet wet. That allows me not to be worried about grading etc. until I see how I want that to go. I would like to see some examples of grading – what to look for etc.

My three ideas for this though are:

- Independent study Python course for senior CS students on open source project using Python

- Project with women in technology group

- Student ACM optional project

- Data Structures class help with Virginia Tech ebook on Visualizations…