User:RMccleary

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
(Sugar Labs project / release cycle)
m
 
(9 intermediate revisions by one user not shown)
Line 24: Line 24:
 
At first, I thought the comments to oneself (the /me commands) were inhibiting the flow of the meeting. On further reflection, I think they add value by giving a little comic relief.
 
At first, I thought the comments to oneself (the /me commands) were inhibiting the flow of the meeting. On further reflection, I think they add value by giving a little comic relief.
  
−
== Sugar Labs Project ==
+
=== Sugar Labs Project ===
  
−
=== Roles most applicable for my students ===
+
==== Roles most applicable for my students ====
  
 
My students come with a variety of skills and interests, so some of them may fit several roles while others may only fit one role. Some of roles seem to have some common skills required: content writer and people person seem to require good communication skills; designers and developers need to use complex programs (for programming and graphic design, respectively). The educator role doesn't seem to fit well for any of my current students.
 
My students come with a variety of skills and interests, so some of them may fit several roles while others may only fit one role. Some of roles seem to have some common skills required: content writer and people person seem to require good communication skills; designers and developers need to use complex programs (for programming and graphic design, respectively). The educator role doesn't seem to fit well for any of my current students.
Line 45: Line 45:
 
We have several international students, mainly from Saudi Arabia and a few from Japan, who could be helpful here.
 
We have several international students, mainly from Saudi Arabia and a few from Japan, who could be helpful here.
  
−
=== Use of Tracker ===
+
==== Use of Tracker ====
  
 
General instructions to submit bugs can be found at the [http://wiki.sugarlabs.org/go/Submit_Bugs/Problems Submit Bugs/Problems page]. To submit a bug, first visit the [https://github.com/sugarlabs sugarlabs page at github] and look for the activity or a sugar component repository that is relevant. If it isn't clear which one is the best choice, pick the first on in the list, [https://github.com/sugarlabs/sugar sugar].  
 
General instructions to submit bugs can be found at the [http://wiki.sugarlabs.org/go/Submit_Bugs/Problems Submit Bugs/Problems page]. To submit a bug, first visit the [https://github.com/sugarlabs sugarlabs page at github] and look for the activity or a sugar component repository that is relevant. If it isn't clear which one is the best choice, pick the first on in the list, [https://github.com/sugarlabs/sugar sugar].  
Line 53: Line 53:
 
The type or category of and issues will be either defect or enhancement. For each ticket, the system tracks a ticket number, a summary statement, status, owner, type, priority, and a milestone.
 
The type or category of and issues will be either defect or enhancement. For each ticket, the system tracks a ticket number, a summary statement, status, owner, type, priority, and a milestone.
  
−
=== Repository ===
+
==== Repository ====
  
 
The project uses Gitorious, which supports distributed, open source projects and appears to use a local repos.
 
The project uses Gitorious, which supports distributed, open source projects and appears to use a local repos.
  
−
=== Release cycle and roadmap update ===
+
==== Release cycle and roadmap update ====
  
 
The roadmap is updated at the beginning of each release cycle by the release team.
 
The roadmap is updated at the beginning of each release cycle by the release team.
 +
 +
=== The Sahana Eden Project ===
 +
 +
==== Community / contributing ====
 +
 +
'''Developers - ''' Developers will need certain programming skills. The system is developed in Web2Py, and Python and Javascript experience would be helpful.  It uses the Model-View-Controller (MVC) architectural pattern to implementing the user interfaces. Developers sign a license agreement retaining all rights to their code but allowing it to be distributed and used.
 +
 +
'''Testers - ''' They can be non-technical, doing manual testing and documenting new test cases.
 +
 +
'''Designers - ''' They give input about the look and usability of the application and the project web sites. The preferred, but not only, way to do this is in the form of CSS and HTML
 +
 +
==== Tracker ====
 +
 +
The tracker for this project keeps data similar to that kept for the Sugar Labs project. For each ticket, it keeps ticket number, summary statement, component, version, priority, type, owner, status, and date created.
 +
 +
Type can be defect/bug, enhancement, documentation, and task.
 +
 +
==== Repository ====
 +
 +
The project apparently uses a local repo.
 +
 +
==== Release cycle ====
 +
 +
Version 0.9.0 "Medway" was released five years late (in 2011). Version 1.0 "Avon" has no date set but was planned for May 2012. Version 2.0 is mentioned but with no projected date.
 +
 +
=== Explorations of forges and OpenHub ===
 +
 +
There is a lot of commonality of the facilities between the two. Both support repos, bug tracking, and various forms of communication. My impression is that the OpenHub may scale up better for large projects (but, of course, I compared a relativley small project in Sourceforge to OpenMRS in OpenHub).
 +
 +
 +
=== Evaluation of OpenMRS ===
 +
 +
OpenMRS would be a good choice for my students. Here is the evaluation sheet on the project: [[file:OpenMRS_Evaluation.pdf |frame | Evaluation Sheet for the OpenMRS Project]]
 +
 +
=== FOSS In Courses - Part 1 ===
 +
 +
I would like to consider activities that would fit in the second semester of my two-semester Java sequence or of my two-semester C# sequence. Two seemed to fit in that they would expose my students to large code bases:
 +
 +
'''Diagnose a bug''' Individually or in pairs, the students would be assigned a simple open bug (or allowed to select from a prepared list) and asked study the code to figure out the cause of the bug. I might create a peer review process so students get their work reviewed before submitting it to the FOSS project.
 +
 +
'''Test a beta or release candidate''' Students would download, build and test the software. This could be a team activity. Teams might be paired and compare the results of their testing before submitting it to the FOSS project.
 +
 +
'''Add a comment''' Each student would look for obscure or unusual code and document it. Here again, I would probably create a peer review process.
 +
 +
=== Bug Tracker Activity ===
 +
 +
I was able to figure out the meaning of the column headings and the possible values for most of the columns. I looked at two bugs I thought I might have a chance to fix. I also run a canned report and experimented with graphing some data about bugs.
 +
 +
=== FOSS In Courses - Part 2 ===
 +
 +
In part 1, I identified three activities I would consider in my advanced C# or Java courses. Here is additional information and development of the ideas.
 +
 +
'''Diagnose a bug''' Individually or in pairs, the students would be assigned a simple open bug (or allowed to select from a prepared list) and asked study the code to figure out the cause of the bug. I might create a peer review process so students get their work reviewed before submitting it to the FOSS project.
 +
 +
* Possible learning outcomes: Students improve program debugging skills
 +
 +
* Pre-requisite knowledge: How to use bug tracker
 +
 +
* Estimated instructor prep time: 5 hours
 +
 +
* Student completion and elapsed calendar time: 5-10 hours; one week
 +
 +
* Requires synchronizing activity with the community: Not required
 +
 +
* Possible input required from the HFOSS community (kind and amount): none
 +
 +
* Result of the activity contributed back to the HFOSS project (contribution and its usefulness): Yes, the of the bug diagnosis to the bug ticket
 +
 +
* Assessment/grading approach
 +
** Basis for grading: Some credit for reasonable effort even if there is not success
 +
** Team activity or individual: Probably do 2-3 person teams
 +
** Role for the HFOSS community in assessing student work: Might consider the responses from the HFOSS community to the comments students enter on the bug tickets
 +
 +
* Questions or concerns: Want to be sure to not clog the tracking system with useless communication
 +
 +
* Stumbling blocks or barriers: Possible problem finding enough of bugs of the right level of difficulty
 +
 +
'''Test a beta or release candidate''' Students would download, build and test the software. This could be a team activity. Teams might be paired and compare the results of their testing before submitting it to the FOSS project.
 +
 +
* Possible learning outcomes: Students improve program testing skills
 +
 +
* Pre-requisite knowledge: How to download and build the system; how to use the system
 +
 +
* Estimated instructor prep time: 10 hours
 +
 +
* Student completion and elapsed calendar time: 10-15 hours; 1-2 weeks
 +
 +
* Requires synchronizing activity with the community: have to wait for the beta or release
 +
 +
* Possible input required from the HFOSS community (kind and amount): not sure
 +
 +
* Result of the activity contributed back to the HFOSS project (contribution and its usefulness): Yes, the of the results of the tests
 +
 +
* Assessment/grading approach
 +
** Basis for grading: Some credit for reasonable effort even if there is not success
 +
** Team activity or individual: Probably do 2-3 person teams
 +
** Role for the HFOSS community in assessing student work: Might consider the responses from the HFOSS community to the input from the students
 +
 +
* Questions or concerns: could get complicated; timing issues waiting for beta or release
 +
 +
* Stumbling blocks or barriers: not sure
 +
 +
 +
'''Add a comment''' Each student would look for obscure or unusual code and document it. Here again, I would probably create a peer review process.
 +
 +
* Possible learning outcomes: Students improve program reading skills
 +
 +
* Pre-requisite knowledge: How to use bug tracker; how to access the source code
 +
 +
* Estimated instructor prep time: 5 hours
 +
 +
* Student completion and elapsed calendar time: 5-10 hours; one week
 +
 +
* Requires synchronizing activity with the community: Not required
 +
 +
* Possible input required from the HFOSS community (kind and amount): none
 +
 +
* Result of the activity contributed back to the HFOSS project (contribution and its usefulness): Yes, the the commented code
 +
 +
* Assessment/grading approach
 +
** Basis for grading: difficulty of the code and quality of the comments
 +
** Team activity or individual: Probably do 2-3 person teams
 +
** Role for the HFOSS community in assessing student work: Might consider the responses from the HFOSS community to the commented code submitted by the students
 +
 +
* Questions or concerns: Want to be sure to not clog the HFOSS project with useless communication
 +
 +
* Stumbling blocks or barriers: Possible problem finding enough of code segments right level of difficulty
 +
 +
 +
[[Category:POSSE 2016-06]]

Latest revision as of 01:34, 7 February 2017

Contents

About Ron McCleary

Ron is assistant professor of computer science at Avila University in south Kansas City, Missouri. He has been at Avila for 14 years. Before that, he was Director of Corporate Information Systems for Terracon, a national engineering consulting company with headquarters in the Kansas City area. Before that, he was at Rockhurst University in Kansas City for 13 years, four of them as a computer science instructor and nine as Director of Computer Services.

Avila is a liberal arts schools sponsored by the Sisters of St. Joseph of Carondelet. The Computer Science Department offers three majors: computer science, software engineering, and a newly approved one in health informatics. Ron teaches a variety of courses that includes operating systems, computer organization and architecture, database, networking, systems analysis and design, Java, and C#.

Ron's interests and activities outside the classroom include reading, hiking, and teaching in the education program of his church.

FOSS Deliverables

IRC

How do people interact? While the meeting has a "flow" to it, because of the asynchronous characteristics of the typed responses, it is more of be a flow with ripples.

What is the pattern of communication? Is it linear or branched? Formal or informal? One-to-many, one-to-one or a mix? Generally, a linear flow of ideas but with a lot of small branching in and out of the current theme. It is informal. Generally, it is one-to-many, interspersed with occasional one-to-one communications; i.e. it is a mix.

Are there any terms that seem to have special meaning? Don't think I noticed any.

Can you make any other observations? At first, I thought the comments to oneself (the /me commands) were inhibiting the flow of the meeting. On further reflection, I think they add value by giving a little comic relief.

Sugar Labs Project

Roles most applicable for my students

My students come with a variety of skills and interests, so some of them may fit several roles while others may only fit one role. Some of roles seem to have some common skills required: content writer and people person seem to require good communication skills; designers and developers need to use complex programs (for programming and graphic design, respectively). The educator role doesn't seem to fit well for any of my current students.

Content writer Several of my students are good writers and have the skills to write content.

People Person Again, several of my students would be good at this role. In fact, many of the ones who could do well as Content Writers would also do well in this category.

Developer We have a two-semester Python requirement in the major to introduce our students to programming, so most of my students should do well in this category.

Designer A few of our students are doing graphic arts minors and would be well fitted for this category.

Translator We have several international students, mainly from Saudi Arabia and a few from Japan, who could be helpful here.

Use of Tracker

General instructions to submit bugs can be found at the Submit Bugs/Problems page. To submit a bug, first visit the sugarlabs page at github and look for the activity or a sugar component repository that is relevant. If it isn't clear which one is the best choice, pick the first on in the list, sugar.

You will need to be signed in to github (follow the links at the top of either page). Hit the "Issues" tab at the top of the page and the the big green button labeled "New issue" to report the issue.

The type or category of and issues will be either defect or enhancement. For each ticket, the system tracks a ticket number, a summary statement, status, owner, type, priority, and a milestone.

Repository

The project uses Gitorious, which supports distributed, open source projects and appears to use a local repos.

Release cycle and roadmap update

The roadmap is updated at the beginning of each release cycle by the release team.

The Sahana Eden Project

Community / contributing

Developers - Developers will need certain programming skills. The system is developed in Web2Py, and Python and Javascript experience would be helpful. It uses the Model-View-Controller (MVC) architectural pattern to implementing the user interfaces. Developers sign a license agreement retaining all rights to their code but allowing it to be distributed and used.

Testers - They can be non-technical, doing manual testing and documenting new test cases.

Designers - They give input about the look and usability of the application and the project web sites. The preferred, but not only, way to do this is in the form of CSS and HTML

Tracker

The tracker for this project keeps data similar to that kept for the Sugar Labs project. For each ticket, it keeps ticket number, summary statement, component, version, priority, type, owner, status, and date created.

Type can be defect/bug, enhancement, documentation, and task.

Repository

The project apparently uses a local repo.

Release cycle

Version 0.9.0 "Medway" was released five years late (in 2011). Version 1.0 "Avon" has no date set but was planned for May 2012. Version 2.0 is mentioned but with no projected date.

Explorations of forges and OpenHub

There is a lot of commonality of the facilities between the two. Both support repos, bug tracking, and various forms of communication. My impression is that the OpenHub may scale up better for large projects (but, of course, I compared a relativley small project in Sourceforge to OpenMRS in OpenHub).


Evaluation of OpenMRS

OpenMRS would be a good choice for my students. Here is the evaluation sheet on the project: File:OpenMRS Evaluation.pdf

FOSS In Courses - Part 1

I would like to consider activities that would fit in the second semester of my two-semester Java sequence or of my two-semester C# sequence. Two seemed to fit in that they would expose my students to large code bases:

Diagnose a bug Individually or in pairs, the students would be assigned a simple open bug (or allowed to select from a prepared list) and asked study the code to figure out the cause of the bug. I might create a peer review process so students get their work reviewed before submitting it to the FOSS project.

Test a beta or release candidate Students would download, build and test the software. This could be a team activity. Teams might be paired and compare the results of their testing before submitting it to the FOSS project.

Add a comment Each student would look for obscure or unusual code and document it. Here again, I would probably create a peer review process.

Bug Tracker Activity

I was able to figure out the meaning of the column headings and the possible values for most of the columns. I looked at two bugs I thought I might have a chance to fix. I also run a canned report and experimented with graphing some data about bugs.

FOSS In Courses - Part 2

In part 1, I identified three activities I would consider in my advanced C# or Java courses. Here is additional information and development of the ideas.

Diagnose a bug Individually or in pairs, the students would be assigned a simple open bug (or allowed to select from a prepared list) and asked study the code to figure out the cause of the bug. I might create a peer review process so students get their work reviewed before submitting it to the FOSS project.

  • Possible learning outcomes: Students improve program debugging skills
  • Pre-requisite knowledge: How to use bug tracker
  • Estimated instructor prep time: 5 hours
  • Student completion and elapsed calendar time: 5-10 hours; one week
  • Requires synchronizing activity with the community: Not required
  • Possible input required from the HFOSS community (kind and amount): none
  • Result of the activity contributed back to the HFOSS project (contribution and its usefulness): Yes, the of the bug diagnosis to the bug ticket
  • Assessment/grading approach
    • Basis for grading: Some credit for reasonable effort even if there is not success
    • Team activity or individual: Probably do 2-3 person teams
    • Role for the HFOSS community in assessing student work: Might consider the responses from the HFOSS community to the comments students enter on the bug tickets
  • Questions or concerns: Want to be sure to not clog the tracking system with useless communication
  • Stumbling blocks or barriers: Possible problem finding enough of bugs of the right level of difficulty

Test a beta or release candidate Students would download, build and test the software. This could be a team activity. Teams might be paired and compare the results of their testing before submitting it to the FOSS project.

  • Possible learning outcomes: Students improve program testing skills
  • Pre-requisite knowledge: How to download and build the system; how to use the system
  • Estimated instructor prep time: 10 hours
  • Student completion and elapsed calendar time: 10-15 hours; 1-2 weeks
  • Requires synchronizing activity with the community: have to wait for the beta or release
  • Possible input required from the HFOSS community (kind and amount): not sure
  • Result of the activity contributed back to the HFOSS project (contribution and its usefulness): Yes, the of the results of the tests
  • Assessment/grading approach
    • Basis for grading: Some credit for reasonable effort even if there is not success
    • Team activity or individual: Probably do 2-3 person teams
    • Role for the HFOSS community in assessing student work: Might consider the responses from the HFOSS community to the input from the students
  • Questions or concerns: could get complicated; timing issues waiting for beta or release
  • Stumbling blocks or barriers: not sure


Add a comment Each student would look for obscure or unusual code and document it. Here again, I would probably create a peer review process.

  • Possible learning outcomes: Students improve program reading skills
  • Pre-requisite knowledge: How to use bug tracker; how to access the source code
  • Estimated instructor prep time: 5 hours
  • Student completion and elapsed calendar time: 5-10 hours; one week
  • Requires synchronizing activity with the community: Not required
  • Possible input required from the HFOSS community (kind and amount): none
  • Result of the activity contributed back to the HFOSS project (contribution and its usefulness): Yes, the the commented code
  • Assessment/grading approach
    • Basis for grading: difficulty of the code and quality of the comments
    • Team activity or individual: Probably do 2-3 person teams
    • Role for the HFOSS community in assessing student work: Might consider the responses from the HFOSS community to the commented code submitted by the students
  • Questions or concerns: Want to be sure to not clog the HFOSS project with useless communication
  • Stumbling blocks or barriers: Possible problem finding enough of code segments right level of difficulty
Retrieved from "http://foss2serve.org/index.php?title=User:RMccleary&oldid=8790"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox