User:Dinclezan

From Foss2Serve
(Difference between revisions)
Jump to: navigation, search
 
(21 intermediate revisions by one user not shown)
Line 158: Line 158:
 
| '''Code of Conduct:'''  
 
| '''Code of Conduct:'''  
 
(1) There is a section about consequences of breaking the code;  
 
(1) There is a section about consequences of breaking the code;  
 +
 
(2) There is a section about people leaving the project and what they should do in this case;  
 
(2) There is a section about people leaving the project and what they should do in this case;  
 +
 
(3) Respect and consensus are discussed.  
 
(3) Respect and consensus are discussed.  
 +
 
'''Communications:'''  
 
'''Communications:'''  
 +
 
(1) Contributors generally acknowledge others' good ideas and are thankful when helped;  
 
(1) Contributors generally acknowledge others' good ideas and are thankful when helped;  
 +
 
(2) Discussions usually start with a more formal language and then they move to informal language, especially between long-term collaborators;  
 
(2) Discussions usually start with a more formal language and then they move to informal language, especially between long-term collaborators;  
 +
 
(3) Clarifications are demanded and offered using a polite tone.
 
(3) Clarifications are demanded and offered using a polite tone.
 
|-
 
|-
Line 176: Line 182:
 
|
 
|
 
|}
 
|}
 +
 +
 +
'''Stage 1B.3 Intro to Copyright and Licensing -- Notes'''
 +
 +
#Project Licenses:
 +
#*[https://github.com/openmrs/openmrs-core https://github.com/openmrs/openmrs-core]: Mozilla Public License, version 2.0
 +
#*[https://github.com/apache/incubator-fineract https://github.com/apache/incubator-fineract]: Apache License, Version 2.0, January 2004
 +
#*[https://github.com/regulately/regulately-back-end https://github.com/regulately/regulately-back-end]: No license
 +
#License "cans", "cannots", and "musts":
 +
##Mozilla Public License, version 2.0:
 +
##*"Cans": commercial use, modify, distribute, sublicense, place warranty, use patent claims
 +
##*"Cannots": use trademark, hold liable
 +
##*"Musts": include copyright, include license, disclose source, include original
 +
##Apache License, version 2.0:
 +
##*"Cans": commercial use, modify, distribute, sublicense, private use, use patent claims, place warranty
 +
##*"Cannots": hold liable, use trademark
 +
##*"Musts": include copyright, include license, state changes, include notice
 +
#Consider contributing:
 +
##Mozilla Public License, version 2.0: No. Does no include the possibility of private use
 +
##Apache License, version 2.0: Yes.
 +
 +
'''Stage 1B.4 FOSS in Courses (1) -- Notes'''
 +
 +
#'''Capstone Project (CSE 448/449)''' - Valuable resources: (i) [http://foss2serve.org/index.php/Independent_Capstone_Project_Design Independent Capstone Project Design]; (ii) [https://blog.humphd.org/teaching-open-source-sept-2018-april/ Teaching Open Source: Sept 2018 - April 2019]
 +
#*Have students go through some of the POSSE activities:
 +
#**Intro to FOSS (1A.1) -- select three projects they may be interested in as a team (or I pre-select three projects for them to consider?!?)
 +
#**Intro to FOSS Project Anatomy (1A.6)
 +
#**FOSS Field Trip (1B.1) -- the parts that relate the the three selected projects
 +
#**Project Evaluation (1B.2) -- evaluate each of the three selected projects; choose one project that the team will actually work on
 +
#*Contribute (in this order; decide a minimum of contributions accepted by the community for each grade level):
 +
#**Documentation (software engineering majors especially)
 +
#**Clean up tickets
 +
#**Add a test suite
 +
#**Propose UX design improvements (software engineering majors especially)
 +
#**Comment code that is unclear/ not well commented (?)
 +
#**Fix bugs
 +
#'''Comparative Programming Languages (CSE 465)'''
 +
#'''Technology, Ethics, and Global Society (CSE 262)'''
 +
 +
'''Stage 1C.1 Intro to Bug Trackers -- Notes'''
 +
 +
(2) '''Projects:''' gtk, rhythmbox, vala, gnote, gnome, glib, pygobject, gimp, etc.
 +
 +
(3) '''Other info available:''' short description (title), when the ticket was open and by whom, when it was last updated, its type (e.g., bug, feature).
 +
 +
(4) '''Labels:''' type (e.g., bug, feature), project it relates to, what device is affected (e.g., webcam), OS (MacOS, Windows), what version is affected (e.g., GIMP 2.10.10), what is needed (e.g., needs information, needs design).
 +
 +
(5) '''Additional info when browsing through a couple of issues:''' activity (updates: added when and by whom), milestone, time tracking (i.e., estimate or time spent), due date, confidentiality, whether locked or not, status, asignee
 +
 +
(6) '''Other label groups:''' 2.blue (issues that require more discussion/design/info), 3.yellow (tickets that are non-issues, not really a problem), 4.purple (tasks that are good for newcomers), 8.green (documentation), 9.red (issues related to how users perceive the application), no_number.bluish_green (short/long term vision in terms of releases).
 +
 +
(7) '''How are issues organized on the board:''' open vs. closed issues, stretch (long term - 4 releases away) and deliverable (short term - 2 releases away).
 +
 +
(8) '''How does GNOME appear to use milestones?''' Collect issues for an upcoming release (See milestone "2.61.5 - Project Milestone" on page 1 with 0 issues as of 06/12/2019)
 +
 +
(9) '''Merge requests:''' In contrast with issues, merge request contain info on the pipeline: whether they passed, failed, or are running; and number of upvotes. Syntax for linking a merge request to an issue: "Request to merge [...] into [branch]"
 +
 +
 +
'''Stage 1C.3 FOSS in Courses (2) -- Notes'''
 +
 +
At Miami University, capstone design courses spread over one year - two courses of 2 credit hours each, one each semester. Teams of 3-4 students are created and each one of them is assigned a faculty member that will act as a mentor. Mentors are not supposed to help with the coding part or technical details of the project, but rather make sure that students are making sufficient progress (accountability issues) and direct them to necessary resources or individuals when students encounter obstacles in their work. Faculty mentors usually meet once a week with each of the teams assigned to them, for a 15-minute meeting.
 +
 +
'''Activity 1: Weekly reports'''
 +
 +
This activity is meant to assist faculty mentors in tracking student progress, guiding students in being proactive and reporting their progress, and allowing students in a team to support each other in finding areas for contributions within the project. Contributions can consist of documentation, cleaned up tickets, test suites added, proposed UX design improvements, code comments, bug fixes, or other (e.g., new code). The activity assumes that teams of 3-4 students have already went through several existent POSSE activities (see "Stage 1B.4 FOSS in Courses (1) -- Notes" above) and have selected a common project to work on. Students will be graded on their achievements on an individual basis, but they will provide support and peer evaluations within their teams.
 +
 +
 +
'''Instructions for the students:'''
 +
Fill out the form below with your answers to the following questions:
 +
 +
1. What area of contributions will you address? You should have made at least 2 contributions of a previous type before you move on to the next type of contributions.
 +
 +
2. Browse through the project to identify possible contributions that you can make. What areas of the project may be suitable for such contributions? List them. If you cannot identify such areas by yourself, contact the project community to inquire about it. Be ready to show the conversation to the project mentor faculty at the next meeting. You can ask for help in finding a suitable area of the project for contributions from your team mates. Report on how you identified for areas for contributions.
 +
 +
3. While browsing through the project, have you found any other parts of the project that may be suitable for types of contributions that you will address in the future?
 +
 +
4. What contributions do you plan to make by next meeting? What is the timeline for the other potential contributions that you have identified?
 +
 +
 +
'''Form:'''
 +
 +
Name: __________________
 +
 +
Date: __________________
 +
 +
Focusing on Contributions of Type: (Check one)
 +
 +
1. __ Documentation
 +
 +
2. __ Cleaning up Tickets
 +
 +
3. __ Adding Test Suites
 +
 +
4. __ Proposing UX design improvements
 +
 +
5. __ Writing Code Comments
 +
 +
6. __ Fixing Bugs
 +
 +
7. __ Other (e.g., write new code) Specify: ___________________
 +
 +
Identified areas of the project that are suitable for contributions of this type:
 +
 +
____________________________________
 +
 +
Suitable areas identified by: (Check one or more)
 +
 +
__ Investigating the project on my own
 +
 +
__ Asking for help from the HFOSS project community
 +
 +
__ Asking for help from other team members. List names ____________________
 +
 +
 +
Areas identified for other types of contributions:
 +
 +
________________ for contributions of type _____________________
 +
 +
________________ for contributions of type _____________________ (add more rows if needed)
 +
 +
 +
Timeline for contributions:
 +
 +
1. Commit ___________________________ by _________________________
 +
 +
2. Commit ___________________________ by _________________________
 +
(add more rows if needed)
 +
 +
 +
Fill out the following table:
 +
{| class="wikitable" style="width:100%;"
 +
|-
 +
! Type of Contribution
 +
! Committed since last meeting
 +
! Accepted since last meeting
 +
! Committed overall
 +
! Accepted overall
 +
|-
 +
| '''Documentation'''
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| '''Cleaning up Tickets'''
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| '''Proposing UX design improvements'''
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| '''Cleaning up Tickets'''
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| '''Writing Code Comments'''
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| '''Fixing Bugs'''
 +
|
 +
|
 +
|
 +
|
 +
|-
 +
| '''Other:''' ___________
 +
|
 +
|
 +
|
 +
|
 +
|}
 +
 +
 +
'''Learning Outcomes:''' After successfully completing this activity, the learner should be able to:
 +
# Identify areas of possible contributions
 +
# Track and report progress in terms of committed and accepted contributions
 +
# Create a timeline for the next contributions to be made
 +
 +
'''Prerequisite knowledge:'''
 +
Students are assumed to have completed the following existing POSSE activities:
 +
#Intro to FOSS (1A.1) -- select three projects they may be interested in as a team (or I pre-select three projects for them to consider?!?)
 +
#Intro to FOSS Project Anatomy (1A.6)
 +
#FOSS Field Trip (1B.1) -- the parts that relate the the three selected projects
 +
#Project Evaluation (1B.2)
 +
 +
'''Estimated time required for instructor prep:'''
 +
# 30 minutes, one time per semester: At the beginning of the semester, the instructor is supposed to determine the minimum of contributions of each type (or overall), committed vs. accepted, for each letter grade. The instructor is also supposed to decide whether a minimum number of committed/accepted contributions of one type is required before the student can move on to a different type of contribution.
 +
# 15 minutes per week: Analyze students' filled forms during the in-person meetings and provide feedback on progress.
 +
 +
'''Estimated time for student completion:''' 6 hours per week (for a 2 hours course)
 +
 +
The activity can be covered independent of the HFOSS community schedule.
 +
 +
'''Possible input required from the HFOSS community:'''
 +
What areas of the project may provide opportunities for the types of contributions listed above?
 +
 +
'''Contribution of the activity back to the HFOSS project:'''
 +
The contributions made by students are supposed to be submitted back to the project, not kept locally.
 +
 +
'''Contribution of the activity back to the POSSE project:'''
 +
The activity is meant to be reused by other professors using HFOSS projects in teaching capstone design courses. It is useful in that it provides a template for monitoring student work with minimal prep time for the instructor.
 +
 +
'''Assessment/grading:'''
 +
Each student will report their contributions individually, for each type of contribution (e.g., documentation, bug fixes), in terms of committed vs. accepted contributions by the HFOSS community. The other team members will provide support in finding areas in the project that may allow for such contributions, but students will make their contributions individually. A minimum number of submitted and accepted contributions of each type will be decided upon by the instructor for each letter grade, with input from the POSSE community.
 +
 +
'''Questions or concerns:'''
 +
What projects are suitable for a capstone project, and especially for the types of contributions listed above? How many contributions of each type can reasonably be expected from each student?
 +
 +
'''Stumbling blocks or barriers to carrying out the activity/task:'''
 +
How to include peer evaluations before students make submissions, in order to ensure a high level of accepted submissions by the HFOSS community.
 +
 +
 +
 +
'''Activity 2'''
 +
 +
This activity is supposed to help students reflect on their experience in the HFOSS capstone project midway through the semester and at the end of each capstone project semester.
 +
 +
'''Instructions for the students:'''
 +
Answers to the following questions:
 +
# What works well in the HFOSS-based capstone project?
 +
# What can be improved in the HFOSS-based capstone project?
 +
# What questions do you have related to the HFOSS-based capstone project?
 +
# What have you learned from your involvement in the HFOSS project? Think about technical knowledge, but also soft skills, networking, what you have learned about the HFOSS community, etc.
 +
# How often have you communicated with members of the HFOSS community for your project?
 +
# How welcoming was the HFOSS community for your project?
 +
# What kind of support did you receive from your team mates?
 +
# How easy was it to find possible contributions?
 +
# What technical difficulties have you encountered so far?
 +
 +
'''Learning Outcomes:''' After successfully completing this activity, the learner should be able to:
 +
# Identify what works well in the HFOSS-based capstone project.
 +
# Identify what can be improved in the HFOSS-based capstone project.
 +
# Identify questions they have related to the HFOSS-based capstone project.
 +
# Identify what they have learned from involvement in the HFOSS project.
 +
 +
'''Prerequisite knowledge:'''
 +
Students are assumed to have completed the following existing POSSE activities:
 +
#Intro to FOSS (1A.1) -- select three projects they may be interested in as a team (or I pre-select three projects for them to consider?!?)
 +
#Intro to FOSS Project Anatomy (1A.6)
 +
#FOSS Field Trip (1B.1) -- the parts that relate the the three selected projects
 +
#Project Evaluation (1B.2)
 +
They are also assumed to have gone at least through 2-3 iterations of Activity 1 listed above.
 +
 +
'''Estimated time required for instructor prep:''' None
 +
 +
'''Estimated time for student completion:''' 1-2 hours, twice a semester
 +
 +
The activity can be covered independent of the HFOSS community schedule.
 +
 +
'''Possible input required from the HFOSS community:''' N/A
 +
 +
'''Contribution of the activity back to the HFOSS project:''' Potentially, relevant feedback can be transmitted to active contributors in the HFOSS community.
 +
 +
'''Contribution of the activity back to the POSSE project:'''
 +
The activity is meant to be reused by other professors using HFOSS projects in teaching capstone design courses. It is useful in that it provides a template for student reflections with minimal prep time for the instructor.
 +
 +
'''Assessment/grading:'''
 +
Each student will complete the reflection individually. The reflection will be graded as Completed/Not Completed and will be assigned the corresponding number of points as follows: 0 points - Not Completed; Max points - Completed and thoroughly; Half of Max points - Completed, but not thoroughly.
 +
 +
'''Questions or concerns:'''
 +
Any other questions to be added to the list? Provide an indication of expected length of answers to each questions?
 +
 +
'''Stumbling blocks or barriers to carrying out the activity/task:'''
 +
N/A

Latest revision as of 22:11, 12 June 2019

Name: Daniela Inclezan

Position: Assistant Professor, Computer Science and Software Engineering, Miami University, 501 E High St, Oxford, OH 45056

email: inclezd@miamioh.edu

Page: http://miamioh.edu/cec/academics/departments/cse/about/faculty-and-staff/inclezan_daniela/index.html

GitHub:

IRC: server: nick: channels:

HFOSS Projects:

HFOSS-Related Courses:

Grants:

Publications:

Other Organizations:

Bio: I am involved with the Humanitarian Engineering and Computing (HE&C) minor at Miami University and serve as the advisor for the Computer Science students enrolled in this the minor. I am also the faculty advisor of the local chapter of the Girls Who Code club. I am interested in the HFOSS initiative as a way to recruit and retain minority students and provide learning opportunities for students in the HE&C minor.

Stage 1A. Intro to FOSS Project -- Notes

SUGAR LABS

  1. Contributions
    • Roles most applicable to my students:
      Developer
      writing and testing code, reporting bugs
      Designer
      user interface design, web design, mock-ups design -- suitable for my students majoring in Software Engineering
    • Commonalities across roles: Focus on communication and education.
    • Differences between roles: Different skillsets are required.
  2. Tracker
    • Submitting a bug: Find the relevant activity or repo component; go to the issues tab; press the green button to submit a bug.
    • Types of tickets: defect, enhancement, task
    • Information available for each ticket: ticket (number), summary (description), status (new, assigned, reopened, accepted, closed), owner, type, priority(unspecified, normal, high, low), milestone
  3. Repository
    • Date of last commit: March 13, 2019
  4. Release Cycle:
    • Relationship between the release cycle and roadmap update: The roadmap is updated at the beginning of each release cycle. The roadmap may include
      the schedule of release dates and freeze points; the list of modules and external dependencies; references to tickets considered for the release; references to new feature proposals.

SAHANA EDEN

  1. Community
    • Commonalities between contributor groups: Most of the roles are rather on the technical side. The only exceptions are the tester and translator roles.
    • Differences between contributor groups: technical vs. non-technical contributor; required expertise (e.g., GIS, sys admin, etc.); amount of details, guidelines and training provided
    • Differences in structure compared to the Sugar Labs website: The technical roles are more in number and divided into separate categories (developers, designers, Sys Admins, GIS specialists); generally more guidelines and instructions; a higher level of technical expertise seems to be required at first glance.
  2. Tracker
    • Differences with respect to the Sugar Labs tracker page:
      • Preset labels can be selected from a dropdown menu
      • Labels are not grouped by type of information in the list of labels to choose from (e.g., priority labels, type of issue labels and component information are all mixed together in the same list), but they are color-coded
      • The date when the issue was open is recorded
      • Comments are available
    • Types of issues: bug, enhancement, documentation
  3. Repository
    • Date of last commit: April 26, 2019
  4. Release Cycle: Unable to access the page (ERROR: FORBIDDEN)


Stage 1B.1 FOSS Field Trip -- Notes

Part 1. GitHub

  • (2.1) How many repositories are found for "education"? 27,839
  • (2.2) How many of these repos use the JavaScript language? 3,456
  • (2.3) In the first page of results, which repo was updated most vs least recently? nodeschool/los-angeles vs drongous/ems
  • (3.1) Which education repo has the most stars? How many? freeCodeCamp - 303k
  • (5.1) How many issues are open? closed? 228 Open; 13,336 Closed
  • (5.2) How many pull requests are open? closed? 1,781 Open; 20,332 Closed
  • (5.3) Click on the Insights tab. What do you see? An overview and graph for the most recent pull requests and issues (default: last week)
  • (5.4) Within Insights, go to the left menu and click on Commits. What do you see? A chart with the number of commits per week. The most commits were done in early October 2018.
  • (6.1) Search for "humanitarian" projects. How many repos are found? 507
  • (6.2) Find HTBox/crisischeckin. How many stars does it have? What language(s) does it use? When was the last update? 178 stars; C#; Oct 24, 2018
  • (6.3) Search for "disaster management", or terms that interest you. How many repos are found? disaster management - 473; language preservation - 18

Part 2. OpenHub

  • (2.1) Search for "education." The listing shows the number of pages, not the number of projects. By default, each page shows 10 projects. How many projects were found?2,262
  • (3.1) Which (if any) of the most active projects do you recognize? Sakai (11th most active)
  • (4.1) From the KDE Education page, click on Code Locations (on the right side). Are any of the repo locations on GitHub? No (does not seem so based on the repository URLs)
  • (4.2) Go back to KDE Education, and click on Similar Projects (below Code Locations). How many similar projects are listed? 10
  • (4.3) This page contains general information for the similar projects. What info is shown for each? Name, activity level, language, license, and icon
  • (5.1) How many projects did the search for "humanitarian"/ "disaster management"/ desired term return? humanitarian - 23; disaster management - 30; language preservation - 16
  • (6) Why is "activity not available"? Because of problems with the projects' code locations or other problems blocking Open Hub from collecting and analyzing code
  • (7.1) Organizations: What info is shown? Most active orgs, newest orgs, orgs by 30 day commit volume, stats by sector
  • (8.1) In Organizations, search for "OpenMRS". Do the search results show projects or organizations? organizations
  • (8.2) Find the project "OpenMRS Core". When was the last commit? Hard to find: February 2018?
  • (9) Search for "OpenMRS Core" in GitHub. When was the last commit? On May 20, 2019 (9 hours ago).
  • (9.1) Why do you think these sites have different info? Because the project was transferred from OpenHub to GitHub? Or because OpenHub requires more information to analyze in order to show a project as active
  • (10) What are some benefits & drawbacks of searching for a project in both GitHub & OpenHub? Benefits: they complement each other (e.g., info about last commit was easier to find in GitHub; can search by organization in OpenHub). Drawbacks: the information is organized and presented differently on the two platforms and you have to learn both.


Stage 1B.2 Project Evaluation -- Notes


Evaluation Factor Level
(0-2) 		Evaluation Data
Licensing 2 Mozilla Public License 2.0 (MPL-2.0) - open source (OSI) and free software (FSF) license
Language 2 Java (96.2%); SQLPL (2.9%); Other (0.9%)
Level of Activity 2 But: last quarter was not that active and there were few commits most weeks (under 5)
Number of Contributors 2 323
Product Size 1 223.35 MB
Issue Tracker 2 Ready for work: 1276; Closed: 14148; Third issue created on 2008-05-21, updated on 2019-04-08; Other issues created in 2014, 2017 and updated in 2019
New Contributor 2
Community Norms 2 Code of Conduct:

(1) There is a section about consequences of breaking the code;

(2) There is a section about people leaving the project and what they should do in this case;

(3) Respect and consensus are discussed.

Communications:

(1) Contributors generally acknowledge others' good ideas and are thankful when helped;

(2) Discussions usually start with a more formal language and then they move to informal language, especially between long-term collaborators;

(3) Clarifications are demanded and offered using a polite tone.

User Base 2
  • User Guide
  • Some questions from users on AskOpenMRS
  • Annual report from 2018 lists "More than 3,048 sites & 8.6 million active patients"
Total Score 17


Stage 1B.3 Intro to Copyright and Licensing -- Notes

  1. Project Licenses:
  2. License "cans", "cannots", and "musts":
    1. Mozilla Public License, version 2.0:
      • "Cans": commercial use, modify, distribute, sublicense, place warranty, use patent claims
      • "Cannots": use trademark, hold liable
      • "Musts": include copyright, include license, disclose source, include original
    2. Apache License, version 2.0:
      • "Cans": commercial use, modify, distribute, sublicense, private use, use patent claims, place warranty
      • "Cannots": hold liable, use trademark
      • "Musts": include copyright, include license, state changes, include notice
  3. Consider contributing:
    1. Mozilla Public License, version 2.0: No. Does no include the possibility of private use
    2. Apache License, version 2.0: Yes.

Stage 1B.4 FOSS in Courses (1) -- Notes

  1. Capstone Project (CSE 448/449) - Valuable resources: (i) Independent Capstone Project Design; (ii) Teaching Open Source: Sept 2018 - April 2019
    • Have students go through some of the POSSE activities:
      • Intro to FOSS (1A.1) -- select three projects they may be interested in as a team (or I pre-select three projects for them to consider?!?)
      • Intro to FOSS Project Anatomy (1A.6)
      • FOSS Field Trip (1B.1) -- the parts that relate the the three selected projects
      • Project Evaluation (1B.2) -- evaluate each of the three selected projects; choose one project that the team will actually work on
    • Contribute (in this order; decide a minimum of contributions accepted by the community for each grade level):
      • Documentation (software engineering majors especially)
      • Clean up tickets
      • Add a test suite
      • Propose UX design improvements (software engineering majors especially)
      • Comment code that is unclear/ not well commented (?)
      • Fix bugs
  2. Comparative Programming Languages (CSE 465)
  3. Technology, Ethics, and Global Society (CSE 262)

Stage 1C.1 Intro to Bug Trackers -- Notes

(2) Projects: gtk, rhythmbox, vala, gnote, gnome, glib, pygobject, gimp, etc.

(3) Other info available: short description (title), when the ticket was open and by whom, when it was last updated, its type (e.g., bug, feature).

(4) Labels: type (e.g., bug, feature), project it relates to, what device is affected (e.g., webcam), OS (MacOS, Windows), what version is affected (e.g., GIMP 2.10.10), what is needed (e.g., needs information, needs design).

(5) Additional info when browsing through a couple of issues: activity (updates: added when and by whom), milestone, time tracking (i.e., estimate or time spent), due date, confidentiality, whether locked or not, status, asignee

(6) Other label groups: 2.blue (issues that require more discussion/design/info), 3.yellow (tickets that are non-issues, not really a problem), 4.purple (tasks that are good for newcomers), 8.green (documentation), 9.red (issues related to how users perceive the application), no_number.bluish_green (short/long term vision in terms of releases).

(7) How are issues organized on the board: open vs. closed issues, stretch (long term - 4 releases away) and deliverable (short term - 2 releases away).

(8) How does GNOME appear to use milestones? Collect issues for an upcoming release (See milestone "2.61.5 - Project Milestone" on page 1 with 0 issues as of 06/12/2019)

(9) Merge requests: In contrast with issues, merge request contain info on the pipeline: whether they passed, failed, or are running; and number of upvotes. Syntax for linking a merge request to an issue: "Request to merge [...] into [branch]"


Stage 1C.3 FOSS in Courses (2) -- Notes

At Miami University, capstone design courses spread over one year - two courses of 2 credit hours each, one each semester. Teams of 3-4 students are created and each one of them is assigned a faculty member that will act as a mentor. Mentors are not supposed to help with the coding part or technical details of the project, but rather make sure that students are making sufficient progress (accountability issues) and direct them to necessary resources or individuals when students encounter obstacles in their work. Faculty mentors usually meet once a week with each of the teams assigned to them, for a 15-minute meeting.

Activity 1: Weekly reports

This activity is meant to assist faculty mentors in tracking student progress, guiding students in being proactive and reporting their progress, and allowing students in a team to support each other in finding areas for contributions within the project. Contributions can consist of documentation, cleaned up tickets, test suites added, proposed UX design improvements, code comments, bug fixes, or other (e.g., new code). The activity assumes that teams of 3-4 students have already went through several existent POSSE activities (see "Stage 1B.4 FOSS in Courses (1) -- Notes" above) and have selected a common project to work on. Students will be graded on their achievements on an individual basis, but they will provide support and peer evaluations within their teams.


Instructions for the students: Fill out the form below with your answers to the following questions:

1. What area of contributions will you address? You should have made at least 2 contributions of a previous type before you move on to the next type of contributions.

2. Browse through the project to identify possible contributions that you can make. What areas of the project may be suitable for such contributions? List them. If you cannot identify such areas by yourself, contact the project community to inquire about it. Be ready to show the conversation to the project mentor faculty at the next meeting. You can ask for help in finding a suitable area of the project for contributions from your team mates. Report on how you identified for areas for contributions.

3. While browsing through the project, have you found any other parts of the project that may be suitable for types of contributions that you will address in the future?

4. What contributions do you plan to make by next meeting? What is the timeline for the other potential contributions that you have identified?


Form:

Name: __________________

Date: __________________

Focusing on Contributions of Type: (Check one)

1. __ Documentation

2. __ Cleaning up Tickets

3. __ Adding Test Suites

4. __ Proposing UX design improvements

5. __ Writing Code Comments

6. __ Fixing Bugs

7. __ Other (e.g., write new code) Specify: ___________________

Identified areas of the project that are suitable for contributions of this type:

____________________________________

Suitable areas identified by: (Check one or more)

__ Investigating the project on my own

__ Asking for help from the HFOSS project community

__ Asking for help from other team members. List names ____________________


Areas identified for other types of contributions:

________________ for contributions of type _____________________

________________ for contributions of type _____________________ (add more rows if needed)


Timeline for contributions:

1. Commit ___________________________ by _________________________

2. Commit ___________________________ by _________________________ (add more rows if needed)


Fill out the following table:

Type of Contribution Committed since last meeting Accepted since last meeting Committed overall Accepted overall
Documentation
Cleaning up Tickets
Proposing UX design improvements
Cleaning up Tickets
Writing Code Comments
Fixing Bugs
Other: ___________


Learning Outcomes: After successfully completing this activity, the learner should be able to:

  1. Identify areas of possible contributions
  2. Track and report progress in terms of committed and accepted contributions
  3. Create a timeline for the next contributions to be made

Prerequisite knowledge: Students are assumed to have completed the following existing POSSE activities:

  1. Intro to FOSS (1A.1) -- select three projects they may be interested in as a team (or I pre-select three projects for them to consider?!?)
  2. Intro to FOSS Project Anatomy (1A.6)
  3. FOSS Field Trip (1B.1) -- the parts that relate the the three selected projects
  4. Project Evaluation (1B.2)

Estimated time required for instructor prep:

  1. 30 minutes, one time per semester: At the beginning of the semester, the instructor is supposed to determine the minimum of contributions of each type (or overall), committed vs. accepted, for each letter grade. The instructor is also supposed to decide whether a minimum number of committed/accepted contributions of one type is required before the student can move on to a different type of contribution.
  2. 15 minutes per week: Analyze students' filled forms during the in-person meetings and provide feedback on progress.

Estimated time for student completion: 6 hours per week (for a 2 hours course)

The activity can be covered independent of the HFOSS community schedule.

Possible input required from the HFOSS community: What areas of the project may provide opportunities for the types of contributions listed above?

Contribution of the activity back to the HFOSS project: The contributions made by students are supposed to be submitted back to the project, not kept locally.

Contribution of the activity back to the POSSE project: The activity is meant to be reused by other professors using HFOSS projects in teaching capstone design courses. It is useful in that it provides a template for monitoring student work with minimal prep time for the instructor.

Assessment/grading: Each student will report their contributions individually, for each type of contribution (e.g., documentation, bug fixes), in terms of committed vs. accepted contributions by the HFOSS community. The other team members will provide support in finding areas in the project that may allow for such contributions, but students will make their contributions individually. A minimum number of submitted and accepted contributions of each type will be decided upon by the instructor for each letter grade, with input from the POSSE community.

Questions or concerns: What projects are suitable for a capstone project, and especially for the types of contributions listed above? How many contributions of each type can reasonably be expected from each student?

Stumbling blocks or barriers to carrying out the activity/task: How to include peer evaluations before students make submissions, in order to ensure a high level of accepted submissions by the HFOSS community.


Activity 2

This activity is supposed to help students reflect on their experience in the HFOSS capstone project midway through the semester and at the end of each capstone project semester.

Instructions for the students: Answers to the following questions:

  1. What works well in the HFOSS-based capstone project?
  2. What can be improved in the HFOSS-based capstone project?
  3. What questions do you have related to the HFOSS-based capstone project?
  4. What have you learned from your involvement in the HFOSS project? Think about technical knowledge, but also soft skills, networking, what you have learned about the HFOSS community, etc.
  5. How often have you communicated with members of the HFOSS community for your project?
  6. How welcoming was the HFOSS community for your project?
  7. What kind of support did you receive from your team mates?
  8. How easy was it to find possible contributions?
  9. What technical difficulties have you encountered so far?

Learning Outcomes: After successfully completing this activity, the learner should be able to:

  1. Identify what works well in the HFOSS-based capstone project.
  2. Identify what can be improved in the HFOSS-based capstone project.
  3. Identify questions they have related to the HFOSS-based capstone project.
  4. Identify what they have learned from involvement in the HFOSS project.

Prerequisite knowledge: Students are assumed to have completed the following existing POSSE activities:

  1. Intro to FOSS (1A.1) -- select three projects they may be interested in as a team (or I pre-select three projects for them to consider?!?)
  2. Intro to FOSS Project Anatomy (1A.6)
  3. FOSS Field Trip (1B.1) -- the parts that relate the the three selected projects
  4. Project Evaluation (1B.2)

They are also assumed to have gone at least through 2-3 iterations of Activity 1 listed above.

Estimated time required for instructor prep: None

Estimated time for student completion: 1-2 hours, twice a semester

The activity can be covered independent of the HFOSS community schedule.

Possible input required from the HFOSS community: N/A

Contribution of the activity back to the HFOSS project: Potentially, relevant feedback can be transmitted to active contributors in the HFOSS community.

Contribution of the activity back to the POSSE project: The activity is meant to be reused by other professors using HFOSS projects in teaching capstone design courses. It is useful in that it provides a template for student reflections with minimal prep time for the instructor.

Assessment/grading: Each student will complete the reflection individually. The reflection will be graded as Completed/Not Completed and will be assigned the corresponding number of points as follows: 0 points - Not Completed; Max points - Completed and thoroughly; Half of Max points - Completed, but not thoroughly.

Questions or concerns: Any other questions to be added to the list? Provide an indication of expected length of answers to each questions?

Stumbling blocks or barriers to carrying out the activity/task: N/A

Retrieved from "http://foss2serve.org/index.php?title=User:Dinclezan&oldid=13557"
Personal tools
Namespaces
Variants
Actions
Events
Learning Resources
HFOSS Projects
Evaluation
Navigation
Toolbox