Latest revision as of 15:25, 19 June 2019

Dave Lillethun

Affiliation: Computer Science Dept., Seattle University

Email: lillethd AT seattleu

Website: http://dave.lillethun.org

GitHub: https://github.com/DaveLillethun

HFOSS Course Design

Learning Outcomes

Students will...

• Apply knowledge of software development processes and FOSS culture to engage with a FOSS project community
  • Communication tools (IRC, Wiki, etc.)
• Apply knowledge of software development tools, such as development environments, source control, issue tracking to...?
  • Source Control (e.g., git / GitHub / GitLab)
  • Issue Tracking
• Understand a large, existing code base and its related technologies in order to start contributing to it
• Appreciate the non-development (non-code) elements of a complete software product/project
  • Documentation (creating & maintaining)
  • Assets (art & design)
  • Translations
• Understand legal and copyright issues in software, including copyright and licensing
• Reflect on the ethical / humanitarian / social justice opportunities for software

Activities

Since I'm thinking about creating a course, not just inserting activities into an existing course, it's a little hard to think of specific activities without first knowing the overall structure of the course and what the ending point for the students at the end of the term should be... so I think maybe I need to think about that course structure first.

• Bug Gardening
  • Intro to Bug Trackers (Activity)
  • Bug Gardening
• Make your first contribution
  • Test Installation Instructions
  • Document Code with Meaningful Comments (Activity)
  • Bug Gardening
• Code Base Understanding
• Fix a bug / make an enhancement / write a test (on a snapshot?)
  • Bug Selection
• Humanitarianism / Social Justice Reflection
• Intellectual Property / Licensing / Legal Paper

Make your first contribution!

Make your first contribution to an HFOSS project. This is a little open-ended, but should _not_ be a contribution to the code. Possible contributions include:

• Documentation (expand, enhance, update, etc.)
• Manage issues (tickets) in the Issue Tracker
• Add meaningful comments to code
• Updates to wiki
• Test, find a bug and create an issue ticket
• Research a bug and add meaningful new/updated information
• What else is possible?

Preparation:

• Read at home about different kinds of contributions that you can make to open source projects
• Class time to get set up and have the tools (and accounts) needed to begin contributing
  • Also discuss your contribution ideas with the instructor at this time

Activity:

• Work on creating your contribution at home, and submit it to the project

Deliverables:

• Turn in the thing you contributed (or a pointer to it)
• Write a short paragraph explaining what you chose to contribute, how it contributes to the project as a whole, and what other kinds of contribution you feel you would be able to make in the future

Outcomes:

• Student understands the different ways to contribute to an open source project
• Student understands the important elements of an open source project, besides the code
• Student gains the ability to set up the tools needed to begin working with an open source project
• Student gains confidence to make contributions to real projects

Questions:

• Are the communication aspects of an open source project an important element of this activity too? Or not? Or are they something that should be addressed in a prior activity?
• How should this best be evaluated? (Should there be a summative evaluation, or is it more of a lab activity?)

POSSE Activities

Intro to IRC activity

• How do people interact?
  • It seems to flow similar to an Agile / SCRUM type of meeting. Someone has the spotlight and talks about what they're working on - they do most of the talking, and others chime in now and then to offer suggestions, ask questions, etc. Then the spotlight moves to a different person to talk about a topic, and so on. Meanwhile, darci uses the bot to take meeting notes (which the bot will format nicely for them, as we find out in the next stage of the IRC activity)

• What is the pattern of communication? Is it linear or branched? Formal or informal? One-to-many, one-to-one or a mix?
  • There is some branching, but without going too far off topic too long - like Charlie Brown's Christmas Tree, not Yggdrasil. The language is pretty informal, and much of it is one-to-many (with a few many-to-one replies) but some of the branches seem to occasionally go one-to-one just for brief moments.

• Are there any terms that seem to have special meaning?
  • Starting a message with "Name:" seems to be a common way to address a message to a specific person, and there were one or two uses of /me . Of course, there are the # commands. Also, there are naturally a lot of technical terms being used.

• Can you make any other observations?
  • A lot of this feels pretty comfortable if you're used to online chat.  :)

• Bonus question: Why didn't Heidi and Darci's actions get picked up by the meetbot?
  • Looks like user names are case-sensitive, and heidi and darci's names start with lowercase letters, but the actions had their names spelled with capitals.

Project Evaluation activity

OpenMRS

https://github.com/openmrs/openmrs-core

Intro to Bug Trackers activity

Current GNOME issues:

• gnome-builder
• evolution
• gnome-control-center
• librsvg

Other information on the list view:

• issue title
• time and user opened
• time last updated
• comments and upvotes

Example labels:

• 1. Enhancement
• refactoring
• 6. Component: Sound
• 6. Component: Background

Issue details:

https://gitlab.gnome.org/GNOME/evolution/issues/489

• Evolution version tested against
• Description of the problem (this issues is very good! it has clear reproduction steps)
• Asignee: None (this was a fairly new bug at the time of reading)
• Milestone: None
• Time tracking: No estimate or time spent
• Due date: None
• List of participants (Is a participant just anyone who's editing the issue ticket?)

Labels:

• 1 is for real issues to be addressed (incl. both bugs and feature requests and more)
• 2 is for things that need more investigation or discussion
• 3 is for things that will not be fixed/addresses (as a deliberate decision, for some specified reason)

Boards: It looks like boards group bugs by their current status. Right now, it's only showing "open" and "closed"... I wonder if there are more boards that could show up here?

Milestones: No milestones are currently being shown, but it looks like they let you assign issues to your project milestones so you can keep track of your progress towards completing the milestone. (I wonder if projects use burndown charts or anything like that?)

Merge requests: These look like fixes to issues that were implemented in different branches and these are the requests to merge the issues fixes from their branch back to the main branch (or the release branch, or whatever)... I think?