User:Welch
Joe Welch
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!).
[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.
Done
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
10/8/2017.
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).
PENDING..... Part B [8-23 Aug 2015]
POSSE Part B Assignment
Part 1 - SourceForge Do the following: 1. Go to: http://sourceforge.net/
2. Use the Search feature in the center of the screen to view applications in an area of interest to you (e.g., gaming, sports, music, computing, etc.).
3. How many projects are there in this category? Security - 1195 OWASP - 17 Java/PHP/ JavaScript Firewall - 63 C/C++/Java/Unix Shell/C#/JavaScript/PHP/Perl SNMP management - 44 Perl/C/PHP/C++ Geospatial - 18 Java/JavaScript Satellite - 65 C++/C/Basic/Java
4. How many different programming languages are used to write software in this category? See above
5. List the top four programming languages used to write programs in this category. See above
6. Identify the meaning of each of the statuses below: (Most developed to least developed) Inactive 6 Mature - But basically if the software can answer to most of these criteria (in no order of importance): secure, reliable, actively maintained, has active community, field-proven 5 Production/Stable - a software product is available for purchase, release 4 Beta - Beta software refers to computer software that is undergoing testing and has not yet been officially released. Released to select users. 3 Alpha - software is computer software that is still in the early testing phase. 2 Pre-Alpha - development status given to a program or application that is usually not feature complete, and is not usually released to the public 1 Planning
7. a. Compare two projects in this category that have two different statuses. Describe the differences between the statuses. SaVi satellite constellation visualizer PreviSat
b. Which projects are the most used? How do you know? SaVi - 23 weekly downloads PreviSat - 121 weekly downloads
c. Pick a project in your category. [Project: ntop] Answer the questions below: 1. What does it do? Nagios, Network Monitoring Tool 2. What programming language is the project written in? Not able to determine on SourceForge. Noted as Perl from several README files. 3. Who is likely to use the project? How do you know this? Network managers - from description on SourceForge and narrative on ntop web site. 4. When was the most recent change made to the project? Last update was 5 days ago. 5. How active is the project? How can you tell? Intermittently active. Last update was 5 days ago. There is a page which shows downloads per week - varies. 1053 weekly downloads this week. 6. How many committers does the project have? Cannot determine 7. Would you use the project? Why or why not? Yes - both use and consider participating in development.
[8-23 Aug 2015] Part 2 - OpenHub
Explore OpenMRS:
1. Go to: https://www.openhub.net/ (Done, depiction of projects from the tag cloud is very helpful) 2. In the upper-most search space, enter: OpenMRS 3. Click on the OpenMRS logo or link. 4. What is the main programming language used in OpenMRS? (Java) 5. How many lines of code does OpenMRS have? (3.8M "...has had 54,687 commits made by 247 contributors representing 3,871,399 lines of code") 6. Click on "User & Contributor Locations" (lower right side of screen). List some of the locations of the developers. (South Africa, US) 7. Go back to the main OpenMRS page. Click on the "Languages" link. How many languages is OpenMRS written in? (15 languages) 8. What language has the second highest number of lines of code? (JavaScript) 9. Of the programming languages used in OpenMRS , which language the has the highest comment ratio? (Java 31.4%) 10. Click on the “Contributors” link under "SCM Data" menu. 11. What is the average number of contributors in the last 12 months? (approx 14) 12. Scroll down to the Top Contributors section. How long have the top three contributors been involved in the project? (4 yr, 4 yr, 2 yr) 13. Use the information on the project summary page to compute the 12-month average of commits. What is the average number of commits over the past 12 months?. (64 commits per month, last 12 months)
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 [1] 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)
PREPARATION
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
PRESENTATION
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)
PREPARATION
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
PRESENTATION
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
