Dee A. B. Weikle is 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.
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 #)
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.