User:Mallen

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
(FOSS in Courses Planning 2)
m
 
Line 197: Line 197:
 
Each students would be assessed separately although they would be able to work together on many aspects of the project. In the past I have found that FOSS community members are often uncomfortable suggesting a grade. I would welcome input from the HFOSS community but would not require it. I would not require that the contribution be committed to the project since that is out of the students' control but I would hope that their contribution would be useful and accepted.
 
Each students would be assessed separately although they would be able to work together on many aspects of the project. In the past I have found that FOSS community members are often uncomfortable suggesting a grade. I would welcome input from the HFOSS community but would not require it. I would not require that the contribution be committed to the project since that is out of the students' control but I would hope that their contribution would be useful and accepted.
  
5% Week 2 bug fix
+
: 5% Week 2 bug fix
 
+
: 15% project plan
15% project plan
+
: 10% code reviews (feedback given to the other student)
 
+
: 40% contributions
10% code reviews (feedback given to the other student)
+
: 15% blog or oral presentation
 
+
: 15% learning reflection paper
40% contributions
+
 
+
15% blog or oral presentation
+
 
+
15% learning reflection paper
+
  
 
'''questions'''
 
'''questions'''
Line 214: Line 209:
 
'''stumbling blocks'''
 
'''stumbling blocks'''
 
It may be difficult to choose pieces of the project that are appropriately sized for this course. It may be difficult for the students to get input from community members when they need it as the community members may have other priorities at that time.
 
It may be difficult to choose pieces of the project that are appropriately sized for this course. It may be difficult for the students to get input from community members when they need it as the community members may have other priorities at that time.
 +
 +
 +
[[Category:POSSE 2014-11]]

Latest revision as of 09:26, 7 February 2017

Meghan Allen

Meghan Allen is an Instructor in Computer Science at the University of British Columbia (UBC) and Vantage College at UBC. The department of Computer Science has 55 faculty members, approximately 1300 undergraduate computer science majors and 200 graduate students. Vantage College has welcomed its first class of 187 students in August, 2014.

Meghan has been teaching in Computer Science at UBC since 2007 and has focused on teaching CS1, CS2 and an Introduction to Software Engineering course. She is currently focusing on creating curriculum and teaching for Vantage College, which offers an innovative, first-year program for international students.

Contents

Intro to IRC

How do people interact? The interactions seem fairly casual, but it seems like there is a chair of the meeting that keeps the conversation on track. The chair uses some meetbot commands to take minutes. The team members give updates and help each othr when they can.

What is the pattern of communication? It seems like one person at a time talks about what they've been working on and others jump in if they have questions or something to add.

Are there any terms that seem to have special meaning? The meetbot commands, and it seems that you can mention a member of the conversation (e.g. to ask them a question)

Anatomy of a FOSS Project

Sugar Project Activity team: develops and maintains activities for Sugar as well as interacting with community contributors. Works with Development and Infrastructure teams to ensure developers have what they need. Documents activities Development team: designs and implements core Sugar environment. Works closely with the Design and Testing teams Documentation team: creates documentation for users and developers

Some commonality between the teams is that the Activity and Documentation teams both work on documentation although at a different scale. Also, the Development and Activity teams both do development, but they develop different things.

Issues: types/categories: defects or enhancements For each ticket, the following information is included - reporter, priority, relevant component, severity, list of other interested team members, status, owner, milestone fix is planned for, keywords, distribution or OS that the issue occurs in and a description. Each ticket also includes attachments, a reference to related change sets, comments and a history of changes

I think Sugar uses a web-based common Git repo

The Development Team's Roadmap is updated at the beginning of each release cycle by the release team.

Sahana Eden Project Developers: Once developers get set up, they can choose what size and kind of project to work on Testers: The project lists many ways for people to get involved with Testing. Testers can choose to manually test, write test cases or work on the CI server. Designers: Designers are graphic designers who wish to contribute to the project. The project prefers HTML/CSS contributions but accepts others.

This is different than what I found for the Sugar project because the developers are not broken into teams. There are also tasks listed for potential contributors with a range of skills (manual tests, graphic designers, CI server specialists, etc.) so it seems like it would be easier for someone to figure out how they could contribute to Sahana than it would be to figure out how to contribute to Sugar.

The Sahana tickets are grouped into specific queries - to see all the open tickets I have to click on Active tickets. types of tickets: defect/bug, documentation, task, enhancement each ticket includes reporter, priority, relevant component, keywords, due date, description, owner, milestone and version, list of other interested community members, comments, change history

I think Sahana uses a local repo

Sahana's roadmap page includes current and past milestones, including the details of what has changed for each milestone

FOSS Field Trip Activity

Source Forge

I searched for Kids Games and there were 30250 projects that use 15 different programming languages. The top four programming languages are C++, Java, C, and C#.

   Inactive - not currently being worked on
   Mature - not sure - complete project with good documentation?
   Production/Stable - production release available for download
   Beta - beta release available for download
   Alpha - alpha release available for download
   Pre-Alpha - version of project is so young that it's not even ready for an alpha release yet
   Planning - still in planning stages, not yet anything ready to download and use

Compare two projects in this category that have two different statuses. Describe the differences between the statuses.

Computational Intelligence in Games is Mature. It has 24 downloads this week and was last updated in July, 2013. Games Museum is Inactive. It has no downloads this week but was also last updated in July, 2013.

Which projects are the most used? How do you know? I think the Most Popular projects are the most used as they have the highest number of downloads.

Pick a project in your category.

I picked Tux Paint

   What does it do?
      It's a drawing program for kids aged 3-12.
   What programming language is the project written in?
      It's written in C.
   Who is likely to use the project? How do you know this?
      From the description, I think parents of young kids or older kids would download and set it up.
   When was the most recent change made to the project?
      The most recent work was to package up a new release (for different OS's)
   How active is the project? How can you tell?
      It's pretty active. The mailing list archive shows discussions as recent as August.
   How many committers does the project have?
      64
   Would you use the project? Why or why not? 
      Maybe! I have three-year-old boys that might enjoy it.

MIFOS

Is mostly written in Java and has 2, 673, 467 lines of code.

List some of the locations of the developers. (The map won't show up for me in Firefox or IE for longer than about .5 seconds. I can tell that there are contributors all over the world but can't see exactly where)

Mifos is written in 19 languages and the second most used language is XML. Perl has the highest comment ratio.

The average number of contributors in the last 12 months is about 1.

The top three contributors have been involved in the project for 1 year, 3 years and 4 years, respectively.

The average number of commits per month is 5.5 over the last year.

FOSS in my courses

I have a number of ideas about how I might use FOSS in my courses.

CS2 Our CS2 starts with students reading code and using models to help understand the code. They extract control-flow diagrams, call graphs and UML class diagrams from existing code. We have searched for FOSS projects for the students to work with and often can't find appropriate projects. I'm interested in finding projects written in Java that are fairly small to use in the beginning of CS2.

Our students do about 5 assignments and a longer (5-6 week) project in CS2. I like some of the ideas at the bottom of http://www.xcitegroup.org/softhum/doku.php?id=f:50ways for our assignments. Specifically, I think our students would learn a lot from these assignments

   - Find/study examples of well & poorly written code
   - Look at coding standard for an open source project (Java, Python)
   - Reformat code, rename variables, etc. (possibly commit back depending on project)
   - Test (perhaps a project that does JUnit testing).
   - Trace the execution of some piece of code.
   - Develop UML diagram from an existing project. 
   - Identify data structures used in a project.

CS2 is team taught at my university so I can't make decisions about its curriculum without consulting my colleagues. One of my colleagues will likely be spending a significant amount of time revising the CS2 curriculum between Sept 2015 - Aug 2016. After I attend the workshop in November I intend to talk to him and my other colleagues to see if we can integrate HFOSS into the curriculum.


Third-year project course We have a third-year project course that is always looking for clients who have projects the students can work on. There may be an opportunity to integrate an HFOSS project into this course if there was someone from the project who was willing to act as the contact or if I was able to learn enough about a specific project to act as a client.

Directed studies course Our university offers directed studies courses, in which a student (or students) and a faculty member submit a proposal to work on a project together for one or two semesters. The students get course credit for their work. I think this may be the easiest way to get a few students involved in HFOSS work.

Bug Tracker Activity

   ID - ID
   Sev - severity (options: blocker, critical, major, normal, minor, trivial, enhancement)
   Pri - priority (options: immediate, urgent, high, normal, low)
   OS - operating system (options: AIX, BSDI, Cygwin, GNU Hurd, HP-UX, IRIX, Linux, FreeBSD, NetBSD, OpenBSD, opensolaris, OSF/1, Solaris, BeOS, Mac OS, Neutrino, OS/2, Windows, OpenVMS, other)
   Product - any of the GNOME modules
   Status - options: unconfirmed, new, assigned, reopened, needinfo, resolved, verified
   Resolution - options: fixed, wontfix, duplicate, notabug, notgnome, incomplete, invalid
   Summary - a short description of the bug

I found these definitions and options on the Advanced Search page. The bugs seem to be initially displayed in order of status. Unconfirmed first, then new, then assigned. I can't figure out what the shading means. Red is for important bugs, based on their priority. Black is for normal bugs. Grey is for enhancements.

Bug 437375 The bug was submitted on May 10, 2007. There has been no activity since June 23, 2011. The bug is likely not current as it refers to version 1.0 and it seems like they are working on at least version 3 now. The bug is assigned to ATK Maintainer(s). To fix this bug, I would need to look at the documentation for this method and figure out whether it needs to be updated.

Bug 601370 This bug was submitted on Nov 10, 2009. There was a comment on the bug on June 15, 2014. It does seem to be current based on the most recent comment. The bug is assigned to Baobob Maintainers. This bug already appears to be fixed as there is a patch attached, although it doesn't seem like the patch has been applied.

Reports 306 bugs were opened and 388 closed in the last week. More bugs were closed than opened this week. The top three bug-closers were Jean-Francois Fortin Tam, Bastien Nocera and Matthias Clasen. It's important to know who the top bug closers are because it's a good indicator of who's most active in the community. It's also nice to recognize the hard work of the community members who have been particularly active. The top three bug reporters were Michael Catanzaro, Jean-Francoid Fortin Tam and Jo. There are two people on both lists. This makes sense as all committers are likely users but not all users are committers. The top three patch contributers are Ray Strode, Bastien Nocera and Marcos Chavarria Teijeiro. There is a little bit of overlap between the patch contributors, patch reviewers and bug closers list. It looks like I can generate a report for almost anything! I just need to set the x/y axes and the search criteria.

FOSS in Courses Planning 2

Since I did the Stage 1B activity on FOSS in my courses, I've been approached by two students who are interested in working on a directed studies next semester. We will meet before I come to the workshop so I'll have a better idea if their goals and my goals for the course align, but for now I'm going to focus on planning a semester-long, capstone, directed studies experience for these two students. They would get course credit for a 4th year computer science course and would spend approximately 8-10 hours per week for 13 weeks on the course. We would pick a project together before the beginning of the semester.

prerequisite knowledge Students must have taken our mandatory 3rd year software engineering course so that they are familiar with issue trackers, version control and working on a software project in a team.

timing This course must line up with our university calendar so we will have to find a project that can accept contributions in our time frame. I anticipate about 10-20 hours each (instructor and students) of prep time before the semester to agree on a project, course goals, schedule, etc. During the semester, the students would spend 8-10 hours per week on the course. I would meet with them once a week for 30-60 minutes to discuss progress and help where I can.

input from the HFOSS community The community members would be consulted when the students were working on the project plan to ensure that their plan fits with the goals of the project. This would increase the probability that the students' contributions would actually be committed to the project. I anticipate that the students would occasionally ask questions on the developer mailing list and/or the IRC channel and would need some support from the community in the form of answering those questions.

contribution to HFOSS community Since this is a semester-long class, I would expect that the students would contribute something useful to the project that would be accepted. Since it's a 4th year computer science class, I expect that the contribution would be a technical contribution (e.g. code patches, tests, design).


course level learning goals

By the end of the course, students will be able to

effectively communicate with HFOSS project members using appropriate tools (e.g. user and developer mailing lists, IRC channels)

write a project plan for their contributions to an HFOSS project

contribute high-quality patches to the HFOSS project that meet the project's standards for design, testing and style

effectively communicate their progress via a blog or end-of-term oral presentation

course schedule

Week 1 - communication (something similar to http://www.xcitegroup.org/softhum/lib/exe/fetch.php?media=homework_2_-_communication.pdf) and getting the development environment ready

Week 2 - getting started: work on a bug or enhancement, start exploring the issue tracker for potential longer-term work

Week 3 - work on a project plan for the rest of the semester

Week 4 - submit project plan including milestones

Weeks 5-12, work on contributions detailed in the project plan. students code review each other's work prior to contributing patches

Week 13, patches due, learning reflection paper due (similar to http://www.xcitegroup.org/softhum/lib/exe/fetch.php?media=learning_reflection_paper.pdf), blog or oral presentation due

grading Each students would be assessed separately although they would be able to work together on many aspects of the project. In the past I have found that FOSS community members are often uncomfortable suggesting a grade. I would welcome input from the HFOSS community but would not require it. I would not require that the contribution be committed to the project since that is out of the students' control but I would hope that their contribution would be useful and accepted.

5% Week 2 bug fix
15% project plan
10% code reviews (feedback given to the other student)
40% contributions
15% blog or oral presentation
15% learning reflection paper

questions I am very interested in talking to Heidi and any others who have run semester-long courses to hear their suggestions. I don't have any specific questions at the moment though.

stumbling blocks It may be difficult to choose pieces of the project that are appropriately sized for this course. It may be difficult for the students to get input from community members when they need it as the community members may have other priorities at that time.

Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox