User:Dlillethun
Contents |
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
- Make your first contribution
- Code Base Understanding
- Fix a bug / make an enhancement / write a test (on a snapshot?)
- 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
| Evaluation Factor | Level (0-2) |
Evaluation Data |
|---|---|---|
| Licensing | 2 | Mozilla Public License (MPL) 2.0 (GPL compatible) |
| Language | 2 | Java (with Spring framework) |
| Level of Activity | 2 | multiple commits during most months of the past year, plus a couple bursts of activity |
| Number of Contributors | 2 | 324 total contributors, and more than several who have made multiple commits in the past year |
| Product Size | ? | need to find a way to count loc while using Firefox |
| Issue Tracker | 2 | 1260 issues "Ready for Work", 14184 "Closed", a blocking issue is resolved about once a month |
| New Contributor | 2 | Clear instructions for getting started, communication channels, ways to contribute, and a pathway for beginners |
| Community Norms | 1.5 | Code of conduct document exists but was buried in the FAQ and hard to find |
| User Base | 2 | Website shows sites across the world using the software, plus makes it easy for new users to download and start using it |
| Total Score | 15.5 |
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?
