Joe is a CS instructor in the Computer Science department at Central Texas College, Killeen Texas. (He has recently moved from from Salinas CA to Killeen TX.) Central Texas College is located 50 miles north of Austin, and CS/Tech events within Austin offer excellent opportunities to "kick start" student interest. Central Texas College offers AS degrees in the area of: IT, Network and Security, and CS transfer studies.
Prior to teaching at Hartnell College, Joe spent 26 years in the Navy as a Naval Aviator and Aeronautical Engineering Duty Officer, largely focused on software development support for aircraft and flight trainers.
Joe's scholarly interests are focused on improving the teaching practices in programming education, network and host security, software carpentry practices distributed to other campus students and orbital optimization for LEO satellites (!).
Joe was recently involved with the following grants and initiatives:
a. Co-PI, NSF Award 1317649, Science, Technology, Engineering, and Mathematics Talent Expansion Program (STEP) , "Academic Integrity Management (AIM) of a collaborative three year computer science degree program," b. Coordinated Hartnell College participation and engagement with MPICT (Mid-Pacific Information and Communication Technologies (ICT) Center) with the mission to coordinate promote and improve the quality of ICT education. c. Coordinated Hartnell college participation with Cyberwatch East and Cyberwatch West involving activities, workshops and clinics focused on computer security and information assurance. d. Co-PI in managing grant execution for Hartnell College Scholars in Science, Technology, Engineering and Math (SSTEM) grant. The SSTEM Scholarship program is intended to increase student success in Science, Technology, Engineering, and Math fields.
Due to the proximity of FT Hood, the largest US Army base in the US, to Central Texas College, Joe is seeking programs and pathways to introduce transitioning soldiers to the opportunities in software development, web development, and network security.
During free and family time Joe enjoys hiking, traveling (visiting family and friends across the states) and coding (of course!).
[2-8 Oct 2017] Stage 1 Activities. Completed:
1. Introduction to FOSS (2 hrs) - Completed 10/5. (Repeated activity from prior workshop. Notable elements were:
Eric Raymond documents on steps to become a hacker, philosophy of code development Article: Computer Science Education: Where Are the Software Engineers of Tomorrow? Document: Teaching_Open_Source 0.1 Practical Open Source Software Exploration Multiple references to tools and utilities available to participate. Much of the conversational style was encouraging and clear. Logged into Freenode channel ##python-friendly
2. TOS Activity Part 1 - Joined the Teaching Open Source Mailing List Part 2 - Added myself to the People Page on Teaching Open Source
3. Introduction to Wikis Created my wiki and linked to participant page
4. Introduction to IRC Used HexChat to access IRC'steps Will lurk on foss2serve and other channels over next two weeks to become familiar with content and interaction.
5. IRC Meeting - completed
Introduction to Project Anatomy - Guided Tour
Sugar Labs Project
Summarize the roles that you think would be most applicable for your students.
The initial role of the student will be to respond to a gently directed effort to find specific details, much as is done in Stage 1A. This initial effort could be described as introduction, orientation for OS project interaction. The roles for the students could be documentation, people person, and a role as teaching perspective advocate, serving to validate proposals or efforts from the student view.
What are the commonalities across roles? What are the differences?
For effective participation in the project, each role would require effort, attention and effective communication. The roles would vary by specific responsibility as well as skill set necessary to participate well in a selected role. For example, an ardent student, not yet comfortable or proficient in coding or software dev would not be able to contribute at a high level in the Developer role and can be more fully engaged in another role. However, pairing this new student developer with a more seasoned developer may provide a participation path in a developer role.
Bug Tracker Describe the general process for submitting a bug.
Select the Issues tab of the repo and use the "New Issue" tab.
Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.
Types of bugs listed are: bug, design, feature, needs SLOBS (?), needs work. Bugs can be retrieved and sorted by various sort/search fields such as: Author, Label, Project, Assignee, Milestones
Repository -- https://github.com/sugarlabs/sugar/ Click the "Commits" link and determine the date of the last commit (an update of the repository).
The last commit was 10/05/2017.
Describe how the release cycle and roadmap update are related.
The roadmap is updated at the beginning of each release cycle. A roadmap was not present on the page.
The Sahana Eden Project (https://sahanafoundation.org/eden/) Read the information found here to get an overview of the goals of the project and the types of contributions one can make.
Community -- In the section titled Want to Contribute to Sahana Eden?, you will find a list of ways in which one can contribute. Again, you will note that there are a variety of distinct groups, each with a distinct responsibility.
There are several avenues to assist with the Sahana Eden project, involving subsidiary projects such as:
EDEN Codebase SSF Operations Disaster Response Research & Action The EDEN Codebase efforts will likely best align with the OS dev capabilities of the POSSE members.
Follow the links to each of the groups listed below and summarize the information you find there. For example, are there any commonalities? Is there something distinct for each type of contributor? How is this structure different than the one you found on the Sugar Labs website?
The characteristics of facilitating engagement with new participants and Sahana Eden are similar to (perhaps named differently) those in SugarLabs. An aspiring participant must identify value and reason to take action on the project; select an avenue of participation and engagement in which they have an emerging or specific skill; interact with a healthy communication mechanism which encourages the act of communicating as well as highlight the products of the interactions (better documentation, identification of bugs, correction of bugs, etc.).
Tracker -- The Sahana Eden bug tracker can be found here. How is the information here different than the information found on the Sugar Labs tracker page?
Information access path is different, but the actual acquired information is similar. The bug tracker takes an additional step. The documentation seems more comprehensive and more easily followed.
Click the Active Tickets link. Indicate the types/categories of tickets listed on this page as well as the information available for each ticket.
The types/ categories for the listed tickets are: Summary Component, Version, Priority, Type, Owner, Status Created.
On the repository -- https://github.com/sahana/eden Click the "Commits" link and determine the date of the last commit (an update of the repository). Record the date on your wiki page. https://github.com/sahana/eden
Release cycle -- Information about Sahana Eden's release cycle and roadmap can be found here.Include a brief entry on your wiki page that summarizes the information you find here.
The roadmap documentation summary was clear (compared to SugarLabs). The grouping of features/tickets were by category and easy to discern: AAA, Requests Management, Asset Management, etc. There was also a guide provided to interpreting the roadmap (http://eden.sahanafoundation.org/wiki/TracRoadmap).
Part 2 - OpenHub 1.How many projects were returned? There were 225 pages, of 10 projects per page. Total projects is approx 2250. 2.Is any of the code located on GitHub? Most of the project code seems to be hosted on GitHub. 3. How many similar projects are listed? There are ten similar projects. 4. What information does OpenHub provide about the project? Summary, # commits and contributors, # LOC, language, evaluation of code base, COCOMO size equivalency. 5. How many projects were returned for each search? Humanitarian: approx 30 projects; disaster management: approx 30 projects. 6. Why do so many projects do not have activity information available? The means to pull data on activitiy may be blocked. [: projects that do not have recent analysis because of problems with their code locations or other problems blocking Open Hub from collecting and analyzing code will show the Not Available icon."] 7. Click on Organizations. What information is provided on the Organizations page? Metrics on the contributing organizations: name, commits, participation by sector, search and filter by sector. 8. When was the last commit for OpenMRS Core on OpenHub? 10/10/2017 9. When was the last commit for OpenMRS Core on GitHub? 1 day 10. Why do you think these sites have different information? The level of familiarity and comfort contributors have with using each particular source. Also, the data "pull" frequency or granularity may cause larger intervals in assessing metrics/participation. 11. What would be the benefits/drawbacks of using both GitHub and OpenHub to search for a project? The benefits are wider scope and coverage. The drawback would be possible duplication, or reconciling variances between both sites. A helpful summary is provide here: "The Open Hub is not a forge — it does not host projects and code. The Open Hub is a directory and community, offering analytics and search services and tools." Use GH for source code configuration management. Use GH and OH for information and analytics.
2. Project Evaluation (Activity)
FOSS in Courses The resources referenced (books, sites on FOSS) were wonderful and are essential to develop a serious, sustained FOSS effort on campus Considerations regarding the sequence to build a FOSS synergy on campus
1. Most important - develop/identify welcoming activities which have low threshold - encouraging students to progress in small steps over time is essential.
2. Use the coding learned in class as the baseline for needed FOSS skill development. Several FOSS skills could be introduced within the class as a means to highlight opportunities.
3. Hold workshops to support collaborative effort on FOSS projects. These workshops could roughly follow the POSSE model. Students would be exposed to the considerable opportunities available - in an area of their interest.
4. Develop a more concerted structure to attain some FOSS achievement. Do not want to send the students off on their own to be successful or fail. Perhaps a summer course, an extended weekend workshop (8 hrs) or a week long (x2?) adjunct to existing courses.
5. Most important - FOSS should be seen as a vital thread to all courses and not as a set of activities "over there".
6. Open Hatch Comes to Campus (OHCTC) and Jessica McKellar provide basis to begi introduction of FOSS.
7. How to best construct sessions for guidng and skill development? use the resources listed on  Directions, Q2. Need to review the resources for clarity and consistence for supporting student activities. Can they follow thread of activities from FOSS materials or classes to make progress.
8. The discussions in Directions, Q1 were excellent.
9. There are broken links in http://teachingopensource.org/index.php/Teaching_Materials_Catalogue, curating references would be great first step to avoid rework for all participants. The resource provide a very solid foundation.
POSSE Part C Assignment [4-7 Sep 2015] Part 4 FOSS in Courses Planning
Important goals would incentivize and encourage the students that they CAN contribute to FOSS as a matter of course and that the mechanism to do so is fairly straightforward. Many students have a service oriented nature and willingness to extend their growing CS skills to assist others - the incentive exists. The current low level of student FOSS participation, even for skilled students, suggests that small scale steps leading to completion to participation , perhaps as a part of a course, may prove illuminating and fruitful. The next sustaining step is to arm the students with solid understanding of the tools to create and submit.
The steps to date within POSSE have helped a tremendous amount to foster specific and useful resources as well as steps towards gaining some proficiency, then through effort and revisit, competency and mastery. The basic CS and programming skills for the students are acquired through the college curriculum. The steps to contribute and a sense of competence in FOSS participation is the purpose of the two workshops below.
Introductory Workshop (setting foundation)
1. Prerequisite knowledge: Skills, knowledge for typical CS0 student -> CLI skills
2. Select specific bugs, features which can be developed/fixed within a short time, to serve as success events for students
3. Set up VM for consistent tools and steps for students
1. Work through the sources of open source products, much as was done with POSSE activities. For my college, due to small numbers and desire to remain focused, converging initially will on 1-2 projects to work on collaboratively will be valuable. Completing the effort leading to a pull request (2-4 times) is important as the student adds value to the community effort.
2. Parse Intro to FOSS (Activity A) into 60 minute presentation. Provide post-workshop reading recommendations and questions to elicit most important points from readings.
3. Underscore the inevitably and value of being "Productively Lost"
4. Introduce HFOSS as a baseline for helpful opportunities.
5. Introduce git in small sense and use as a basis to clone, fork and submit pull request
6. Teach the presentation with another CS faculty, to serve as observer and identify recommendations to improve. This CS faculty is not primarily (or at all) a presenter - provides basis to refactor workshops.
Applied Workshop 1 (baby steps)
1. After students gain a sense of FOSS, ask that they identify a project, together, to work on for a short time.
2. Work through any problems from above and ensure all students in AWS1 can step through git in meaningful way - not simply watching videos
1. Ask students (using PP practices) to identify "fixable" bugs or features or contributions.
2. Review the 50 list - make sure the students are aware that other means of contribution exist - keep appetite whetted
3. Ask for 2 pull-request submissions within workshop period