User:Jburge

Latest revision as of 21:56, 12 June 2017

Janet Burge

Janet Burge is an Associate Professor in the Department of Mathematics and Computer Science at Colorado College. Colorado College is a small liberal arts college in Colorado Springs and teaches on the Block Plan where students take one course at a time.

Prior to joining Colorado College Dr. Burge was an Associate Professor at Wesleyan University and at Miami University. While at Miami, she was awarded an NSF Career Award for her research in Design Rationale. Her research interests are AI in Design and Software Engineering.

Dr. Burge also spent 20 years in industry before starting her academic career.

Exercises:

Intro to Project Autonomy: Sugarlabs Project

Contributions: What would be the most suitable roles for my students? Developer, maybe Content Writer? Possibly Designer if students have the right skills. What are commonalities across roles? What are differences?. Educator can overlap with quite a few other roles. Content writer and People Person overlaps.

Tracker: What is the process for submitting a bug? File a bug using Trac. Describe, Categorize, Create. Types/categories of tickets: Defects and Enhancements. There are more detailed fields that can be set by the developers.

Repository: Date of last commit: October 10, 2016

Release cycle: How the release cycle and roadmap update are related:

Milestones are mapped to tickets to show the percentage complete. The roadmap lists items that are going into the particular Milestone. I am guessing Milestones represent releases? Some of the tasks have names next to them, some do not.

Sahana:

Contributions: Developers, Testers, Designers: commonality? Differences? Compare w/Sugarlabs Developers - work on tasks, tickets, projects Testers: - three types: manual testing by non-technical, developers writing tests, and administrators working on Continuous Integration. Designers: looking for help with the website - they mention graphic design but skills listed are HTML and CSS.

Overlap between developers and testers since developers write tests. Differences with Sugarlabs: explicit test role, designers are more developer like (Sugarlabs was looking for graphic-designer specific experience) Commonalities with Sugarlabs: developer role is similar.

Tracker:

      This is still using Trac, so that's similar to Sugarlabs'. The view we're taken to is
      a list of queries on reports (some are confusing - why would I have a list of reports if
      I am not logged in?). They have more types - defect, enhancement, documentation, and task. 
      In Sugarlabs we were taken to instructions for creating a ticket. Here we're on a reporting page
     but it does not provide a way to add a ticket. Is this restricted?
 
 Bug info: number, summary, version, priority, type, owner, status
 

Repository: last commit today (March 7, 2017)

Release cycle:

 The format is the same as Sugarlabs. It must be generated from Trac? More 
 detail under the tasks.

FOSS Field Trip:

Part 1 - Github:

11, 920 education repositories (!) Graphs shows who committed when, commits shows comments in order (most recent first) 284 Humanitarian repositories HTBox/crisischeckin - last commit August 7, 2016 136 Disaster management repositories

Part 2 - OpenHub

347 pages of education projects. 3461 total projects (assuming 10 per page, one on last page) None of the code is on github although it is all managed using Git Four similar projects are listed on the main page but if I click Similar Projects I get 10 OpenHub provides summary information, language, statistics (code, activity, community) Humanitarian - 34 Disaster management - 53 Activity information - some projects are not linked to their source code Organizations - lists most active, most recent, statistics by sector, commit volue OpenMRS Core - Last commit August 18, 2016, GitHub March 14, 2017 It sounds like OpenHub only grabs code and analyzes it periodically (OpenMRS got the code 8 months ago; analyzed it 6 months ago) OpenHub has a nice interface but GitHub is the most current. OpenHub will have information about projects that are not hosted on GitHub (although possibly not up to date information).

Evaluation Rubric

Copyright and Licensing

OpenMRS: MPL - Mozilla Public License - free to modify, distribute, sell. New versions must conform to the license. Can: commercial, modify, distribute, sublicense, , patent claims, place warranty. Can't: hold liable, use trademark. Must: include copyright, include license, disclose source, include original.

incubator-fineract : Apache license - free to modify, distribute, sell. New versions must conform. License does not have to be listed in every file. Can: commercial, modify, distribute, sublicense, private use, patent claims, place warranty. Can't: hold liable, use trademark, Must: include copyright, include license, state changes, include notice

regulately-back-end: couldn't find license information

I'd be ok contributing to the first two projects. The one where I can't find the license would be a problem.

FOSS in Courses 1

I'm interested in OpenMRS or Ushahidi (although I wouldn't mind having project selection be one of the things the students are responsible for)

The course I'm interested in supporting is the Senior Capstone course. Our capstone is unique in that the bulk of the work will occur during a 3.5 week period where that's all the students do. This does not mean the students aren't supposed to do planning and preparation before that. I would want a set of activities planned out in the time leading up to the project start so that they would be ready to jump in and start the bulk of their project work on November 27th. Actitivies I would like to see prior to that point:

1) Introduction to FOSS
2) Introduction to FOSS Project Anatomy
3) Project Evaluation - the students may be given a couple of choices - this is where we would narrow it down to a final selection
4) Ways to contribute - some of the FOSS readings from this activity would be useful for the students
5) Introduction to IRC - if this is how the chosen project(s) communicate
6) Bug Tracking (this will be new to the students)
7) Github (this will hopefully be review!)
8) Language tutorials (if needed)
9) Initial development selection - choose a bug or some small contribution to make
	-- this would take potentially several weeks
10) Propose the capstone project - ideally this would be a new feature but it depends on the project... 

I would recommend that the students blog or journal about this during the process, ideally on-line either through a Wiki (such as Google Sites) or something more official/polished (such as Wordpress)

Part C

Part C

Bug Tracking:

Part 1: Bug Reports ID - number identifying the bug Sev - how severe the bug is Pri - priority OS - operating system Product - products and components - what part of the software Status - unconfirmed, confirmed, in-progress, etc. Resolution - what happened to the bug (fixed, etc.) Summary - short description of the bug

Clicked on Reports to get this information Order: unconfirmed, then new Color: grey is enhancement, red is critical, black can be normal or major Bug to fix?

Bug 777558 User Manual drop-down menu should have a TOC. This bug is fairly recent (January this year) and has been assigned to GIMP BUGS (not sure what this means since it is not a person!). There hasn't been much discussion after it was proposed. To fix it I would first need to install the software to see what it is doing now and then find out what they need to have added to the software.

Bug 494314 - Awkward handling of non-existant paths. There's some error handling needed if an invalid path is typed in to make it less intrusive than the current dialog box. The bug was old but was modified recently - not sure what the modifications mean though. I would first make sure the bug was reproduceable to see if it is still an issue.

I find it confusing that the assignments are so generic - shouldn't a bug eventually to to a person?

Part 2: Collective Reports Summary: 278 opened, 208 closed in the past week. More opened than closed. Top 3 closers: Reiter, Muktapavels, Chimento. These may be the people who did the most work (although there could be bugs that are taking a while). Top 3 reporters: Lei, Nocera, Plazas There was some overlap between the two lists but not all were on both. Those using the software and reporting problems are not all the same as those making fixes. Patch reviewers and patch contributers overlapped by half. Some of these folks were on the other lists. 19 normal and 10 enhancements for braille Lots of reports for other kinds of bug status