View source

You do not have permission to edit this page, for the following reason:

You can view and copy the source of this page:

'''Dee Weikle''' Dee A. B. Weikle is an Associate Professor of Computer Science in the Mathematical Sciences Department at [http://www.emu.edu 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 [http://hotyogacville.com/ Bikram yoga]. ---- == 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 [http://wiki.sugarlabs.org/go/Category:Team 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 [http://eden.sahanafoundation.org/wiki 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

Return to User:Dee.weikle.